CI & CD
This article is a summary of my understanding and use of Continuous Integration, Continuous Delivery and Continuous Deployment. There are several interpretations of these terms, some of which I'd argue are more correct than others. My interpretation is based on my experience and the processes I've followed and also articles by companies like AWS and by experts in the field like Dave Farley.
Continuous Integration
I always use a trunk-based approach, whether that be when building software, pipelines or Infrastructure as Code (IaC). I usually use short-lived feature branches rather than committing directly to the main branch, especially when working with others. I never use long-running branches, opting for feature toggles to manage the rollout of new features.
I then typically use pull requests to:
- Verify the changes are the ones I intended
- Run automated tests
- Get feedback from others
Once the pull request is approved, I merge it into the main branch, usually using a squash commit. This triggers a build pipeline that will also run automated tests but it also builds packages, containers, etc... Once the build is successful, the deployment phase(s) of the pipeline begin.
Continuous Delivery
Every successful commit to main not only triggers the build process but also the deployment phase(s) of the pipeline, ultimately pushing code all the way to production.
Regardless of how many environments I have in place, the process tends to be the same for them all:
- If environment is subject to change management, raise a change request
- Deploy the change to the environment - if code:
- Database changes first
- Code changes second
- Run automated tests (these may vary between environments)
- If no automated tests exist, show a manual approval gate
- Close the change as successful or failed as appropriate
If a deployment fails, sometimes excluding the development environment, then all changes are automatically reverted. This is to get the environment back to a known good state as quickly as possible.
Continuous Deployment
Continuous deployment is effectively the same as continuous deliver but with any manual gates removed. When building pipelines, I typically build them all to support continuous deployment but, when automated testing isn't available, revert to using a manual approval gate.
I'd say the biggest barrier to going to continuous deployment is the lack of automated testing or at least a lack of trust in your automated testing. If you can't trust your tests to catch issues, you can't trust your deployment to be successful. Once you have highly reliable and high confidence (and ideally high speed) automated testing in place, you can move to continuous deployment with confidence.