Continuous Delivery as a methodology and tool to meet the ever-increasing demand to deliver software at the speed of ideas is quickly gaining the attention of businesses today. Continuous Delivery, with its emphasis on keeping software in a release-ready state at all times, is a natural evolution from Continuous Integration and Agile software development practices. However, the cultural and operational challenges to achieving Continuous Delivery are much greater.

For most organizations, Continuous Delivery requires adaptation and extension of existing software release processes. The roles, relationships, and responsibilities of people across the organization can also be impacted. The tools used to deliver, update, and maintain software must support automation and collaboration properly in order to minimize delays and provide tight feedback cycles across the business.

Organizations looking to transition to Continuous Delivery should consider the following seven pre-requisites. These are practical steps that will allow them to successfully execute the cultural and operational changes within the regulatory and business constraints they face.

1. Shared Goals and Communication Between Development, QA, and Operations 

While Continuous Integration limits its scope to the development team, Continuous Delivery embraces the testing phases of the quality assurance team and the deployments to staging and production environments that are managed by the production operations team.

This is a major transformation in software development, and to succeed in transforming a Continuous Integration platform into a Continuous Delivery platform, integrating the QA and operations teams in its governance — as well involving the development team — is critical. Collaboration and communication are vital components of successful software development today, and in a Continuous Delivery environment, they have to take center stage.

2. CI Must Be Working Prior to Moving to CD

Continuous Delivery is an extension of Continuous Integration. The prerequisite to Continuous Delivery is to have Continuous Integration in place and working during the project, including source control management, automated builds and unit tests, as well as continuous builds of the software.

3. Automate and Version Everything

Continuous Delivery involves the continuous repetition of many tasks such as building applications and packages, deploying applications and configurations, resetting environments and databases. All these tasks in Continuous Delivery should be automated with tools and scripts and be kept under version control so that everything can be audited and reproduced.

4. Sharing Tools and Procedures Between Teams Is Critical

Continuous Delivery aims to validate the deployment procedures and automation used in the production environment. To do this successfully, these procedures and automations must be used as early on as possible so that they are extensively tested when used to deploy software to production.

In most cases, the same tools can be used in all environments, i.e., integration, staging, and production. The automation scripts should be managed in shared source code repositories so that each team (development, QA, and operations)can enhance tools and procedures. Mechanisms like pull-requests can help the governance of these shared tools and scripts.

5. The App Must Be Production-Friendly to Make Deployments Non-Events

Applications should simplify their deployment and rollback procedures so that deployments in production become non-events. A major step to achieving this is to reduce the number of components and of configuration parameters deployed. The ease of rollbacks is important when deploying new versions; that is, allowing the ability to quickly rollback in case of problems. Feature toggles help to decouple the deployment of binaries from feature activation — a rollback can then simply be the deactivation of a feature, thanks to a toggle.

Special attention should be paid to any changes of database schemas, as this can make deployments and rollbacks much more complex. The schema-less design pattern of NoSQL databases brings a lot of flexibility, moving the responsibility of the schema from the database to the code. This concept can also be applied to relational databases.

6. The Infrastructure Must Be Project-Friendly

This will empower people and teams. Infrastructures should provide all the tooling (GUIs, APIs, and SDKs) and documentation required to empower the development and QA team and make them autonomous in their work. These tasks include:

• Deploying the application version of their choice in an environment.
• Managing configuration parameters (view, modify, export, import).
• Managing databases (creating snapshots of data, restoring a database snapshot).
• Allowing view, search and notification alerts on application logs.

Public cloud platforms, mainly Infrastructure as a Service (IaaS) and Platform as a Service (PaaS), are examples of project-friendly platforms.

7. App Versions Must Be Ready to Be Shipped Into Production

One of the most important goals of Continuous Delivery is to allow the Product Owner to decide to deploy into production any version of the application that successfully goes through the Continuous Delivery pipeline; not only the version delivered at the end of an iteration with a “beautiful” version number.

Reaching this target requires many changes in the way applications are designed:

• Features that are not yet validated by the QA team should be hidden from end users. Feature toggles and feature branches are two key ways to implement this.
• Build tools should evolve from the concept of semantic versions separated by intermediate unidentified snapshot versions to a continuous stream of non-semantic versions. Subversion repositories help provide ordered version numbers thanks to a revision number. Git, the free, open-source distributed version control system, is more complex to use for this due to its unordered commit hashes; special tooling may be useful to make this version identifier more human-readable.

The crux is that Continuous Delivery is not just about a set of tools; it is also about the people and organizational culture. Technology, people, and process need to be aligned to make Continuous Delivery successful, and a collaborative approach is fundamental to its success. Implementing these best practices can allow organizations to reap the rewards of a more fluid, automated approach to software development — and one that provides business agility, too.