Continuous Delivery as a methodology and tool to meet the ever-increasing demand to deliver better software faster is fast 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 prerequisites -- 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. Development, Quality Assurance and Operations teams must have shared goals; and communicate
While Continuous Integration limits its scope to the development team, Continuous Delivery embraces the testing phases of the Quality Assurance team (QA) 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 a vital component of successful software development today, and in a Continuous Delivery environment it has to take center stage.
2. Continuous Integration must be working prior to moving to Continuous Delivery
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 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 the environments -- example, 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 application 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 achieve this is to reduce the number of components and of configuration parameters deployed. The ease of rollbacks is important to be more forthright in deploying new versions; allowing the ability to 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 should be paid to any changes of database schema, 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, it’ll empower the 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. Application 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 un-ordered 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 organisational 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 organisations to reap the rewards of a more fluid, automated approach to software development -- and one that provides business agility too.
Photo Credit: fotogestoeber / Shutterstock
Cyrille is director of product management at CloudBees. He has more than 12 years of experience in Java technologies. He came to CloudBees from Xebia where he was CTO and architect. Cyrille was an early adopter of the "You Build It, You Run It" model that he put in place for a number of high-volume websites. He readily embraced the DevOps culture, as well as cloud computing, and has implemented both for his customers. Cyrille is very active in the Java community as the creator of the embedded-jmxtrans open source project and as a speaker at conferences. Follow Cyrille on Twitter @cyrilleleclerc.