Member-only story
Deployment Pipeline Reversibility
When developing systems in a modern way, when developing them in a cloud native fashion and adopting a high release cycle this will require controls for deployment reversibility. Traditionally, deploying changes in large monolithic systems, included bringing a change into a production system during a maintenance window and only after long and intense human user based testing. In modern systems changes can be pushed to production multiple times a day.
Changes, new releases, being pushed to production systems multiple times a day is not an excuse for skipping rigorous testing. It is not an excuse for skipping testing, however, testing will differ that it is not done by humans during SIT and UAT like testing “weeks”. Testing will be done based upon automated testing and could (should) include best practices like test driven development.
While rigorous testing should tackle issues before they are being deployed into production reality is that faulty code will be deployed into production at one point in time. Admitting to the fact that something will break, admitting that faulty code will be deployed into production at one point in time is the starting point for ensuring you can handle this in a controlled manner.
