Tags: production engineering*

0 bookmark(s) - Sort by: Date ↑ / Title /

  1. separate the deployment of schema changes from application upgrades. So first apply a database refactoring to change the schema to support both the new and old version of the application, deploy that, check everything is working fine so you have a rollback point, then deploy the new version of the application. (And when the upgrade has bedded down remove the database support for the old version.)
    2016-01-11 Tags: , , by klotz
  2. If the new version of your software doesn’t contain any data layer changes, then you stand up a new green environment with your stateless presentation and API layers, and simply reference the same data layer for both.
    If you make modifications, such as schema changes, to your data layer, you’ll need a process in place to keep the data in sync between the blue and green environments. Your users will make changes to data in both environments during the deployment. The complexity of such a process depends on your data needs: how often the data changes, the consistency model, and how different the old versus new data models are.
    2016-01-12 Tags: , by klotz
  3. If your blue and green environments are in the same AWS region, and you don’t have to account for schema changes, you can have both environments tap into the same data sources, significantly simplifying your deployment process.
    If you do need to account for schema changes, a simpler way to handle that is to decouple schema changes from code changes. By using decoupling, you can choose one of two approaches:
    Database updates are backward compatible
    Code changes are backward compatible with the old schema
    2016-01-12 Tags: , , by klotz

Top of the page

First / Previous / Next / Last / Page 1 of 0 SemanticScuttle - klotz.me: tagged with "production engineering"

About - Propulsed by SemanticScuttle