Continuous delivery is the single most important step in agility. Regardless of whether you do big releases or not you should always build software incrementally so it is always in a releasable state. Why? Because the only way to know if code will work in a system is to test it in the system. This is at the very core of XP and Agile. Here are seven practices for continuous delivery.
1. Think about automation from the very beginning
Project automation can’t usually be an afterthought. We have plan for automation in our design from the get-go. We do this by validating our architectures and designs are testable and easy to automate. This involves isolating business logic, building pluggable components, and making code within each component simple to understand.
2. Implement a one click build
The build has to be easy to use. It has to be fast. It has to provide good diagnostic information if something goes wrong, and most importantly, it must be trustworthy. As soon as new code is checked-in to the repository from a developer’s working copy of the system, the build automatically runs along with a full suite of unit tests to validate direct dependencies. If that passes, the new code is automatically promoted to the build server and either the entire build is run immediately or queued for later and a partial build is run immediately.
3. Write testable code
Of course, the key to building an easy-to-automate system is to write testable code. Too often, developers write tests after they write code only to discover that their code is untestable and has to be rewritten. Developers should avoid practices that yield untestable code.
4. Write the test first
The best way to write testable code is to write the test first. By writing the test first and then creating production code to make a failing test pass, we are assured of always writing testable code and end up writing code that’s more focused and succinct. When done correctly, test first development helps developers write cleaner code with less effort and more support.
5. Strive for 100% test coverage
Another advantage of doing test first development is that all production code we write is inherently about making a failing test pass so we always get 100% test coverage. If you don’t think trivial code should have unit tests then I won’t argue with you but complex code or code with multiple paths through it should be covered by tests at the unit level.
6. Remove human intervention
The key to doing continuous delivery successfully is to remove all manual processes from validating a release candidate. When we can do this we can drop the cost of validating release candidates to nearly zero and the build becomes a rich source of instant feedback for the team that they use all the time.
7. Give back control of releases to the business
Continuous delivery doesn’t mean you have to release all the time, it means your system is always releasable. When new versions are released should be a business decision based on sales cycles, maintenance plans, and other business factors. When we practice continuous delivery we are giving control of when we release back to the business where it belongs.
Continuously delivery fundamentally changes the dynamic of developing software and turns the build into a source of rich feedback for developers. If you’re building software incrementally then code should be integrated as it is being built. The way to reduce the risk of building features is to integrate them into a working system as they are being built.
Previous Post: « Seven Strategies for Creating Better Names
Next Post: Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software is Here! »