Spinnaker is a really interesting piece of kit, though when I last tried it 3-4 months ago the docs were in a state of flux and it took quite a lot of fiddling about to get things going.
The one thing I cannot find any details on, and it's not specific to Spinnaker, is; how do you perform your database changes as part of your deployment system? I figured it would be sensible to have one-off tasks you could run inside your containers as part of the pipelines, but I've not found any guidance on doing that with any CD tool at the moment.
> how do you perform your database changes as part of your deployment system?
Usually you run a database migration tool. However, the application has to be coded in a resilient way, so it can work with current and the immediate previous version.
In dev/test environments and if you have initial data that needs to be loaded, you just bring a new database up with the latest schema (hopefully in version control). You can have test cases that load old data, perform a migration and use the latest app version.
For production, it needs to be done more carefully if you're doing huge database changes. Ideally, you shouldn't exactly because CI/CD is letting you make smaller changes constantly... but sometimes your data is just too big and not trivial to migrate (e.g. a table with 1bn records now needs a new column base on data from another two columns)
That's a really interesting topic in my opinion, as well as coordinating migration of shards, etc. Is kubernetes the right later to orchestrate all that ?
robotmay|8 years ago
The one thing I cannot find any details on, and it's not specific to Spinnaker, is; how do you perform your database changes as part of your deployment system? I figured it would be sensible to have one-off tasks you could run inside your containers as part of the pipelines, but I've not found any guidance on doing that with any CD tool at the moment.
gtirloni|8 years ago
Usually you run a database migration tool. However, the application has to be coded in a resilient way, so it can work with current and the immediate previous version.
In dev/test environments and if you have initial data that needs to be loaded, you just bring a new database up with the latest schema (hopefully in version control). You can have test cases that load old data, perform a migration and use the latest app version.
For production, it needs to be done more carefully if you're doing huge database changes. Ideally, you shouldn't exactly because CI/CD is letting you make smaller changes constantly... but sometimes your data is just too big and not trivial to migrate (e.g. a table with 1bn records now needs a new column base on data from another two columns)
polskibus|8 years ago
florianleibert|8 years ago