My CA colleague in Europe, Benny Van de Sompele, posted an excellent LinkedIn blog titled 'When Do You Reach Continuous Delivery' that proposes a CD readiness assessment along 5 dimensions. Rather than make you click through to LinkedIn, I've reproduced the post below with his permission. So. Where do you score on readiness?
With continuous delivery gaining a lot of momentum in the market, there is also a growing level of confusion on what it means to be “enabled for continuous delivery”. What is “good”, or at least “good enough”? What is a realistic and achievable goal for this transformation project?
In most articles and presentations, you hear over and over again those same handful of examples such as Facebook (dozens of deployments per hour in production), Netflix (self healing within seconds) or Spotify. But those are the 0,001% of companies which are completely different than most of the existing organisations, who have a legacy of monolithic applications, who have to deal with complex architectural dependencies, who run on a variety of proprietary and open world technology stacks. Pretending that each and any of these companies can be enabled for continuous delivery in the same way like the 0,001% digital native companies is simply setting the wrong expectations.
continuous delivery enablement is not measured by the frequency of deploying changes in production.
When assessing where an organization is on the journey to reach the level of “enabled for continuous delivery”, I use the following 5 dimensions to calculate a readiness score: can “any release” be deployed to “any environment” at “any moment” fully “zero touch” by “anyone”. If so, then the readiness score is high and kudos to the team for reaching that point. It does not matter if you deploy once every quarter in production or several times per day, the fact you are enabled for it is what allows you to reach the benefits which come with continuous delivery.
- The “any release” dimension validates that a proper release management and versioning/revisioning is in place, broken builds are removed, a central repository is in place, dependency management is under control, etc.
- The “any environment” dimension requires that the organization has a clear release pipeline management and process in place, validation happens and automation ensures no mandatory phases can be skipped for the nature of the release. Dynamic environment provisioning is a plus, but integrated configuration management and drift which ensure any environment is always "ready" for being used does the job as well.
- The “any moment” dimension indicates if a release deployment needs to be planned well ahead of time because of the need for critical resources or manual activities, or if it can be decided and executed “ad hoc” and executed immediately (once all approval gates, if any, passed successfully).
- The “zero touch” relates to the ability to prepare, execute, validate, and if needed rollback without any manual interaction.
- “Anyone” is used in the context of segregation of roles and duties along the software life cycle. Can a non-technical release manager push the button, or do technical devops need to login to various systems and click the buttons for a release to be promoted and deployed along the life cycle.
Once an organisation is enabled for continuous delivery, then you can start implementing the benefits which continuous delivery brings to an organisation: increase the frequency of releases from once every quarter to once every month, or every week, or few times per hour. Start to refactor those monolithic applications into more modern composable applications or even micro services based architectures. And use that collected release pipeline data to visualise evolutions and improvements along the continuous delivery pipeline, setting reachable and realistic targets for all stakeholders based upon the current state of people, processes and technologies in use at your organisation.