Continuous Delivery is often seen as a further development of Continuous Integration. The idea of a deployment pipeline is meant to help make the step from Continuous Integration to Continuous Delivery.
Figure 1 shows a deployment pipeline. The starting point of this deployment pipeline is the development team working together on a project. When several developers collaborate, so-called integration errors frequently occur. It’s bad when these integration errors are discovered only late, because fixing them in a later project phase is considerably more expensive than fixing them in an early phase. That’s why it’s important that an automated build runs after every code integration — one that checks whether the software can even be built, and also checks the software for errors. A so-called CI system helps with this.
Figure 2 illustrates the schematic structure of a typical CI system and the cycle that takes place within a CI system. The team makes changes. These changes are handed off by the team to a Version Control System (VCS). A build server continuously monitors the VCS and performs a build whenever changes occur. This build can succeed or fail. After a build, the result is archived by the build server and communicated to the development team.
The focus of such a CI system clearly lies with the developer. They can be satisfied when the CI server signals that the latest commit was successful. Unfortunately, this completely leaves out the user, who is more interested in new functionality. That’s why, in the next step, the software has to reach the user. For this, a release is needed. Such a release usually represents a major challenge, since it involves many stakeholders and often many manual steps, which leads to a high error rate. Unfortunately, many companies therefore often avoid releases, which is of course frustrating from a user’s perspective, since they have to wait a long time for many features.
As an enthusiastic software developer and consultant, I naturally can’t live with this state of affairs. That’s why, over time, I want to show you techniques for delivering new features promptly and continuously once they’re finished. In doing so, I’ll show you how I bring the principle of Continuous Delivery to life in my everyday work.
Retrospective (2026)
Looking back, this journey from CI to CD took far longer and twisted far more than I expected back in 2013 — manual releases didn’t vanish overnight, but over the following decade deployment pipelines, feature flags, and infrastructure-as-code turned “continuous delivery” from an aspiration into table stakes for serious engineering teams. The hard part was never the tooling, it was the organizational discipline to actually release what the pipeline said was safe to release. These days my focus has shifted again: I’m building AI agents that don’t just run the pipeline but reason about it — deciding what to test, what to roll back, and what to ship, with far less human babysitting than the CI servers of 2013 ever needed. In a sense, the dream I described here — getting finished work to users continuously and without friction — is finally being realized, just with an agent at the controls instead of a human watching a dashboard.