This article draws on an interview with Eberhard Wolff, software architect and Fellow at innoQ, originally published by TheServerSide.com, discussing themes from his book A Practical Guide to Continuous Delivery.
The CI Server Is Not Enough
Installing a CI server such as Jenkins or Concourse is now standard practice for any team that claims to be doing DevOps. But having a server that runs a job every hour or two is not the same as practising continuous integration in any meaningful sense.
“I’d say that continuous integration is nowadays a commodity, up to the point where people actually have forgotten what it actually means. People are using integration servers just to do a regular compile,” said Eberhard Wolff, a software architect and Fellow at innoQ, in an interview with TheServerSide.
Wolff points to a pattern he sees repeatedly: a team creates a long-lived feature branch in their Git repository, works on that branch independently for weeks or months, and uses the CI server only to compile that branch. The CI server is doing work, but the team is not integrating continuously — they are integrating rarely, in large batches, which is the opposite of what CI is designed to achieve.
“They’re missing the original point about continuous integration. That’s the state we are in. People have forgotten about the original ideas behind CI.”
— Eberhard Wolff, innoQ
True continuous integration requires that every developer integrates their work into a shared mainline frequently — ideally at least once per day — so that integration problems are caught early and in small, manageable increments. A CI server is a tool that supports this workflow; it cannot create the workflow by itself.
Continuous Integration and Effective DevOps
The relationship between CI and DevOps is more than superficial. DevOps as a practice aims to shorten the feedback loop between writing code and running it in production. CI is the first stage of that loop — catching defects before they accumulate. Without genuine CI (frequent integration into a shared branch, automated build, automated tests), the later stages of the pipeline — continuous delivery and continuous deployment — become unreliable.
Wolff argues that the CI server is only one small piece of the puzzle. The larger pieces are comprehensive automated testing and the automation of manual processes that would otherwise interrupt the pipeline.
The “Continuously Interrupted” Anti-Pattern
One of the most instructive concepts in Wolff’s thinking is what happens when a pipeline is technically automated but still requires a human to approve or perform steps along the way. He describes this as turning “continuous delivery” into “interrupted delivery.”
“Just having Jenkins and just having a deployment pipeline is not the key challenge. The key challenge is going into production without sign-off,” Wolff said.
When Wolff works with new customers, he starts by asking what the biggest impediments to running their continuous delivery pipeline are. The answer is almost always the same: a manual process — frequently in the user acceptance testing (UAT) phase — that requires a human to review and approve before the pipeline can proceed. That single manual gate can negate much of the speed and reliability benefit that automation is supposed to provide.
This does not mean that all governance and oversight should be eliminated. It means that wherever possible, checks that currently require human intervention should be replaced with automated tests that can make the same determination faster and more consistently. The goal is to shift quality assurance left — catching problems earlier in the pipeline through automation rather than relying on a human reviewer at the end.
Automation, Testing, and Confidence in Deployment
There is an important dependency that is easy to overlook: you cannot safely automate deployment unless you have a comprehensive automated test suite. Without tests that reliably catch regressions, removing human sign-off from a deployment pipeline is genuinely risky. This is why Wolff treats testing and automation as inseparable topics.
A robust test strategy for a continuous delivery pipeline typically includes:
- Unit tests — fast, isolated tests that verify individual functions or classes and run on every commit.
- Integration tests — tests that verify how components interact, including databases, message queues, and external services.
- Acceptance tests — automated tests written in terms of business behaviour (often using tools such as Cucumber or Gherkin) that replace or supplement manual UAT.
- Performance and security tests — automated checks that can be run on a schedule or as a pipeline stage to catch non-functional regressions.
Only when this test pyramid is in place can a team confidently remove the manual sign-off gate and allow the pipeline to deploy to production automatically.
A Practical Approach: Tools, Examples, and Hands-On Guidance
Wolff’s book, A Practical Guide to Continuous Delivery, is designed to be less theoretical than much of the existing literature on the subject. Rather than explaining concepts in the abstract, it covers specific tools — including Chef, Docker, Vagrant, Jenkins, and SonarQube — and provides concrete examples of how to use them to build a real continuous delivery pipeline.
“I talk about specific tools, I provide advice about how to use them, I have examples of how to use the tools,” Wolff said. The goal is to give readers enough practical experience with individual tools that they can assemble a working pipeline themselves, rather than understanding only the theory behind why such a pipeline should exist.
This practical orientation matters because one of the common failure modes when adopting DevOps practices is that teams understand the goals — faster delivery, fewer defects, higher confidence — but struggle to translate those goals into a working system of pipelines, scripts, and configuration. A tool-focused, example-driven resource closes that gap.
Key Takeaways for DevOps Engineers
- A CI server is a prerequisite, not a solution. Running builds on Jenkins or any other CI platform does not make your process continuous integration unless developers are integrating into a shared branch frequently.
- Long-lived feature branches undermine CI. The longer a branch lives in isolation, the larger and riskier the eventual merge becomes. Trunk-based development or very short-lived branches are the approaches most compatible with genuine CI.
- Manual gates break the pipeline. Any step that requires a human to intervene — approving a deployment, executing a test case by hand — introduces delay and variability. Identify these gates and replace them with automated equivalents.
- Automation requires test coverage. Before removing human oversight from a deployment pipeline, invest in a comprehensive automated test suite. The tests are what make automation safe.
- DevOps is defined by outcomes, not tools. The goal is to reduce the cycle time from code commit to production deployment while maintaining quality and reliability. Tools support that goal; they do not achieve it automatically.