Continuous Delivery

Introduction

The aim of Continuous Delivery is to deliver software in an efficient, fast and reliable manner.  Continuous Delivery achieves this by automating the build, deployment, test, and release stages of the application development. At every code check-in, the Continuous Deployment process ensures that the application remains in a production ready state. Any issues are promptly reported to developers so that they can fix them.

This document starts by introducing Continuous Integration, a fundamental part of Continuous Delivery. It then explains what Continuous Delivery is and why it is a natural extension of Continuous Integration. Finally, it explores the Deployment Pipeline, a commonly used strategy to achieve Continuous Delivery.

Continuous Integration (CI)

Continuous Integration (CI) is a process where multiple developers integrate their work into a shared repository. Each check-in triggers an automated build and suite of tests to detect integration errors as soon as possible.

Continuous Integration represents a paradigm shift. Without Continuous Integration the application is broken until proven it works, usually after lengthy manual testing. With Continuous Integration the application is always in a production ready state. Any failures immediately alert developers, who should fix them as soon as possible.

Effective Continuous Integration

These are some of the practices needed to have an effective Continuous Integration:

  • Developers check in their changes to a version-controlled repository frequently. This includes code, tests, database scripts and any configuration needed to build and execute the application.
  • Each check-in to the version-controlled repository triggers an automated build.
  • The automated build should complete as quick as possible.
  • The state of an automated build should be visible at all times. It is important to provide quick and visible feedback to the team.
  • Developers should fix broken builds as soon as possible.
  • The automated build generates an artefact ready to download and execute.

Continuous Integration Benefits

These are the benefits of Continuous Integration:

  • Increases reliability, decreases stress. Integrating code continuously leads to more predictable and less tense integration process.
  • Improves feedback. Developers can identify broken builds and failing tests as soon after checking in the code.
  • Reduces errors. Bugs and application issues are identified early in the development process.
  • Production readiness. There is always a production ready artefact. As the artefact has passed the automated quality checks, trust is improved and risk reduced

Continuous Delivery (CD)

Continuous Delivery (CD) is the processes and practices that make applications ready to be deployed into production at any time.

Continuous Delivery aims to create an end-to-end process from code check-in to production release. Continuous Delivery involves the configuration management, build, deployment, testing, and release process of the application.

Continuous Delivery is the natural extension of Continuous Integration. Continuous Integration aims to create a high quality artefact, and is an activity that mostly involves the development team.  Continuous Delivery, on the other hand, brings together the developer team, testers, operations and business.

NOTE: We should not confuse Continuous Deployment with Continuous Delivery (CD).  Continuous Deployment is about deploying every build into production, while CD is about making every build available for deployment.

Deployment Pipeline

The Deployment Pipeline is the automation of the project build, deployment, test, and release processes. The Deployment Pipeline is a strategy to achieve Continuous Delivery.

The principle of a Deployment Pipeline is to break down the deployment process into several stages. After a change is checked-in, the first stage is to compile the code and create the artefact. This artefact then passes through a sequence of tests, each evaluating the artefact from a different perspective. As the artefact passes from stage to stage, confidence grows and the artefact becomes more production ready.

The line stops as soon as a failure occurs at any point in the pipeline. The aim is to provide prompt feedback to the development team. The development team can then investigate, fix the issue and trigger another build sequence.  Developers need to give priority to fix the Deployment Pipeline, and should never check in on a broken build.

Deployment Pipeline Example

The Deployment Pipeline varies from project to project, and from team to team. Some projects, for example, might break down their tests into several stages. Others might want to deploy to some environments manually instead of automatically. Some might choose to speed up the Deployment Pipeline by running some stages in parallel.

Below an example deployment pipeline:

A Deployment Pipeline: Automation of the Continuous Delivery process
A Deployment Pipeline: Automation of the Continuous Delivery process

These are the deployment pipeline stages above:

  • After a check-in, we compile the code, run unit tests and create the artefact.
  • Deploy to test environment. We deploy the artefact to a test environment automatically.
  • Smoke Tests. We run quick automatic smoke tests to verify the artefact can start and is stable.
  • Automated Acceptance Tests. We ensure the system works at a functional and non-functional level.
  • UAT Tests. Testers manually test the application to detect any defects not caught by the automated acceptance tests, and provide user sign-off.

NOTE: The deployment pipeline is also called build pipeline or build chains.

Continuous Delivery Benefits

These are the benefits of a fully automated Continuous Delivery process:

  • Production readiness. The application is always is in a production ready state unless the build fails. This is a paradigm shift from traditional process, where the application is broken until proven working.
  • Reduces release cycle. The fully automation of the deployment pipeline reduces the time taken from conception to delivery. The deployment pipeline also promotes smaller incremental releases, thus further reducing release cycle.
  • Improves feedback. Everybody involved knows the state of the application at all times. Failures during the deployment pipeline will notify developers so they can fix them promptly.
  • Improves collaboration among teams. Testers know when an artefact is ready for testing. Operations know what builds have passed rigorous testing and are ready for production deployment.
  • Reduces errors and increases reliability. The automation of the full deployment pipeline encourages the team to run and test the process more frequently. This helps detect issues early in the development stages. It also avoids human mistakes common in manual configuration and releases.
  • Promotes configuration management. Each change made to production is recorded and audited. This reduces the risk of mistakenly overriding manual production changes.
  • Lowers stress. Daylong releases with many manual configuration steps are very stressful. Continuous Delivery reduces stress by releasing at the push of a button and reducing manual changes.

Bibliography

The following two tabs change content below.

Eduard Manas

Eduard is a senior IT consultant with over 15 years in the financial sector. He is an experienced developer in Java, C#, Python, Wordpress, Tibco EMS/RV, Oracle, Sybase and MySQL.Outside of work, he likes spending time with family, friends, and watching football.

Latest posts by Eduard Manas (see all)

Leave a Reply