alphaspirit - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Is continuous delivery a path to continuous improvement?

By embracing the cultural and technological changes of continuous delivery, developers and testers can use it as an approach to continuous improvement.

Continuous delivery is like a disruptive technology. It will change not only the way IT professionals develop and test software, but also their approach throughout the entire process. The cultural and technological changes at the heart of continuous delivery make sense when developers view them through the lean lens of continuous improvement.

This quote from Jez Humble, vice president at Chef and former ThoughtWorks principal, summed it up:

"It's virtually impossible for us to practice continuous improvement, to learn how to get better as teams or as individuals, and to acquire the skills that enable the successful creation of great products and services -- unless we focus on getting that feedback loop as short as possible so we can actually detect correlations and discern cause and effect."

Continuous delivery and its predecessors … are the processes through which software development professionals can reach individual professional goals and their organization's business performance goals.

Continuous delivery and its predecessors, continuous integration and continuous testing, are the processes through which software development professionals can reach individual professional goals and their organization's business performance goals. Implementing these processes will require not only cultural and technological changes, but also a shift in software development priorities. The focus will shift to give top priority to new features and functionality that can be implemented fastest. This shift in priorities may be led by the information technology organization or project management office; however, it must be accepted and embraced by the business.

This shift to focusing on delivery speed is the change that drives all other changes in the way developers and testers work; continuous delivery is the process by which organizations and teams achieve the goal of continuous improvement -- by increasing delivery speed. The goal of the continuous delivery process is to develop software in increments that are ready to be released. However, that does not mean each increment is actually released.

Here are specific ways in which software development and testing will change as continuous delivery is implemented. Organizationally, the Agile team (or the core project team if an organization is using the waterfall methodology) will no longer be the core team for code delivery. Instead of coordinating with system admins and operations, those teams will need to become part of the core. Each team will need to become intimately involved in -- and take responsibility for -- the full development, testing and delivery process. And the extended team, as a whole, will be responsible not only for the quality of the release and its integration into the base code, but also for performance and integration with other applications. This will be a major culture shift, even for the most mature Agile organizations.

From a technology standpoint, the changes to the way IT professionals develop and test are all about automation. Automation is the key to speed; the most complicated and time-consuming parts of the process must be automated. And for automation, tools are needed for every step in the process, including building and provisioning the infrastructure.

To automate the processes of building and managing different environments, development and operations will need to approach these processes as code, an approach known as "infrastructure as code." In an infrastructure as code framework, scripts are developed for provisioning and updating environments. Just like code, updating and versioning these scripts is handled through configuration management.

To reduce the cycle time of configuration management and version control, automation tools will be needed for those functions as well. Developers will need continuous integration tools to manage the continuous code commits, and they will need code review tools to automatically test the newly committed code against the codebase, as well as the new code developed for other paths through the application. And developers may need monitoring tools to track the entire process.

All testing phases will be automated, beginning with unit testing. Risk-based automated regression testing is a key process of continuous delivery. Testing must be specific to the code changes and the areas around those changes where bugs are likely to be found. Automated performance monitoring is also critical to finding performance and load issues before they affect customer experience.

By embracing the cultural and technological changes of continuous delivery, developers and testers can use it as an approach to continuous improvement.

Next Steps

Map plans for continuous improvement, disaster recovery audit and maintenance

Agile leads development race

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Has your organization used continuous delivery and continuous improvement together?
First, my task reduces with the use of the continuous delivery because I can build my software faster. This technology consolidates task management, code management, and automated testing. I have used CD when I offer online services such as SaaS and online gaming. However, there are moments when I lean more on the CI strategy, more so when my customers need fast responses. Besides, it slims down rework time and boosts quality in production.
A very interesting article, but I have some reservation.

The vision you describe in here is an achievement which doesn't address well the real world.
As an ideal it is appealing, but when you get into the details - its seems that it will almost always break.
Another thing: The following sentence you wrote "...achieve the goal of continuous improvement -- by increasing delivery speed" is a not an accurate assertion (As far as I see it) - Most of the time speed DOES NOT EQUAL Quality, but the opposite.
I would have written it like this: The continuous improvement task is too see how to hold to high quality IN SPITE of increasing delivery speed, most of the time - by holding the speed back in order to have High quality.