Photo by Timothy Eberly on Unsplash
In my last article, CI/CD — A Purpose Exploring Approach — Part 1, I wrote primarily about Continuous Integration (CI) and how it is important to keep in mind that CI is not just a tool but a set of behaviors. The focus of this article will be the CD part of CI/CD.
As the software industry continuously strives for better ways to manage its product development processes, many have turned to use a CD approach to achieve faster and more efficient results. However, with so many different opinions on what CD actually is — and how it should be implemented — it can be challenging to understand the topic clearly. In this blog post, we’ll explore CD’s purpose to help clarify the matter.
I have heard many interpretations and names for CD, like Content Delivery or Continuous Development, but the most popular one is Continuous Deployment. Although it is connected or related to CD, it means something different; however, we will discuss this later.
Most people understand what Continuous Integration (CI) is and how it can be useful in a software project. However, there often needs to be more clarity about Continuous Delivery (CD). The CD concept involves expanding on CI by automating the release process for rapid and frequent changes that must be automatically tested before being pushed to production. This method allows developers to build, test and deploy applications quickly and ensure the changes are working as intended once deployed. By employing CD, projects benefit from improved communication, faster releases, and higher quality for products by finding errors sooner in the development cycle. Utilizing CI/CD together provides an ideal method for companies to release software regularly. So you see that the practice of CD is about automation, but it does not imply that you automatically have to push release to production. But let’s dig deeper and explore Continuous Delivery to understand why it is beneficial.
Jez Humble quotes the following about CD: “Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes, and experiments — into production, or into the hands of users, safely and quickly in a sustainable way.”
This sounds, of course, very nice and something most teams want to have, but how can we achieve safely, quickly, and sustainably?
Automation through build pipelines is essential to Continuous Delivery in software projects. Every step from check-in into mainline to production deployment should be automated — this doesn’t mean that human manual approval isn’t allowed, but the task itself should be automated. By automating tasks such as compiling code, running tests, and deploying binaries onto production servers, teams can ensure a high degree of repeatability, predictability, and reliability. This reduces errors and inconsistencies when releasing new features and products to customers. The CI/CD pipeline stages provide information on each check-in’s production readiness. With every successful stage, we gain a new layer of confidence that the code is ready to move into production. The earlier we can catch any issues that arise, the better. Stages such as code analysis and automated testing provide invaluable feedback on quality and stability at each step along the way. Furthermore, this is very sustainable since the knowledge of how to release software is back in the pipeline and not in some outdated documentation or, even worse, a single person’s head.
CI/CD Pipeline
Side note: in a modern Cloud Native approach, teams usually split CI and CD and use dedicated CD tools such as ArgoCD or Flux.
There is a second quite crucial quote from Jez Humble that describes CD: “Our goal is to make deployments — whether of a large-scale distributed system, a complex production environment, an embedded system, or an app — predictable, routine affairs that can be performed on demand.”
We can identify some specific goals by breaking down these two quotes.
CD allows software teams to make software deployments painless, low-risk events that can be performed on demand. It enables software teams to deploy better software with fewer errors and allows them to do so in a fraction of the time it would take with traditional software development practices. CD enables developers and operations staff to collaborate and rapidly deploy software, reducing the risk of breaking something or introducing a bug. With low-risk releases, software teams can rest assured knowing that their changes are tested and working accordingly before going live in production, creating a much smoother process overall. In the end, a release or deployment should be something really boring and not a fearsome event.
In a conservative release process, releases would be pushed out once per quarter. However, with the introduction of Continuous Delivery in software projects, releases no longer need to take months and incur expensive maintenance costs. When teams work together to automate the build and deployment processes, environment provisioning, integration, and regression testing — developers can now incorporate these processes into their daily work and remove these phases from the release process. Therefore, CD enables teams to bring products to market faster.
Continuous Delivery brings higher quality to software projects and shifts teams away from time-consuming, repetitive tasks for a more effective and efficient process. Automated tools enable teams to quickly test, discover potential regressions, and shift their focus towards user research and other high-level tests such as usability testing, performance testing, and security testing. Ultimately these changes result in better output, faster development cycles, and a shift of attention to areas that add immense value to the product while minimizing risk. Machines should do repetitive tasks; they can do that way better than humans.
By investing in build, test, deployment, and environment automation for software projects, we can make an upfront investment that will substantially reduce the cost of producing and delivering incremental changes. Automating many tasks with fixed costs associated with the release process helps create a small but clear impact on our business by allowing us to quickly and efficiently deliver new features and bug fixes. The result is drastically lower costs than a manual or semi-automated release process. We can keep our overhead expenses down by taking advantage of CD while still delivering high-quality software.
Continuous Delivery and Continuous Deployment are terms often used interchangeably in software development, but they have different meanings. Continuous Delivery is a mindset and process that enables the continuous and automated delivery of applications to customers. It automates the release processes so that code changes can be shipped quickly and confidently. On the other hand, Continuous Deployment is the practice of automatically deploying code to production after it has gone through a CI/CD pipeline. This requires more advanced automation tools and processes than what is typically used for Continuous Delivery and goes beyond just shipping the latest version of an app — it requires the deployment of code without any manual intervention. If teams employ Continuous Deployment, they — hopefully — also practice CI/CD.
Continuous Delivery is a software development practice in which code changes are automatically built, tested, and released for production. For CD to work, automation through build pipelines is essential. The goal of Continuous Delivery is to make small, incremental changes to software that can be delivered quickly and predictably with minimal risk in a sustainable way. However, CD does not mean you have to push your release artifact automatically to production. I hope this article clarifies the purpose of Continuous Delivery and how it can be achieved. Stay tuned for my next and last article on this topic, where I will write about why those practices are really paying off.
We at & are always challenging and improving our delivery processes since we believe this should be the standard in every efficient software development and delivery team. If you have any thoughts about this topic, please drop me a line :)
Here are some further readings and major influences for my blog article.