Time for DevOps to get out of the weeds

Software and service providers face a battle to deliver new products, features and capabilities faster than ever

Software and service providers face a battle to deliver new products, features and capabilities more quickly than ever. The overall success of the business is linked to its ability to meet rising customer expectations.

In response, development teams must deliver high-quality software while reducing release cycle times. Forrester Research recently found a strong correlation between release cycle times and business satisfaction. Teams with faster cycle times enjoy greater business satisfaction and teams with slower cycle times see less satisfaction. Only one-third of organisations consistently deliver new software to end-users within the 'gold standard' one to three-week cycle.

Pressure to shorten release cycle times and raise quality is emphasising the need for change-centric delivery.

Agile development has increased the rate and quality of output from planning and development teams. They now operate at high efficiency and can accommodate even faster release cycles. The bottleneck is increasingly a lack of efficient delivery. 

To facilitate delivery streams capable of ingesting changes more quickly, delivery teams must reimagine core principles. DevOps has shouldered the burden of faster release cycles and has focused on automating delivery workflows through tools such as Git, Jenkins, Chef and Selenium, to name but a few. 

Faster cycle times

These tools have improved the delivery process, and DevOps has assembled cross-functional teams with the authority to implement delivery-related activities, which also results in faster cycle times.

So why is delivery still the constraint? Because focusing on bits of automation and cross-functional teams ignores the main purpose of the delivery stream – to reliably build, validate and deploy change. DevOps tooling has been completely change-agnostic. 

Ask Jenkins or Chef what has changed since yesterday. There are some change-aware tools for their domain, but they are unaware of changes elsewhere in the delivery stream. 

It is difficult to track changes while ‘in flight’. As change flows through the delivery stream, it becomes aggregated or 'rebundled' many times between build and deployment. CI servers process many tiny changesets, while QA deals with larger bodies of change. Both these delivery pipelines are continuously processing a distinct changeset, so the movement of any single change must be accounted for as it flows through various pipelines, artefacts and environments to reach some final destination.

Change-centric delivery frameworks

A change-centric delivery (CCD) framework organises the entire delivery process to continuously deliver a steady, never-ending stream of change to the consumers of digital services and products – end-users. 

We can identify seven attributes of a CCD framework that can materially reduce cycle times: clearly identify every source of change; track change through the delivery pipeline; correlate every change back to a work item/business driver; implement change navigation and routing through the delivery stream; implement change bundling and rebundling during the delivery stream flow; relate binary artefacts back to changesets; track changes through environments from development to production and implement application/service assembly from loosely coupled components.

The bottom line

Automation tools alone will not produce the positive impact on the delivery stream that Agile has delivered for planning and development. But as more digital service providers adopt CCD frameworks, cycle times will continue to shrink, allowing new features and capabilities to reach end-users much more quickly, ultimately bringing the level of delivery efficiency in line with planning and development.

Stuart Kenley is managing director of Cachet Software Solutions

Next Steps

Here's why ALM and DevOps are so important to orchestration

Read more on Software development tools