What is continuous delivery?

Traditionally, before software could be released to the end user, it would have to go through large amounts of development, testing and revising. This waterfall methodology, in which entire products were developed upfront before being tested and then deployed, was extremely time consuming, and resulted in slow deployment cycles and a less positive user experience.

A core component of DevOps, and working within the larger context of CI/CD, continuous delivery came about as part of the Agile-software revolution. Rather than create complete packages all at once, continuous delivery incorporates all aspects of building code that could go into production while using advanced automation solutions for repetitive tasks like testing and it allows developers to ship smaller software changes at a more consistent rate. Under some circumstances, the code may go directly to production - something also referred to as continuous deployment.

This provides a number of key advantages for businesses and software vendors:

When developers release large-scale deployments, there is a lot that can go wrong. Continuous delivery limits the risk of deployment, by focusing on small changes that are easier to vet and to troubleshoot, and that require less time to fix in the event that they don’t function as expected.

Rather than simply waiting on developers to decide when the work is done, continuous delivery allows application and project owners to easily chart progress by tracking software delivery cycles as well as deciding when and how to continue with deployment into production or testing environments. In some cases it may be desirable to leverage the information gathered throughout the continuous delivery lifecycle within a Value Stream Management solution to understand the relative capabilities of teams and to help identify and remove bottlenecks.

When software deployments move through pre-established development stages, individual phases can take up a significant amount of time. Continuous delivery forces teams to build testing and fixing tasks into other daily processes, rely on automation in building, provisioning and more to help shoulder the burden. This allows for fewer development phases, much less redundant work and faster turnaround times. In fact, the hallmark of continuous delivery is that it produces software that can be released at any time—a notable improvement over the long delivery times of traditional software development.

When developers invest a great deal of time into building something, only to discover upon release that it is ineffective or poorly received, they are forced back to square one with very little to show for their effort. Shorter, more-frequent releases show up testing and other issues more quickly and allow the application users to provide feedback early and often so developers can make course corrections where needed.

With reliable feedback throughout the delivery lifecycle, developers can improve and streamline their products, testing out features and ideas and cutting away anything that’s unnecessary, ineffective or that creates a negative user experience.

Continuous delivery relies upon automation to eliminate many of the fixed costs that have traditionally plagued software development. This means less of a cost investment upfront and through the development lifecycle, and an increased return on the costs that remain.

Development marathons and looming project deadlines have a way of wearing down development teams. Conversely, small-scale fixes and releases can be managed more easily and in conjunction with other duties. Continuous delivery not only creates a less-stressful working environment and helps prevent burnout, but it also allows developers to interact more directly with users and see exactly how their labours are benefiting customers.

On the surface, continuous delivery sounds and looks a lot like continuous deployment. But while they both are part of the Agile approach to software development, there are subtle differences between the two variations that are worth recognising.

As described above, continuous delivery automates many of the processes involved in software development and empowers teams to make incremental, ongoing changes to products. But where continuous delivery does not automate is the final stage of approving the deployment to production. Changes that have been made and pushed through to testing environments typically go through manual review and authorisation as part of a scheduled release into full deployment.

Continuous deployment takes automation further, by automatically deploying updates either on a predefined schedule or as soon as code is delivered from the continuous delivery process. If code does not require a deployment window, then by automating change governance (where used) in a reliable way, developers essentially get direct access to production and can ensure that updates are going out regularly, without having to push them out the door themselves. This gives businesses increased capacity to release more deployments at any given time, and even takes a lot of the hassle out of major releases. For most organisations, the inhibitor to continuous deployment is the need for strong governance, for example, because of industry regulation. Implementing continuous deployment in these kinds of organisations is largely dependent upon the ability to effectively automate what used to be manual approvals, such as in a formal change management process.

The overall concept of continuous delivery is easy to grasp: break time-intensive development processes apart into automation-backed small-scale tasks and releases. However, understanding the idea and knowing how to implement the methodology are two separate things. The following are vital prerequisites in making the switch to continuous software delivery:

The aforementioned waterfall approach to software development may still be deeply ingrained in the minds and processes of development teams. As such, making the cultural switch to DevOps and Agile development will require extensive planning and thorough training. If dev teams are not committed, then continuous delivery is not likely to succeed.

The cultural shift towards DevOps is one that will need to take effect beyond the confines of software development. Fast feedback loops and effective decision making demand clear collaboration and coordination with leadership, so that everyone is fully aware of and committed to the right processes.

Fast turnaround times and pain-free software releases don’t do organisations much good if the end products can’t stand up to security or compliance demands. Thankfully, many of the same approaches to automation tools used throughout continuous delivery can be employed to help minimise the security risk that comes with deployment. Automated code scanning tools with policies determined by specialist security teams become a part of the pipeline. If automated change management is in use, then the successful completions of those scans become a part of the information used to automatically create and approve change requests.