The end goal of continuous delivery (CD) is to provide the business with the confidence and power to decide when to release product changes. In this video, learn about why this might require dramatic changes to existing processes.
- [Instructor] Continuous delivery adoption often takes much longer than expected and/or fails to deliver the expected benefits, especially around change lead time and quality of the software. In my experience, this is often due to misunderstanding of the true power of continuous delivery and what's required to unlock it. The end goal of continuous delivery is to provide the business with the confidence and power to decide when to release product changes to customers. This means that true continuous delivery is an organizational capability, not simply a technical discipline. Think of all the teams that typically take part in a large release process and the handovers of work that take place. While the delivery clock keeps running, teams are waiting on each other to put together all the pieces of the release puzzle. If done right with a cross-team approach, continuous delivery allow us to visualize the end-to-end flow of delivery and therefore start addressing recurring delays due to dependencies and scheduling conflicts that can consume a large part of the delivery time. Be aware, we're not saying that teams should not start with continuous delivery by their own volition. It's actually a good sign when the team is engaged in improving their delivery workflow. But in the enterprise world, the highest returns for continuous delivery lie in the interplay between multiple teams. Research and empirical evidence have shown that up to 85% of the elapsed time to deliver a change is regularly spent waiting for dependencies. That means if a release takes four weeks, it could actually be delivered in three working days if only we could eliminate wait time altogether. Besides increasing speed, continuous delivery can dramatically increase the visibility and confidence levels of software releases. A comprehensive delivery pipeline provides a shared view on the status of features, fixes, and any other type of changes, waiting for structure, configuration, or anything else. By making this view accessible to everyone, we gain a shared understanding of the current status of changes, including what activities and checks have been performed so far and the corresponding results as well as which still need to be executed. This is only possible when all teams in the delivery cycle are focused on improving the overall flow and quality of work. In contrast, when teams work in isolated functional silos there's little visibility on the roadmap and goals. This tends to block flow due to conflicts and priorities in schedules between teams. A release process which translates into a sequence of black box steps where each team only worries about its direct inputs and outputs is a recipe for slow and subpar value delivery. With true visibility on the release process comes the ability to establish clear release criteria and automate where possible. This increases our confidence in what is being delivered to customers, not only in terms of functionality but also quality, security, compliance, and so on. Finally, we want to enable not just faster releases but also timely release decisions. It is often hard to automate the full release process for large, long-lived products or services. We might have a green pipeline but still need to update user documentation, support documentation, and perhaps our on-call processes as well. And/or we might want to launch a marketing campaign around the new feature or product version, for example. Knowing when we are ready to release is fundamentally a human decision for any non-trivial product. Continuous delivery helps not just by reducing delivery time but also by allowing us to decouple deployment of a change from actually releasing it to customers. Technical practices like feature toggles, which are essentially an in/off switch for a new feature, canary releases, which expose a change to a small number of users first so we can quickly learn how the change is performing, and finally, adaptable deployment models allow separation between the necessary pre-live activities, such as deployment to production and the act of releasing the change to the users in the live environment. Ideally, a release should always be a business decision at the push of a button and constrained by technical issues.
In this course, instructor Manuel Pais shows leaders how to rethink CD in their organization to boost the speed and safety of their delivery workflow. Manuel explains why true continuous delivery is an organizational capability, and why software releases should be treated as business decisions. Plus, learn how to define a single path to production that balances speed and reliability; extract and transform data to enable faster release decisions; improve key metrics for high performance sustainably; and more.