Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
There’s often confusion between Continuous Integration, Continuous Delivery, and Continuous Deployment: let's break down the key differences and why they matter.
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!
As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇
Now, let's dive into today's micro-topic!
In short
🪵 Trunk-Based Development (TBD) is a source-control branching model, where developers collaborate on code in a single branch.
🔄 Continuous Integration (CI) is the activity of very frequently integrating work to the trunk of version control and verifying that the work is, to the best of our knowledge, deployable to production.
🚚 Continuous Delivery (CD) is the engineering discipline of delivering all changes in a standard way safely.
🚀 Continuous Deployment takes things a step further. Once a change passes all automated tests and quality checks, it’s automatically released to production. There’s no human intervention between the development and release stages.
Trunk-Based Development: Changes Goes to Main Branch
Trunk-Based Development (TBD) is a source-control branching model, where developers collaborate on code in a single branch (trunk/master/main), implying a team workflow where changes are integrated into the trunk with no intermediate integration branch. The two common workflows are making changes directly to the trunk or using very short-lived branches that are created from the trunk and integrate back into the trunk a day at most.
Some key improvements when implementing TBD are:
Smaller changes
We must test
Better teamwork
Better work definition
Replaces process with engineering
Reduces risk
You can deep dive more at trunkbaseddevelopment.com.
Continuous Integration: Main Branch is Always Deployable at Any Time
Continuous Integration (CI) is the activity of very frequently integrating work to the trunk of version control and verifying that the work is, to the best of our knowledge, deployable to production.
The minimum activities required for CI are:
Trunk-based development
Work integrates to the trunk daily
Work has automated testing before merge to trunk
Work is tested with other work automatically after merge
All feature work stops when the build is red
New work should never break existing work
You can deep dive more at minimumcd.com.
Continuous Delivery: Deploy in an Automated, fast and standard way
Continuous Delivery (CD) is the engineering discipline of delivering all changes in a standard way safely. It covers a broad spectrum of activities depending on what is being delivered. However, there are behaviors and abilities that must be met in every context to qualify as “continuous delivery”
The core idea is that you don’t let technical debt or unfinished work accumulate; the software is continually improved in small increments. This keeps the team flexible and responsive to user needs, and minimizes the risk of releasing a broken product.
A simple trigger (like a git tag or GitHub release) can be used to trigger the release: while the trigger to start the release process is manual, the release process itself is fully automated.
With CD, we can start making a difference between a deployment and a release:
a “deployment” is the technical act of delivering software to a host environment
a “release” makes a new feature available to users
Some of the key activities required for CD are:
Use Continuous integration
The application pipeline is the only way to deploy to any environment
The pipeline decides the releasability of changes, its verdict is definitive
Production-like test environment
Continuous Deployment: Automatically Deploy Every Time the Main Branch changes
On the other hand, “Continuous Deployment” takes things a step further. Once a change passes all automated tests and quality checks, it’s automatically released to production. There’s no human intervention between the development and release stages. This practice demands a high level of confidence in your test suite and pipeline, as you’re constantly delivering updates to users.
In essence, Continuous Deployment is basically Continuous Delivery with a fully automated release. It automates the final step, ensuring that any code change that passes the pipeline will immediately go live.
In the end, we can now understand that all those methodologies are strongly connected to each other, in a strong relationship that implies progressin in steps when moving from long-living feature branches to CI/CD.
Until next time, happy coding! 🤓👩💻👨💻