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
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