I always say there are two kinds of people doing continuous delivery – those that know it’s hard, and those that are in denial.
Steve Smith, Independent continuous delivery consultant
The aims of Continuous Delivery
Continuous Delivery is the direct, fully integrated, fully automated movement of working software from its developers to its users.
That is, with no stops, no gaps, no delays, no mistakes.
You can also think of it as the progressive extension of the delivery process to include more and more groups & stakeholders.
And in each case, you can think of the impact of Continuous Delivery as giving these groups more of what they want:
But you do this while also demanding less from them to get it.
However, in order to get more for less, the same users, stakeholders and groups must give the Core Team & the Continuous Delivery system full authority & power to act on their behalf.
So Continuous Delivery is one of the most radical elements of Agile.
- It impacts the whole post-development organisation & environment.
- Not just development.
Before Continuous Delivery, the organisation responsible for getting software from the development environment to the desktop typically consists of a large, complicated collection of silos.
- Each silo controls a distinct function, from regulatory acceptance to day-to-day operational management.
- Each silo had rigorous (and usually rigid) formal boundaries, tests & governance authorities controlling the movement of code from developer to user.
The goal of Continuous Delivery is to eliminate all these silos, and to create this:
Not that all these units and functions will disappear (though some may), but their role in delivery will be severely limited, typically solely to:
- Defining how Continuous Delivery will work.
- The standards and approvals it needs to apply.
- The records and reports it needs to generate.
- Seeing reports on how Continuous Delivery is actually working.
In proportion to how fully Continuous Delivery is implemented, these silos’ continuing role in the Continuous Delivery process itself – tasks, management, authorisations, Go/No-go decisions, etc. – will disappear.
Why Continuous Delivery?
In traditional (e.g., waterfall) development, turning newly developed code into a working system in users’ desktops takes place over a number of quite separate phases:
- Building each individual developer’s part of the solution.
- Integrating the results into a complete product.
- Deploying the final product to the user community.
Not only are these traditionally three quite separate phases, each with its own organisation, processes, technologies and governance, but they are usually carried out in three (and usually more) quite rigidly separated silos.
Increasingly, however, these three phases are being aligned and fused into a single seamless process, heavily automated and highly reliable, flowing from start to end of this sequence. This unified process is often referred to as Continuous Delivery, or, as it will be called here, CD.
This makes it clear why Continuous Delivery is potentially so valuable:
- From the users’ point of view, CD means:
- They get the latest software as quickly as possible.
- The disruption caused by new releases is minimised (or, ideally, wholly eliminated).
- From a business perspective, there are two major reasons:
- CD increases the efficiency and reduces the time, cost, risks and quality problems created by manually driven, poorly aligned, variably mature, unreliable and error-prone processes.
- CD increases speed to market, and so accelerates the benefits from the working software – a basic element of the business case for Agile.
- From the developers’ point of view, automating delivery as a whole helps the development team:
- To eliminate unnecessary steps between finishing the software and the realisation of value – their ultimate goal.
- To eliminate the risks and defects commonly associated with post-development phases of delivery.
- To turn what has traditionally been a white-knuckle experience into a routine (and largely inviable) event.
But for most organisations, continuous build is the norm and continuous integration quite widespread. However, continuous deployment is much less common, and end-to-end integration rarer still. So CD as a whole is still generally in the future. In fact, the reality is often even uglier:
- Many of the individual steps within each of these phases are also complex and uncertain.
- Movement between different areas is still largely manual, or are even undefined in any regular way.
- Some manual tasks have to be reiterated as the software is:
- Promoted from one environment to another.
- Integrated with the outputs of other releases and iterations.
- Configured for multiple platforms.
- Passed through additional verification steps such as product certification and regulatory approval.
- Signed off.
So, are there any ways to (at least):
- Align the build, integration and deployment phases?
- Eliminate all the manual hand-offs?
- Standardise components (e.g., ‘containers’ for applications)?
- Removing the risk, repetition and sheer tedium of manual processes?
- Set up, configure and provision infrastructure (environments, databases, interfaces, networks, etc.)?
- Program devices (burning programmable chips, etc.)?
- Set up and provision services?
- Automate verification and governance?
- Rollback every phase in this process in the event of a mistake?
- Streamline and accelerate this process as a whole?
As developments over the last decade or so have shown, there certainly are.
- Continuous Build has been available ever since compilers arrived on desktops and nightly builds became the norm. Its widespread adoption has also been signalled by the emergence of DevOps functions, which span what were once the very high barriers between Development and Operations. But its familiarity should not does not detract from its importance. As soon as the tools and procedures for Continuous Build became readily available, one of the basic practices that would eventually drive Continuous Delivery became the norm for all developers.
- Continuous Integration is also becoming increasingly widespread. Standard tools (including open source freeware) are widely used.
- Over the last decade, powerful methods, tools and techniques for Continuous Deployment have emerged, and we are now at the point where there real obstacles is not the available to Continuous Deployment solutions but reluctance – for many reasons – to implement them
- CD itself is increasingly well understood.
- Whole new technologies are rapidly evolving to manage CD as a whole.
- Agile itself is rapidly evolving the policies, conventions and tools needed to support Continuous Delivery.
- Ways of implementing CD are becoming increasingly standardised and mature.
- The risks and issues associated with CD are being identified and solved.