The latest expert opinions, articles, and guides for the Java professional.
Introducing: Continuous Delivery
Before jumping in to describing the difference in approach it’s worthwhile to understand the philosophy of the Continuous Delivery (further “CD”) methodology:
As often as humans excel at the creative, they appear to suck at doing anything repetitive. In production updates, they are a source of error that should be eliminated as much as possible. The deployment path should be as predictable and repeatable as possible.
No action can happen without some kind of a trail. In fact, not only should the trail exist, it should be easy to access and navigate through, as well as redundant, like with double-entry bookkeeping.
Every step of the way, including production, should be probed for failures. Monitoring in both development and production is just a style of testing and should be planned accordingly. Combine A/B testing with gradual rollouts and we have a great way to isolate failure.
The moment you know or suspect that something is wrong, begin a predefined recovery process.
Recovery is a part of every change and without it the rest of the steps are effectively neutralized.
This philosophy is incorporated in the central concept of Continuous Delivery (CD): the automated pipeline leading from development all the way to production.
The idea of this pipeline is that every change that a developer makes and commits to the code repository flows through the pipeline creating a record of success along every step of the way. Each stage of the pipeline consists of automated or manual checks that try to enact and catch failure in the change you are trying to commit as early as possible. Once thelast check is cleared, the change is release-ready and can be deployed to production at any time.
At this point we would like to introduce an example application & environment and discuss the methodology and its pros/cons.
No comments yet.
Leave a comment