CI/CD: Continuous Deployment or Continuous Delivery?

I've heard the terms continuous deployment and continuous delivery used interchangeably though they are not the same. From what I can tell, it's pretty common for them to be understood as synonyms despite this. This post will simplify what CI/CD means and clarify their differences and benefits.

First things first: What is Continuous Integration?

At its simplest, CI means integrating code changes into the main branch often. It's typical, though, to connect your version control system with a continuous integration server, which will automate your tests and provide you with performance metrics for your project. You might add tests for code quality, test coverage and styling on top of your unit and integration tests - but if any pull request doesn't meet your threshold it cannot be added to the main code. Only code meeting your teams standards will be automatically integrated into main.

💡 Some devs like to use an extreme feedback device (XFD) as a tangible representation of their project's health. I've heard of traffic light displays, water fountains, Mr. Potato Heads and, rocket launchers, being used to indicate the build status.

Popular CI tools include Travis CI, Circle CI, and Jenkins. Up until now I've used Travis CI on all my CI repos; it's free for open source projects and was the most used CI tool on GitHub in 2017.

Benefits of CI include getting automated (frequent) feedback, having confidence in the code on your main branch, and increased collaboration, with each person working from the latest version - this also mitigates the risk of pulling masses of conflicts with a single git pull. Yay!

Continuous Delivery

With continuous delivery, you deploy your features to production manually, and, you may use feature flags to deploy code without releasing it to the public. This offers some safety to phase in changes especially if your new features are likely to cause a big impact - you can spread the risk! With continuous delivery it's likely that features are released less often (daily, weekly, monthly...) than they're integrated with the main branch.

Continuous Deployment

With continuous deployment, your code will be deployed automatically whenever it's integrated into the main branch. You'll likely want good tests to be happy about automatically releasing your code so this approach lends itself to TDD. Your rate of integration should not be affected - code is deployed little and often.

On some of my projects I've set up Heroku to listen to my GitHub repo. When Travis CI completes it's check and goes green, my updates will automatically go live: that's one less thing for me to do plus it's super satisfying.

"Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements." - Carl Caum

I like to ask devs about their CI/CD practise to get an insight into their team. OK, It wouldn't be appropriate to expect continuous deployment everywhere (think healthcare or aviation), but to me, continuous deployment is The Dream: done well, it indicates a team who are confident in their code base, are relaxed about releases (since they happen all the time, they're no big deal), and who operate smoothly.

_{Edit: update on 13/09/23 to refer to the main branch which is now standard usage.}