CI/CD: Automate the Release Chain
Together, CI and CD implement the changes necessary to make the DevOps philosophy of delivering value quickly a reality. Read our overview in The Key to Realizing Agile and DevOps is CI/CD.
Think of your CI/CD pipeline as an application for your applications—an application that moves changes to production quickly, safely and reliably. This article focuses on automating the release chain, i.e., automating the activities that occur when moving change from one point to another all the way through production.
The Toil Challenge
Software development and delivery are often slowed down by manual, repetitive activities that are devoid of enduring value and only scale linearly—classic toil. These under-documented, inconsistent release processes are prone to break frequently and simply take too long. Adding to the challenge, when inconsistent environments have to be built each time and are not fit for purpose, they cannot be stood up quickly and reliably. It’s no surprise complex as well as simple changes can take months to deploy.
Move from Change Complete to Change in Production Faster
Application Release Automation (ARA) helps eliminate toil. For starters, by automating manual, repetitive activities, organizations can rely on automation frameworks as ‘doers’ while keeping people as decision makers. And automating the entire release chain ensures that any change (new feature, code, bug fix, etc.) – in a known good state – can be moved sequentially and predictably through fit-for-purpose environments.
Build and Deploy a Reference Architecture
A proven method for taking a CI/CD approach from concept to reality includes building and deploying the right reference architecture for your organization that automates the release process. For example, the CI/CD conceptual reference architecture below defines the four layers of the stack through which change (code) moves from left to right in the SDLC—from source code management to building and continuously integrating software through managing configurations and dependencies, and orchestrating releases. In short, the reference architecture is like an inventory of everything required to move change from one point to another.
A clearly defined reference architecture helps:
- Remove manual, repetitive activities
- Optimize human efforts
- Accelerate the time from “change complete” to “change in production”.
Once the reference architecture is defined, prototype, design, then pilot a small, skinny safe version you can deploy quickly. Prove you can move all the way from implementation of code through environments, implementation and into production. Apply lessons learned from the pilot before onboarding applications across the portfolio.
Rethinking Environments – Infrastructure as Code
The concept of infrastructure as code says to tear down and build environments every time one is needed. Without automation, this process would be expensive and take far too long. But automating the ability to stand up an environment can be a game changer—imagine pushing the same button every time, only adding a couple of minutes to the process.
Three key enablers of the infrastructure as code concept include:
Create a model, or template, to define what an environment looks like, what’s in the environment, and what constitutes fit for purpose. Store this description in the library and pull it every time you need a new environment.
Use containerization tools, like Docker or Kubernetes, to stand up an environment in predefined memory space. This is where you store the items you need. Because you can configure the container, you can plug in and access everything in it without having to configure every time—another way to speed up the deployment and release process.
- Dynamic Provisioning
With dynamic provisioning, you only pay for what you use when you use it. This method also removes a lot of the overhead involved with regulating, managing, scheduling, and sharing environments. Further, dynamic provisioning removes many of the problems that come with managing both test and production environments to manage pipeline. Provision the environment you need, stand up the empty box, leverage your templates, put code in the container, then click to deploy.
By passing all required code and infrastructure changes into an environment in real time, the snapshot you drop into that environment will be exactly what you need to go all the way to production.
The New Normal
In reality, these small pilot projects are actually helping to define a new capability of how you move change to production. Essentially you are achieving a new normal. Think of CI as a capability and CD as a decision. For example, if you are going from development to production with one click of a button, the decision should occur with no technical barriers. The capability has been built and risk-based decisions can be made whether or not to execute. Humans retain the ability to decide. The infrastructure enables the ability to do.