You’ve worked with software development and explored any sort of automation, you’ve certainly come across the acronyms CI and CD. While the CI, continuous integration, aspect is fairly well understood by software developers as a part of the development process, CD is more mysterious. In part, this is because it crosses over into the realm of “operations” and in part, this is because it can refer to continuous delivery or continuous deployment. The image below can serve to orient you to the landscape and we’ll get into a bit more detail below.
Continuous integration is focused on automating the building of software, hopefully, but not always with testing built into the process. In the graphic above the flow is create some initial code (or modify the existing, stored code), run tests on the code, and if the tests pass, update the codebase. This can cycle through multiple times. The stored code – aka “artifact” – could be manually uploaded somewhere to run, but in a world where automation is increasingly the goal, both CDs streamline the deployment process.
Although these two terms are different, their differences really come at the end, which we will get to at the end of this. The CD process is much like the CI process, but now the idea is that testing is going on in the environment that includes any other interactions that will be needed for the final presentation of the code. Much like CI, this could go through cycles. If all tests pass, the new code is assigned a version and finally, we get to the difference between CD and … CD. Continuous delivery simply means that there is a manual step – a final check- that will release the code into the wild. Continuous deployment automates this last step with the assumption that if the code passes the CD stage tests it is good to go.
Want to dive a bit deeper to see how this works in real life? Check out next article plus video on CD using the open source Gitlab and Kubernetes.