Reversion - taking an environment and feature set back to a snapshot
We have invested in Continuous Delivery and this means we are now really good at continuously promoting features to live. (We discuss elsewhere why we like to track features, rather than code.) This means that features are constantly moving from through the Software Value Chain from Dev, to Test, to whatever other environments you’ve configured, and through to Production. We have Blue/Green deployment in Production: two environments, only one of which is reachable at any one time by users, so that we can flip to a new version of the application with zero downtime, and also flip back if we detect a problem through our built-in monitoring. But what if we don’t spot the problem in Live for a few hours or days and, in the meantime, someone updates Staging? We need a way of reverting back to a stable release without destroying the rest of our value chain - i.e. we want to revert to a stable version on Staging so we can test it, but leave Dev, Test, UAT etc. intact.
Clearly we have source control (we use Git) and an approach to delivery which tags both features and the environment configuration needed to execute them. To revert Staging to a previous version, we need to:
Create a version (a “tag”) of the master product repository which includes metadata for the set of microservices (including their versions) and the features related to that version;
Allow the operator to review the set of features to which they will revert. This is important because our whole approach is driven by features, rather than (for example) microservice versions;
Use the metadata to restore the Staging environment (using Ansible) to the tagged set of microservices, allowing the underlying engine to resolve automatically the set of corresponding features that are displayed to users through the console;
When the microservices are restored to the staging environment, we must then ensure that production tests are executed so that we know the release can be pushed live safely.
We call it Reversion, it’s in development but we wanted to share the idea now. This is because we’re finding that it takes time to convince people that a feature-based approach to managing development is the right way to go. We’re therefore addressing each point as it’s raised and this one has been bugging us for a few weeks. Please let us know what you think.
In our next blog, we’re going to talk about Product Streams: these describe how you manage different branches of the code through the Boost UI.
