How building software in a fast feedback loop helps push the whole team forward. At the heart of continuous delivery is a fast feedback loop that immediately shows 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 and responsibility. developers learning The foundation is : 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, 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. continuous integration deployment is triggered automatically 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 — not days or weeks afterwards, when QA finally detects the problem and the code is no longer fresh in the developer’s mind. learn about problems “just in time” . 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. Fixes are small and their takeaways are easy to document With fewer significant failures to clean up, the organization can focus its efforts on experiments and , for both product feature development and internal processes. metrics-driven learning 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 , 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 product discovery 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. Continuous experimentation In continuous delivery, . 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, . As a result, everyone deploys to production, and there’s no distant authority that locks knowledge and processes. everyone owns the quality of their work knowledge gets organically transferred between coworkers Through small changes and distributed ownership, the team is highly collaborative and . 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. members trust each other 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. Read more: What’s the difference between continuous integration, continuous deployment and continuous delivery? What is proper continuous integration? Why we need continuous integration At Semaphore, we’re on a mission to make continuous integration and deployment fast and easy. If you’re new to Semaphore, learn more about our hosted continuous integration and delivery service . Originally published at semaphoreci.com on February 14, 2018.
