Software7 Key Pre-Requisites For A Successful Transition To Continuous Delivery

7 Key Pre-Requisites For A Successful Transition To Continuous Delivery

Businesses today are moving toward continuous delivery as a methodology and tool to meet the ever-increasing demand to deliver better software faster.

Continuous delivery, with its emphasis on keeping software in a release-ready state at all times, can be seen as a natural evolution from continuous integration and agile software development practices.

However, the cultural and operational challenges to achieve continuous delivery are even greater.

For most organisations, continuous delivery requires adaptation and extension of existing software release processes. The roles, relationships, and responsibilities of people across the organisation may be impacted.

The tools used to deliver, update, and maintain software must support automation and collaboration properly, minimizing delays and providing tight feedback cycles across the organization.

While these changes can be a huge challenge to implement for organizations that must live within regulatory and operational constraints, there are many practical steps you can take to make real progress today.

With that in mind, here are 7 key pre-requisites organisations should consider when making a successful transition to Continuous Delivery.

1. Make Sure Development, QA & Operations Teams Have Shared Goals & 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 centre stage.

2. Get Continuous Integration Right Before Making The Step 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.

pexels lukas 574077

3. Automate & 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. Share Tools & Procedures Between Teams

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 e.g. 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. Make Your Application Production-Friendly: 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 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.

pexels christina morillo 1181472

6. Make Your Infrastructure Project-Friendly: Empower The People & The 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.
Related:   REVIEW: TeamViewer 6

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

7. Make Application Versions 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 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”.

Continuous Delivery is not just about a set of tools, ultimately it is also about the people and organizational culture. Technology, people and process all have to be aligned to make Continuous Delivery successful in any organization, a collaborative approach is fundamental to its success.

If organizations are to reap the rewards of a more fluid, automated approach to software development that can also provide them business agility – they need to implement these best practice steps on the path to Continuous Delivery.


Related Articles