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?
Top comments (13)
Your images and captions made my day. 😂
I have a different definition for each of the these steps.
First, for the Continuous Integration each commit is first run through a bunch of tests before actually merging to the intended branch if these tests passes then the changes are merged.
Second, the Continuous Deployment can be to a test or QA site for the users to see and approve the changes.Though this can be automated by integration and functional tests, it's always good an actual user tests the new changes for feedback and unseen bugs.
And then finally comes Continuous Delivery which would be pushing the changes to production once they're tested and approved.
The first two sound reasonable; the third one requires an approval process. Assuming this is a manual process it runs counter to the name.
Continuousis without interruption, wherein your example (if indeed a manual approval) would not be.This is one of the challenges for the DevOps community. How to clearly and sharply define terms, concepts, and goals such that the community accepts them and the business stakeholders can conceptualize them.
I do like the concept of assaulting the the change set to the test and quality checks BEFORE being merged into a target remote branch. Works well with 'branch often' workflows. With a little alteration it would probably work well in a 'trunk' centric flow as well.
Thank you for the input Jefry. I love talking tech. MEssage me some time.
Excellent article (images were good too 😂).
I’m currently exploring the DevOps world and I wonder: is “continuous delivery” to a non-production environment a thing? I mean, having an environment where actual users can experience the latest changes without putting in danger their everyday operations.
Great question Paula, welcome to the wide (but sometimes ambiguous) world of DevOps.
To answer your question: Yes, I would call that a partial continuous deployment.
To alleviate the danger to users have the development team hide new features behind a 'feature flag'. An easy way to do this is have features release version based. The code is on production but not accessible until the environment's version is incremented.
Hey David, a very well-written article. Kudos! As you said, continuous deployment is still not as widely accepted as Continuous Integration and Continuous Delivery. In that case, Continuous testing comes into play. With ongoing efforts to efficiently automate the whole SDLC, continuous testing will be critical. You might like to check out this blog that talks about how Continuous testing reduces software failures. Give it a read share your thoughts on it. Here is the link: cigniti.com/blog/how-continuous-te...
Glad you liked the article Hemanth. I'll give the article you provided a look, thank you.
Nice post.
For whatever reason, I reached peak clarity on this subject matter when I stopped trying to keep up with the trends on a granular level.
Now, if I were more specialized in this regard, I’d want to understand the grammar, but in terms of my day to day, I’ve happily accepted a less detailed mental model/vocabulary.
Really nice explanation!
I just use all three randomly in conversation lol
Well written, and this ...
Know the pain of adopting CI, well worth it though
Very true. Automated build / deploy processes changed my life.
Was enjoying the article already but had to scroll down to comment this early - I LOVE the images and captions, had me in tears. 😂 ok back to the article...