Dave Farley

I coined the term "deployment pipeline," so I can say with some authority that the idea has suffered from semantic diffusion. As the concept spread, it became diluted into something else entirely.

Today, having a build script or running an instance of Jenkins does not mean you are practising Continuous Delivery.

If you want to reap the massive benefits of CD, you have to stop making these three fundamental mistakes with your pipelines:

1. You still have manual steps after the pipeline finishes: A core defining characteristic of a deployment pipeline is that it must be definitive for release. If your pipeline passes all its tests, you should be safe to release your changes into production with zero further work. If your pipeline goes green but you still need manual sign-offs or manual testing phases, you do not have a true deployment pipeline.

2. It is not your only route to production: I once consulted for a company that had a special "emergency release" process that bypassed all automated testing so they could deploy in under an hour. This is insane. When disaster has struck, and your system is collapsing, that is exactly when you need the protection of your tests the most! Bypassing the pipeline in an emergency is like pouring petrol on a fire. Every single change, whether it's a code update, a spelling correction, or an infrastructure tweak, must go through the exact same pipeline.

3. You accept the excuse that some things are "too difficult to test": Many teams fall back on slow, unreliable manual testing because they believe certain components simply cannot be automated. I have learned to be highly sceptical of this. If something is difficult or impossible to test, it is not a testing problem; it is a design problem. You need to use testability as a driver for your software architecture. If you modularise your design, you can isolate components and fake inputs to make automated testing fast and reliable.

When you treat your pipeline as the definitive, single route to production, it acts as a forcing function. It guides your decision-making, forces you to improve your software design, and leads you toward a much more effective engineering culture.

#ContinuousDelivery #DevOps #SoftwareEngineering #Automation #TechLeadership #CICD

Are we writing fiction, or are we practising engineering? If you know my work, you know I generally prefer data and science over fiction. But Gene Kim’s fantastic novel, The Unicorn Project, made me realise something...

Gene’s "Five Ideals" for rescuing broken software projects map absolutely perfectly onto the empirical, scientific truths of Continuous Delivery and Modern Software Engineering.

Here is how those 5 Ideals translate into real engineering practice:

1. Our real enemy is complexity. You can't go fast or safely if every simple change requires spelunking through 14 different subsystems. As I always say, the quality of a system is defined by how easy it is to change it. If your system is hard to change, that's a bug.

2. "Joy" isn't a word engineers use at work very often, but there is certainly no joy, and no flow, in 45-minute builds, flaky tests, and constant friction. Software development is a flow-based discipline optimised for learning. We use Continuous Delivery (fast tests, small batch sizes, reliable pipelines) to systematically remove friction so developers can actually focus.

3. Improving the work is the work. In badly run organisations, refactoring, fixing automation, and improving the deployment pipeline are treated as "nice-to-haves" when we have spare time. We never have spare time. Fixing a flaky test or eliminating a manual process today isn't just morally good, it's economically stupid to do anything else.

4. This ideal frightens ineffective leaders because it sounds soft. It isn't. Engineering relies on the scientific method: make a hypothesis, run an experiment, and learn. You cannot run experiments or surface defects in fear. If you punish mistakes, people will hide reality, and reality will eventually bite you with a catastrophic failure. Technical safety (working in small steps, fast automated testing, easy rollbacks) creates cultural safety.

5. Customer focus is the ideal that gives the other four their purpose. All the Jira tickets, architecture diagrams, and status meetings ultimately only exist to serve a real human need. Our job is about understanding the problem we are trying to solve, much more than it is about typing code. Especially with the rise of AI, skills in understanding and decomposing customer problems will outlast any knowledge of a specific API or framework.

High-performing teams reduce complexity, get fast feedback, improve continuously, and stay connected to real value.

How does your organisation stack up against these 5 ideals?

#SoftwareEngineering #ContinuousDelivery #DevOps #TechLeadership #Agile

If you’re not treating software development as an scientific discipline, with experiments, feedback loops, and measurable outcomes, then you’re not a software engineer…

I couldn't agree more with Andrea Laforgia's comments in this post. Saying "we must review every AI-generated change" is simply not enough, we can't keep up that way, we have to find alternatives that can keep pace with the rate at which AI can generate code. This doesn't mean that simply trusting the AI is an option either! We have to find better ways to verify that we got what we wanted from the AI assistants.
I have a YouTube video on this topic coming soon on the Modern Software Engineering Channel.

Thanks Andrea Laforgia for, as usual, a thoughtful, insightful post.

Forget about deploy speed. Continuous Delivery is about having engineering confidence so high that the release becomes boring.