4 ms·

Database is the sticky part of this strategy. If Blue is in production and Green is on deck, how are updates to the Blue database pushed to Green?

joshribakoff 11y ago
Copy DB from live [blue] to staging [green], then run migrations and test. Do this several times. This should give you confidence that the migrations behave as intended before you flip from blue to green for production & run the migrations for real. If you have "big data" you can use schemaless migrations, for example never rename a column, instead add a new column, update the app to deal with both columns, then in a subsequent update remove the old column. You can also avoid migrations [use mongo instead of relational DB, for example]. I recommend Fowler's "DB Refactoring" book for further reading. http://martinfowler.com/books/refactoringDatabases.html http://martinfowler.com/books/refactoringDatabases.html
- deleted 11y ago
  [deleted]
robinwarren 11y ago
I believe (in practice if not theory) it is common to handle db schema updates separately and to run both systems off the same database. This way the data only lives in one location but you get to run two slightly different app servers/frontends on top of it. You are then more careful with database changes. This sounds like a pain in the arse but a lot of people seem to be able to run with it without it causing a lot of additional overhead having to schedule your db changes to go out before your dependant code changes.
- hartror 11y ago
  Yeah this is how you do it. You can also use feature toggles to help manage this. http://martinfowler.com/bliki/FeatureToggle.html http://martinfowler.com/bliki/FeatureToggle.html
- neilellis 11y ago
  Yep agree, also keep the database schema a little soft - i.e. tolerant of minor changes. ( an example for SQL databases of this is having an 'additional info' field/table which has no value for indexing but contains additional captured info.)
- anton-107 11y ago
  So does this effectively mean - only create tables and add columns in your db schema migrations (no updating and removing)?
  - lmm 11y ago
    You can remove but you update the application to not read from the removed column (and test this in a test environment) first. "Updating" is best done by adding a new column, writing to the new column in parallel, back-populating it, reading from the new column, and then dropping the old column. It's a bit cumbersome but it works and it's safe.
dorfsmay 11y ago
It's complicated and time consuming, but one way to do it is to never modify a column, add new ones and use trigger to copy values from one to the next. Only delete two deploys later.
- pc86 11y ago
  I'm not saying I have a better solution, but that seems overly complicated and manual (e.g. remembering that in two deploys we're deleting ColumnA and TriggerColAColB) for a system that is seemingly designed to help automate the deployment process.
neilellis 11y ago
Personally I keep the database out of the equation, ala 12 Factor. The database when treated as a unique exception allows you to just get on with developing robust infrastructure. However for this to work you need to keep code off the database and treat database changes as migrations not blue/green deploys. I can't say this enough, treat the database as an exception, keep it clean without code on it and with 'soft' schemas (ones that tolerate minor changes well) - then you can do b/g deploys easily. Also let someone else host the DB where possible (or the same cloud infrastructure of course), it's just not worth the pain.
jbgreer 11y ago
Yes. Especially if you're using one of the systems as a failover or you're running them as a normally active-active configuration. You want DB replication, but you also want to be able to take down a blue or green, apply DB updates, be able to independently access blue or green to check out your changes, then roll the world over the upgrade leg, then do the same work on the other side, check it out, and then make it available. Alternating on blue / green as the 'live' side works, too.

joshribakoff 11y ago

Copy DB from live [blue] to staging [green], then run migrations and test. Do this several times. This should give you confidence that the migrations behave as intended before you flip from blue to green for production & run the migrations for real. If you have "big data" you can use schemaless migrations, for example never rename a column, instead add a new column, update the app to deal with both columns, then in a subsequent update remove the old column. You can also avoid migrations [use mongo instead of relational DB, for example]. I recommend Fowler's "DB Refactoring" book for further reading. http://martinfowler.com/books/refactoringDatabases.html http://martinfowler.com/books/refactoringDatabases.html

deleted 11y ago
[deleted]

robinwarren 11y ago

I believe (in practice if not theory) it is common to handle db schema updates separately and to run both systems off the same database. This way the data only lives in one location but you get to run two slightly different app servers/frontends on top of it. You are then more careful with database changes. This sounds like a pain in the arse but a lot of people seem to be able to run with it without it causing a lot of additional overhead having to schedule your db changes to go out before your dependant code changes.

hartror 11y ago
Yeah this is how you do it. You can also use feature toggles to help manage this. http://martinfowler.com/bliki/FeatureToggle.html http://martinfowler.com/bliki/FeatureToggle.html
neilellis 11y ago
Yep agree, also keep the database schema a little soft - i.e. tolerant of minor changes. ( an example for SQL databases of this is having an 'additional info' field/table which has no value for indexing but contains additional captured info.)
anton-107 11y ago
So does this effectively mean - only create tables and add columns in your db schema migrations (no updating and removing)?
- lmm 11y ago
  You can remove but you update the application to not read from the removed column (and test this in a test environment) first. "Updating" is best done by adding a new column, writing to the new column in parallel, back-populating it, reading from the new column, and then dropping the old column. It's a bit cumbersome but it works and it's safe.

dorfsmay 11y ago

It's complicated and time consuming, but one way to do it is to never modify a column, add new ones and use trigger to copy values from one to the next. Only delete two deploys later.

pc86 11y ago
I'm not saying I have a better solution, but that seems overly complicated and manual (e.g. remembering that in two deploys we're deleting ColumnA and TriggerColAColB) for a system that is seemingly designed to help automate the deployment process.

neilellis 11y ago

Personally I keep the database out of the equation, ala 12 Factor. The database when treated as a unique exception allows you to just get on with developing robust infrastructure. However for this to work you need to keep code off the database and treat database changes as migrations not blue/green deploys. I can't say this enough, treat the database as an exception, keep it clean without code on it and with 'soft' schemas (ones that tolerate minor changes well) - then you can do b/g deploys easily. Also let someone else host the DB where possible (or the same cloud infrastructure of course), it's just not worth the pain.

jbgreer 11y ago

Yes. Especially if you're using one of the systems as a failover or you're running them as a normally active-active configuration. You want DB replication, but you also want to be able to take down a blue or green, apply DB updates, be able to independently access blue or green to check out your changes, then roll the world over the upgrade leg, then do the same work on the other side, check it out, and then make it available. Alternating on blue / green as the 'live' side works, too.