Chances are you've had a continuous delivery project that failed. It does not matter that you announced to the world that it was a big success. You failed, and you don't want to admit it.
I might be wrong. If I am, you should be proud, since you are in the minority.
Why do so many attempts to implement continuous delivery fail? Some prerequisites and steps should have been taken in almost all cases. If you failed, chances are you missed some, if not all, of the commandments that follow.
1. Thou shalt be agile
Your organization must be agile before starting the journey to continuous delivery. Doing agile for the sake of having one more sticker that next to your PMI certificate is not the way to go. You must truly adopt agile. Otherwise, handovers between different departments will convert continuous delivery into eventual delivery.
2. Thou shalt refactor
Tests are flaky and fail for random reasons, and test execution lasts for hours instead of minutes. If an application is to pass through a continuous delivery pipeline every time someone makes a commit, the application needs to be designed with that in mind. Refactor your applications. Make them build-friendly, test-friendly, and deploy-friendly. Design them with CD in mind.
3. Thou shalt educate everyone
Letting other people take care of your continuous delivery pipeline is wrong. They don't know what you're developing -- but you do. More importantly, if you cannot write the delivery pipeline yourself, you will not be able to design your application to be CD friendly.
If you are responsible for the code of your application, you should also be responsible for writing the CD pipeline. It belongs to the team responsible for the application. Instead of creating an uber pipeline, spend your time educating the organization you work in.
4. Thou shalt be small
There is nothing continuous about big teams. Hoping that you will be able to continuously deliver code maintained by a huge number of people is optimistic at best. It cannot be done. You have to have small teams.
How big should a team be? That depends on the situation, but as a rule of thumb no less than four and no more than 10 people. Anything more than that is not a software development team but a school reunion.
5. Thou shalt practice test-driven development
Excluding exploratory tests, everything must be automated if you want to apply continuous delivery. But that is not enough. You will need to start writing tests before writing the code.
If tests are not present by the time you make a commit, execution of your CD pipeline will (almost) always <NOT?> be unsuccessful. Adopt test-driven development!
6. Thou shalt define thy CD pipeline as code
Code is easy to version and easy to put in Git; it can be easily reviewed, deployed, and so on. Most importantly, pipeline defined as code can reside together with the rest of the code it is testing, building, and deploying. Get a grip and learn to code.
7. Thou shalt have a fast pipeline
A CD pipeline must be fast. How fast? It depends on how much time a developer needs to get out of his chair, go to the kitchen, grab a coffee, and get back to his desk to start working on a new feature. Our work requires concentration, and we cannot focus on the task at hand if we are interrupted by notifications of a failed build. Pipeline execution needs to finish before we move onto a new task.
8. Thou shalt fix a failed pipeline as highest priority
There should be nothing more important than fixing a failed CD pipeline. When a build fails, you need to stop doing what you're doing and fix the problem. It will not go away, so best to get to it while it's still fresh in your mind and you can find the problem fast. A failed test needs to be fixed whether it requires a modification of the code under test or the test itself.
9. Thou shalt run the CD pipeline locally
A CD pipeline is the last line of defense, not a system that allows you to push code that you are not confident with. Run most of the pipeline locally before committing your code. Execute unit tests, build your artifacts, run (parts of) integration tests. We have the technology to do that and, if you follow the commandments, the pipeline is very fast, so you won't lose much time. Committing code that is not likely to work is a sign of disrespect to your coworkers. They might just pull your code and work on top of it.
10. Thou shalt commit only to the master branch (or use short-lived feature branches)
One of the main ideas behind CD (and CI for that matter) is to continuously validate that code is working as expected. If you are using branches and you are merging them into a master less than once a day, you are postponing CD. You might as well call it eventual delivery. The more time it takes for you to merge your branch, the more time you are in the dark.
What now?
While many companies claim to be doing continuous delivery, most are faking it. As with other popular practices, companies jump into it, try to apply it, fail to do it and, finally, change the rules and objectives so that they can put a sticker on it and inform the CTO that it's done. If you did manage to do it, congratulations: You you are a member of a very small and exclusive club. Welcome to the world of advanced software development.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
