At the heart of continuous delivery is a fast feedback loop that immediately shows developers the effects of their work. Mistakes are found and fixed quickly, while beneficial changes can be released and deployed to customers without having to wait for a distant future release date. This rapid feedback helps build an organizational culture of learning and responsibility.
The foundation is continuous integration: whenever developers commit new changes into version control, fast automated tests run in a production-like environment to ensure that both the code and the system as a whole are safe to deploy to users. In many cases, deployment is triggered automatically if tests have passed. If not, the team knows that the system is in a deployable state and initiates deployment manually according to their schedule.
Most of the time, the fast feedback loop gives developers the go-ahead to continue working on their task, or to move on to the next task. If we can verify and deploy our changes within minutes, we preserve the state of flow and can continue to work very effectively.
Then, there are times when the feedback loop produces some new information that requires action. For example, we may receive reports of elevated error rates, or observe a shift in user engagement after we’ve deployed a change in a shopping cart design. Because continuous delivery enables frequent system updates, the changes we make are small and the feedback loop is set to give us small pieces of information. It’s much easier to understand the immediate feedback that arrives after deploying a few hours’ worth of work than the slow feedback that arrives after three months of an all-hands effort.
Here are some specific examples of learning through continuous delivery:
- Continuous integration leads developers to fix issues quickly. They learn about problems “just in time” — not days or weeks afterwards, when QA finally detects the problem and the code is no longer fresh in the developer’s mind.
- Fixes are small and their takeaways are easy to document. Good documentation helps build organizational knowledge. When developers know what’s gone wrong in the past, similar problems can be detected more quickly, or avoided altogether.
- With fewer significant failures to clean up, the organization can focus its efforts on experiments and metrics-driven learning, for both product feature development and internal processes.
- Feature flags, sometimes also called feature toggles, allow us to iteratively build complex new features in production and validate them by talking to customers early on. This process, sometimes called continuous product discovery, helps us avoid investing in building expensive things that no one wants. We can focus on the features that do have value to customers, and evolve them until customer needs and business objectives are met.
- Continuous experimentation leads to continuous learning. Developers share what they’ve learned in internal company “show and tell” events and demos, which elevate the skills of the whole team and encourage further sharing. In this environment, peers routinely push each other forward.
- In continuous delivery, everyone owns the quality of their work. Every developer adopts test-driven development, learns how to use logging, and builds monitoring metrics for the components they own. Code review is standard practice in every pull request. When collaboration is second nature, knowledge gets organically transferred between coworkers. As a result, everyone deploys to production, and there’s no distant authority that locks knowledge and processes.
- Through small changes and distributed ownership, the team is highly collaborative and members trust each other. So when things go wrong and there’s an outage, the team tends to approach it as a learning and improvement opportunity, rather than blaming each other in a post-mortem.
Large projects developed in isolation can be hampered by technical roadblocks and long turnaround times, and, even when deployed, they may not meet users’ needs without feedback and additional fixes. A continuous delivery system supports fast, iterative software development — but only if we use it well. It’s our responsibility to understand that each iteration is an opportunity for learning, and to apply that learning in our work.