26/180: Continuous Integration / Continuous Delivery

What is Continuous Delivery?

Continuous delivery (CD) is an approach in which teams produce software in short cycles, ensuring that the software can be reliably released in small intervals of time safely and quickly in a sustainable way. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production.

Code Pipelines

Automated tasks to build and deploy software on demand. It turns code into versioned packages and deploy those packages to environments.

Pipeline Design Patterns for Continuous Delivery

1. Pipelines as codes: Pipeline logic is codified, stored alongside application or infrastructure code and utilizes containerized runners.
2. Externalize logics into reusable libraries: Reusable libraries contain common pipeline logic that is referenceable from pipeline code and independently developed and tested.
3. Separate build and deploy pipelines: Build and deploy pipelines should be logically separated, independently runnable and triggered by automated or manual events
4. Trigger the right pipeline: Branch commits, pull requests, merge can all trigger to different pipeline behavior depending on the teams way of working.
5. Fast Team Feedback: Every commit automatically triggers the right pipeline, with build pipelines especially optimized for speed and quick reporting of any issues.
6. Stable Internal Releases: Versioned packages produced by the build pipeline are deployed and these deployments are triggered by humans or automated events.
7. Buttoned up product releases: Deploy tagged releases on production and automate the paperwork.

Strategies for Application Deployment

1. Blue/Green: In this the new app is deployed side by the older version and then the traffic is shifted to the newer version.
2. Recreate : In this we shutdown the previous version and replace it with the new version of code to be deployed. This have certain downtime. Downtime can be measure according to the time from shutting down the version A to starting the version B.
3. Ramped: In this, things are deployed instance by instance. Not the whole application is shut but an instance is removed and replaced with the new instance till all the instances are replaced.
4. A/B Testing: Version B is released to certain subsets of users under specific conditions. This is mainly done to check the functionality of new features for certain areas etc.
5. Shadow: Version B receives real world traffic along version A, but didn’t impact the response. This is particularly useful to test production load on a new feature. A rollout of the application is triggered when stability and performance meet the requirements.
6. Canary: This is like Blue/Green but in this case the version B is deployed side by Version A, then certain amount of traffic is released to version B, once it is found that everything is working as expected then whole traffic is release for Version B.

References:

7 Pipeline Design Patterns for Continuous Delivery (singlestoneconsulting.com)

Patterns — Continuous Delivery

Six Strategies for Application Deployment — The New Stack