Rethinking Continuous Delivery

Continuous Delivery is the ability to consistently ship code multiple times a day to production. It enables fast and reliable delivery of features through automation of the release process.

Effective release processes have a few essential qualities:

• Speed: Changes should be quick to get into production.
• Simplicity: The process should be easy to understand.
• Traceability: It should be clear what was included in each release.

A powerful approach to achieve these qualities is to center the release process around a build artifact.

Build Artifacts

A build artifact is the built and packaged output of a codebase. It’s the result of the Continuous Integration (CI) process and represents a specific version or commit of the code. Each artifact is self-contained, allowing for easy inspection and reuse.

Build artifacts offer several benefits:

• Security: Artifacts can be scanned for supply chain risks or vulnerabilities.
• Debuggability: Anyone can pull and run the artifact in isolation for troubleshooting.
• Reproducibility: The artifact’s contents are tied to a specific commit, making it easy to identify the exact code and dependencies used.

By using build artifacts as a bridge between Continuous Integration (CI) and Continuous Delivery (CD), CI focuses on creating the artifact, while CD focuses on deploying it. This separation allows for quick and consistent releases, as only the specific artifact and its corresponding configuration need to be updated.

This approach is fundamentally different from the process of shipping infrastructure.

Continuous Delivery of Infrastructure

Shipping infrastructure is a different challenge from delivering application code. Infrastructure changes often carry higher operational risks and may require additional safeguards or manual intervention. Unlike application builds, infrastructure changes can be slower to roll out due to the complexity and potential for wide-reaching impact.

Here’s how infrastructure delivery differs from application delivery:

• Risk: Infrastructure changes may affect uptime, scalability, and security.
• Speed: Infrastructure changes might take hours to propagate, unlike application changes which can be instant.
• Process: Infrastructure updates often require approvals, manual checks, or phased rollouts to reduce risk.

However, there are scenarios where Continuous Delivery for infrastructure is useful—particularly in Disaster Recovery (DR) processes. In a disaster, the ability to rapidly redeploy infrastructure from scratch can significantly reduce downtime. To achieve this, it’s beneficial to have a separate release process dedicated to infrastructure updates, distinct from the standard application release process.

Why Separate Application and Infrastructure Delivery?

Keeping the release process for infrastructure separate from the release process for the application code has several advantages:

• Flexibility: Each process can be improved independently, leading to faster iteration and fewer bottlenecks.
• Risk Reduction: Infrastructure changes often require a higher degree of caution and operational rigor, which may not align with the fast-paced nature of application code delivery.
• Focus: Teams working on disaster recovery can focus on infrastructure readiness without disrupting the standard code release process.

A clear separation also allows for better control over disaster recovery. By isolating the disaster recovery process from the normal deployment process, teams can test recovery scenarios more effectively and ensure that systems can be restored quickly when failures occur.

Conclusion

Continuous Delivery isn’t a one-size-fits-all approach. While build artifacts are a proven method for streamlining the delivery of application code, infrastructure delivery requires a different strategy. By separating the two, teams can optimize for speed, simplicity, and security in application delivery, while maintaining the operational rigor required for infrastructure changes.

This approach allows for faster, more reliable application releases while creating a clear, deliberate process for infrastructure updates and disaster recovery. As teams adopt this separation, they’re better equipped to deliver application changes at speed and handle infrastructure updates with caution and confidence.