Continuous Deployment is the familial outcast that no one talks about in the CI/CD world. It’s the “Jon Snow” of the Stark family for you Game of Thrones fans. And … no spoilers … like Jon, a true hero with unrealized potential because of improper definition.
The Continuous Integration part of CI/CD is understood well enough from a developer’s point of view. When the code is changed by a single developer, an automated integration pipeline is run to build, scan, and unit test the code in a standard way, ensuring that everything still works along with all the other changes each developer is making. The automation, itself, provides benefits, such as consistent quality, efficiency, and standardization, yet there are more benefits to be gained when used continuously.
If a developer with an automated CI pipeline makes changes but doesn’t check-in and integrate frequently, the automated process will likely break for this lethargic developer. The benefits of CI come from running the integrations early and often, which will root out and, thus, force developers to resolve integration issues more quickly and efficiently. By identifying an issue earlier, the culprit is more apparent, namely the small bit of code just checked in, and the problem is stopped before it has a chance to grow.
It’s like my mother telling me to clean my room in eons past. “If you wait until it’s a big mess, then it’s going to take a long time to clean up. But, if you do it a little bit at a time each day, you’ll barely notice it.” Thanks for your technical advice, mom, although I ignored you at the time.
This brings us to the CDs. No, not Compact Discs or Certificates of Deposit…Continuous Delivery and Continuous Deployment. Unfortunately, the acronym is overloaded, and people define the distinctions differently. So, let’s first agree on the traditional definitions.
“…the traditional distinction is that Continuous Delivery is an automated process that stops just short of deploying the application into production, and Continuous Deployment takes the additional step of pushing changes into production directly…”
Continuous Deployment would be the operational part of CI/CD, such that any change made by development would be packaged, quality-tested, and deployed directly into production. Since most projects have some form of manual approval process before changing production, this message is a “bridge too far” and loses the audience.
Instead, the message becomes one of Continuous Delivery, where all the steps to package, test, and deploy are enacted and validated in a production-like environment. Thus, creating a deliverable that could be deployed to production if given approval, or could be discarded for the next package. Although not recommended, a Continuous Delivery pipeline can exist with a completely manual deployment process into production, but the presumption is that the deployment is also automated.
Thus, the traditional distinction is that Continuous Delivery is an automated process that stops just short of deploying the application into production, and Continuous Deployment takes the additional step of pushing changes into production directly…because you are a magical unicorn and just that confident in your automated processes that you can forgo any human review and intervention. Under this definition, I, too, shy away from Continuous Deployment, because I face the realities of change control boards and user acceptance contractual requirements.
But that’s a shame since the deployment process may be automated, but it is not gaining the added benefits of continuous implementations. Also, production-like environments are never 100 percent truly representative of production, so your final delivery could still face unencountered issues. And your actual production environment gains no continuous benefits at all.
So, let’s rethink Continuous Deployment by disassociating it with the development and delivery process of pushing code changes, and flip it to an independent, pull-based operational process. Applications are built with Continuous Integration and Continuous Delivery (CI/CD) pipelines to completely package and test the deliverable when changes are made. You can have, or forgo, a manual approval process as your agency requires. And there is a separate Continuous Deployment process that makes changes to production on an ongoing basis. Not different flavors of CD, but CI/CD & CD!
If this sounds familiar, good. Because this is a basic tenant of GitOps. GitOps redefines Continuous Deployment as a separate, automated process that compares the specifications of what should be running in an environment to the facts of that running environment, and then syncs the actual state to the desired state. These desired specifications are stored in a source code repository, aka infrastructure-as-code, which gains benefits of tracking changes and easier rollback should an implementation go awry. And the automation runs continuously, or at least frequently, regardless of definition changes, because real-world systems can drift away from their definitions for various reasons.
Like the CI/CD process, this GitOps’ definition of Continuous Deployment gains the benefits of both automating the process for consistency and efficiency, and continuous implementation benefits from rooting out issues. Regardless of how often developers integrate and deliver, there are benefits to reap by continuously monitoring and repairing deployments of the production environment. If automated repairs are a “bridge too far” then create an alert when drift is identified and have someone push a button after approval. It’s still beneficial.
“…let’s rethink Continuous Deployment by disassociating it with the development and delivery process of pushing code changes, and flip it to an independent, pull-based operational process.“
Automation benefits, source control benefits, continuous implementation benefits … and it doesn’t stop there! This definition of Continuous Deployment means you could unleash 1,000 Chaos Monkeys and your production environment will self-heal. When all infrastructure definitions are stored as code, you can centrally scan those configurations to enforce conformity, best practices, and other security concerns. You can simultaneously address network and hardware configurations through the same deployment process, which is another reason to separate the process from the frequency of code releases.
Worried about rogue admins with the keys to all servers? Lockout all admins and only let your CD system deploy to production through processes that are visible to everyone, and which must pass peer reviews and automated scans before being enacted. That’s enforcement for Separation of Duties that goes above and beyond just driving a wall between development and operations.
Changing the Continuous Deployment process definition transforms it from something near impossible to achieve and slightly undesirable to something with numerous benefits for everyone. So, let’s rethink and finally adopt Continuous Deployment.