DevOps has a bunch of new goals, practices, and terms. Many of which are mixed up, misused, or just plain wrongly defined by people who do not internalize the specific differences due to the very technical nature of DevOps. Here we break down three of the most common terms in layman’s terms and try to provide a clear example that delimites each of the three.
Continuous Integration
Continuous Integration specifically speaks to the process of constantly combining a change set into the source of truth. Typically this is a developers pushing changed code to a shared remote. For example a team of 12 developers could work on 18 different GiT branches containing over 67 commits per day. That is a lot of changes! Over the course of a work week the number of changes commits could easily top 300 commits. When the time comes to deploy a new release all these changes haves to be merged into a single branch. As if the release was not stressful enough the team also must ensure it all works, together. Those 300+ changes per week will, I promise, result in problems. A problem that means staying late, dealing with the pressure from the business owners, stressing due to fearing release days, the business owners not trusting you nor your team’s ability to deliver on time and on target. No one wins in this type of situation.
Enter Continuous Integration. Take that same team of developers, in that organization, but instead of waiting until release day to combine changes together multiple times a day. The changes are continuously integrated into a target GiT branch to ensure that merge issues (when a file is changes in two ways from different people) are dealt with immediately when the changes are made. Not when trying to deal with a release. (This is part of the ‘shift left’ concept in DevOps.) When release day comes around the changes are already merged and issued corrected long before the release event occurs.
Continuous Delivery
Continuous Delivery, as a concept, is the logical progression from nothing to Continuous Integration with an additional step towards full automation. In order to provide Continuous Delivery proper automated quality assurance steps such as automated testing, monitoring, altering, and metrics need to be in place. Why? because Continuous Delivery means any changes applied to a piece of software are constantly ready for delivery. At the push of a button the software should deploy to a production environment. You 100% must have a high level of assurance everything works, nothing breaks.
The way I mentally separate Continuous Delivery from Continuous Deployment is to think of it as a UPS package: Delivery is on your doorstep after being paid for, processed, tested, handled, and ready to be used; Continuous Deployment the package is unpacked, installed, and being used.
Continuous Deployment
Which brings us to the last of our concepts for today: Continuous Deployment. Of the three I think is the easiest to define and conceptualize. As the name implied Continuous Deployment is the process of continuously deploying a software to a place where user (read: real people) can use the application.
Continuous Deployment is the Holy Grail of automation and one many businesses have the hardest time adopting.Buty is seems so easy after achieving Continuous Integration success. So why is delivery so hard to accept? Well, because it means very-single-commit to the deployment branch get deployed. No human intervention. No quality gates. No change control committee approvals. If a change is received, a change gets deployed.
An Example Implementation Path
As a developer you are working on feature-1234. As part of the workflow you hide feature-1234 behind a feature flag in the application. Before lunch and at the end of the office day you push your changes and correct any merge conflicts immediately. This is Continuous Integration.
As part of the automation policy within your organization you must create unit tests, integrations checks, and end-to-end scenarios in order for the commit to be allowed into the origin repository. If automations all pass the commit is allowed to be applied to the source repository. This is Continuous Delivery.
Given the above the works stably and the organization sees the value in receiving end-user feedback quickly and trust the engineering teams to keep a tight lid on outages and minimize the blast radius when something does do wrong (thus allowing the organization to get ahead of the competition). With the assumption all the automated quality assurance and test metrics pass, the code change is immediately deployed to a live production environment. This is Continuous Deployment.
Resources
- Git Flow
- DevOp Maturity Survey
- https://stackify.com/continuous-delivery-vs-continuous-deployment-vs-continuous-integration/
- https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd
- https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff
- https://semaphoreci.com/blog/2017/07/27/what-is-the-difference-between-continuous-integration-continuous-deployment-and-continuous-delivery.html
Conclusion
Dev(Chat/Git/Sec/No)Ops is a ever changing place. The terms and acronyms quickly become confusing. I hope this helps clear up some of the most commonly used phrases.
It is not easy, but if you internalize the fact that ‘Every business is a software business’ (Watts S. Humphrey) the sooner we realize software engineering is like any other form of engineering the better. We need to apply the same principles in order to reap the same rewards. Greater visibility, stronger products, flexible internals, faster velocity, and the respect of being a craftsmanship career. This allows organizations to be excellent; who doesn’t want to be excellent.
With that what do you think of DevOps? Do you have experience in organizations implementing DevOps/CI/CDs? What is your opinion on the perceived disruption to organizations and markets?
One thought on “What’s the difference: Continuous Integration, Continuous Delivery, and Continuous Deployment.”