Continuous Deployment/Delivery

Increase automation to provide a seamless and reliable "path to live" once code is complete, tested, and ready to deploy.

  1. Previous: Continuous Integration
  2. Next: Operate

Continuous Delivery is an extension of Continuous Integration. Where Continuous Integration ends with a tested, packaged product, Continuous Delivery takes that product and puts it into an automated release process. The end result of Continuous Integration and Delivery is the ability to take a product all the way from code to a production environment at the push of a button.

Continuous Deployment takes this concept further still, removing the requirement to “push a button” to release. Every deployment which passes integration successfully is deployed automatically to the live environment.

Both practises represent the transition from development of a system to its operation. See Teams for a description of how these responsibilities can be distributed in unified teams.

“We don’t have a release manager and there are no set weekly deploys. Developers and designers are responsible for shipping new stuff themselves as soon as it’s ready.” - GitHub Blog

Objectives

Ideal continuous deployment processes should have the following characteristics:

  • Minimal human intervention

    Minimise the amount of human effort required to deploy a product to a live environment. This ensures that personnel are working on value-add activities rather than repetitive “overhead” costs. Minimising human interaction also reduces a source of error, as people are typically poor at repeating complex tasks.

  • Repeatable deployments

    Deployments should be reliable, so that personnel are not worried about releases which have to be meticulously planned and executed. Deployments should become predictable, with high confidence and low risk.

  • Timeless deployments

    The timing of deployments should matter less as organisations develop competencies in this space. Product technology decisions can be made to reduce dependencies or ensure data migrations do not interrupt normal processing. With these in place concepts such as release windows can be removed and deployments made at any time of day.

Developing competency

To achieve the objectives outlined above, consider the following suggestions:

  1. Deployment technology

    Establish the technology (or technologies) to be used for CD. This may be an extension of your existing CI infrastructure, for example Azure DevOps Pipelines or GitHub Actions

    Maturity indicators

    • CD processes are automatically triggered from CI processes
    • Sequential release of deployment packages through staging environments to production
    • Use of deployment patterns such as blue-green deployments
  2. Robust QA and approval processes

    As CD approaches are an extension of CI, it is expected that CI processes (and particularly automated testing regimes) are already mature. This is particularly true for Continuous Deployment practises where the output of CI is automatically released to live.

    Maturity indicators

    • Low number of deployments to live environments found to have errors
    • Automated release approval processes (Continuous Delivery may involve a manual approval step or deployment windows)
    • Roll forward (i.e. create a new release) when issues occur in live rather than rolling back
  3. Automatic notifications

    Keeping relevant parties informed of releases is an important part of release practise. This may take the form of automatically created release notes, emails to customers, or IM-based notifications to internal teams.

    Maturity indicators

    • Agreed communication platform and channels
    • Release notifications describing change and release information are created and distributed automatically
    • Accessible user-facing release history and details
  4. Embedded monitoring

    In rare cases that errors are not caught by CI processes, it is important to have robust monitoring software in place to detect any issues in live environments once the release process is complete.

    Maturity indicators

    • Ability to identify the build/release associated with any logged failures
    • All errors are logged
    • Wider performance monitoring and dependency monitoring tools are in place
    • Failures are detected swiftly, and routed efficiently to development teams
  5. Deployment design

    Technology selection and coding patterns are put in place to support CD processes.

    Maturity indicators

    • Use of software patterns such as feature toggles
    • Systems are designed to minimise or remove downtime caused by data migrations
    • Data backup and restore processes are aligned to support disaster recovery scenarios
  1. Previous: Continuous Integration
  2. Next: Operate

Reading matter

The following books are recommended to help develop competency in this area:

Book cover art for Continuous Delivery
Continuous Delivery

Jez Humble, David Farley

Once your software is ready to release to users it must be deployed. This book explains how to de-risk and efficiently manage your deployment pipeline to make releasing software as simple as possible.

Edit this page on GitHub

The content on this page is published under Open Source licenses via GitHub. To submit issues or provide feedback please visit the repository.

Visit