Once Continuous Integration is in place, you can focus on improving your project’s delivery process. Today I want to highlight the need for two foundational of a continuous delivery process: deployment and test automation.
Average Read Time: 2 minutes
Recall that Continuous Delivery is a practice that:
ensures our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.
Jez Humble
When delivery teams adopt Continuous Delivery, release candidates are deployed into test environments frequently. ‘Frequently’ usually means on each change or a small time interval like an hour. At a high-level this looks like:
Software delivery processes are built around a control loop that looks like:
This control loop exists no matter what software delivery process you use.
However, with Continuous Delivery, you will execute the Deploy and Verify steps with high frequency, often multiple times per day.
This is a huge increase if you’re accustomed to deploying a new release once per week and then having someone (or a team of people) spend three days checking the system’s correctness manually.
Do the math yourself and compare the number of times you deploy and test releases versus a continuous delivery model. Will you be increasing the execution of these processes 10x or more?
In order to adopt Continuous Delivery successfully, you must have efficient and robust deployment and verification processes. These processes must be practically and economically feasible to execute multiple times per day, so that you can realize the benefit of delivering functionality in small batches. In practice, this means automating that work in the main. The deployment side of this usually appears tractable, but the test side can look overwhelming.
Next week we’ll explore strategies for lowering the cost and risk of deployment and verification processes and provide a roadmap for incremental adoption. But I’ll leave you with another thought exercise for the weekend:
- What does it cost your organization to deploy and verify a single release right now in person-days of effort and calendar duration?
- Do those people enjoy that work? Would they prefer to focus elsewhere (exploratory testing, automation, risk analysis)?
Stephen
#NoDrama
