Climb the five steps of a continuous delivery maturity model
The continuous delivery maturity model lays out the five increasingly intense -- and capable -- levels of the process. Know where to start and when to progress.
Continuous delivery is for everyone, not just the DevOps elite. Wherever your organization falls in the continuous delivery maturity model, there's a path to progress higher.
The most effective improvement processes, whether they streamline manufacturing operations or speed up software development, describe the path to desired improvements -- not just the end state. Continuous improvement processes never focus on the end state, because perfection, however it's defined, can only be incrementally approached, never fully achieved.
A maturity model describes milestones on the path of improvement for a particular type of process. In the IT world, the best known of these is the capability maturity model (CMM), a five-level evolutionary path of increasingly organized and systematically more mature software development processes.
The CMM focuses on code development, but in the era of virtual infrastructure, agile automated processes and rapid delivery cycles, code release testing and delivery are equally important.
Continuous delivery (CD), sometimes paired with continuous integration to make CI/CD, is an automated process for the rapid deployment of new software versions. A complicated process, CD includes several steps that span multiple departments. CI/CD and DevOps can prove daunting to organizations that view modernization as a dichotomy: Either you're DevOps or you're legacy. But continuous delivery is an efficiency improvement that can evolve in stages.
Continuous delivery implementations pass through phases of maturity. This five-phase continuous delivery maturity model borrows its structure from the CMM, progressing from a base level of no effective capability through beginner, intermediate, advanced and expert stages. It's a path to the advanced capabilities befitting the DevOps major leaguers that deploy multiple times a day or even multiple times an hour.
Stage 1: A regressive, mostly manual starting point
The lowest maturity level is sometimes called the initial or regressive state because it is highly inefficient. Organizations typically have a hodgepodge of manual processes. At this stage, when automation is applied to application delivery, it's often ad hoc and isolated -- usually instituted by a single workgroup or developer and focused on a particular problem. Nevertheless, organizations starting down the continuous delivery path have often standardized portions of software development, such as the build system using CMake, Microsoft Visual Studio or Apache Ant and a code repository, like GitHub.
Containers are a common runtime destination for CI/CD pipelines, and if they're in use at this first stage of the continuous delivery maturity model, development teams have usually adopted Docker images defined by a Dockerfile.
Stage 2: Beginner CD with repeatable, managed processes
The first stage of maturity in continuous delivery entails extending software build standards to deployment. The team should define some repeatable, managed processes that get code to production. Developers shift build and deployment activities off of personal workstations -- the usual location for ad hoc chaos -- and onto a central, managed system available to all developers and the IT operations team. The goal at this stage in the continuous delivery maturity model is to establish an automated build and deployment system that can serve both the scheduled deliveries of updates or new features that occur during off hours, and self-service processes that are triggered by developers or IT teams.
The automation is generally quite rudimentary in organizations at this level of maturity: some scripts that consistently pull from a central location -- a standard environment configuration -- and changes tracked through a version control system. Automated code delivery processes require a software-defined runtime environment, such as VMs, containers or equivalent cloud services.
While the software builds are automated via scripts and applications plus container images also deployed with scripted automation, the team probably is just starting to experiment with automated deployment software, such as Jenkins, TeamCity and AWS CodeDeploy.
At this stage in the model, the participants might be in a DevOps team, or simply developers and IT operations collaborating on a joint project.
Stage 3: Intermediate CD means consistent and defined
The next level in the continuous delivery maturity model entails defining the activities for the entire move-to-production process, along with the file and system locations plus tooling to automate it. The goal is to increase release cycles' consistency, not their speed, although the intermediate stage is typically when organizations can stick to regular releases on a defined schedule, such as nightly or weekly. The entire CD process should be automated, launched with a single command.
To maintain a consistent release train, the team must automate test suites that verify software quality and use parallel deployment environments for software versions. Automation brings the CI/CD approach to unit tests, typically during the development stage and integration stage when all modules are brought together.
Testing illustrates the inherent overlap between continuous integration and continuous delivery; consistency demands that software passes acceptance tests before it is promoted to production. Test automation tools include pipeline software like Jenkins; test automation systems like Selenium or Cypress; and cloud services, including AWS CodePipeline or Microsoft Azure DevTest Labs.
Parallel software deployment environments don't require cloud services, but they are much easier to set up when infrastructure is delivered instantly as a service. Cloud services and CD automation simplify the task to create and manage redundant environments for production, beta and developer code. New releases nondisruptively roll into production after a suitable testing cycle with the help of parallel setups.
Stage 4: Automated throughout
Advanced CD implementations have almost completely automated code's journey from integration testing through various stages of test deployments onto production systems. So, if the entire CD process can launch with one command, why are there still two higher levels of CD maturity? Although testing is automated, many organizations are reluctant to cede control over the release to production, and, thus, might require a manual approval step before code gets promoted to the next stage of deployment.
Another characteristic of advanced continuous delivery maturity is the use of quantitative measures of software performance and quality, along with metrics that track the health and consistency of the CD process. Identify and monitor key performance indicators (KPIs) for better control over software acceptance and rollback criteria in test and in live production. For example, continually monitored application performance KPIs enable an CD system to automatically roll back a release that exhibits problems in production.
Issues and recommendations
Resist the tendency to treat a maturity model as prescriptive directions instead of generalized guidelines -- as a detailed map instead of a tour guidebook. Also, this continuous delivery maturity model shows a linear progression from regressive to fully automated; activities at multiple levels can and do happen simultaneously. DevOps teams need to learn more advanced techniques and tools while they master the basics. Therefore, start by defining a basic CD process and developing some simple scripts, but simultaneously research, learn and test more complicated processes and advanced tools.
At this advanced level, teams also tackle harder deployment problems, such as multi-tier applications in which several components must deploy together, but are on different release cycles. These composite applications also include more sophisticated components, notably databases, that are complicated to deploy and test.
Stage 5: DevOps experts optimize CD
The pinnacle of continuous delivery maturity focuses on continual process improvement and optimization using the metrics and automation tools previously implemented in stages two through four of the model. Optimizations reduce the cycle time for code releases; eliminate software errors and resulting rollbacks; and support more complex, parallel release pipelines for multiple, concurrent software versions, including A/B experimental releases.
At this stage, DevOps teams -- continuous delivery experts all adopt some form of DevOps structure -- have fully automated a code build, integration and delivery pipeline. They've also automated the infrastructure deployment, likely on containers and public cloud infrastructure, although VMs are also viable. Hyper-automation enables code to rapidly pass through unit, integration and functional testing, sometimes within an hour; it is how these CD masters can push several releases a day if necessary.
These teams use tools to improve software robustness, detect rare failure conditions before they affect users and automate complex big data systems. Tools for advanced continuous delivery, and continuous deployment, include Netflix's chaos engineering suite in the Simian Army and Genie, its big data orchestration service as well as sophisticated deployment stacks, such as Buddy and Pinterest's Teletraan.
