Continuous Deployment

Continuous Deployment is the software development practice of automatically deploying all changes that pass through the established pipelines directly to production, without manual intervention. It extends continuous delivery by automating the release process.

Goal

The goal of continuous deployment is to minimise the lead time between making a change to software and that change being used by live users, in production.

Context

Every manual step in the deployment process delays the ability for teams to get quick feedback from customers. The delays reduce the accountability of the teams as they will blame the delays and it encourages the bad behaviour of batching changes together, which increases the risk of each release and makes it harder to evaluate the impact of each change.

Deployment Approaches

Deployment Approach	Description	Benefits	Considerations	Best Suited For
Blue/Green Deployment	Involves two identical environments. One hosts the current version (Blue) while the new version (Green) is deployed and tested. Traffic is switched to Green once it's verified.	Minimal downtime; easy rollback.	Requires double the resources Managing stateful applications can be complex.	Applications needing minimal downtime and quick rollback capabilities.
Staged (Rolling) Deployment	Gradually replaces instances of the old version of an application with the new version across several stages.	Allows gradual exposure Reduces risk by not affecting all users at once.	Longer rollout time More complex to rollback if issues are detected late.	Applications where gradual rollout and minimising impact on all users simultaneously are important.
Canary Deployment	Releases the new version to a small subset of users before rolling it out to the entire user base. This "canary" serves as an early indicator of issues.	Early detection of potential problems Reduces impact on the user base.	Requires robust monitoring and metrics Managing different versions can be complex.	Applications needing real-world testing feedback before full rollout Systems where reliability is critical.
Feature Toggles	Uses feature flags to enable or disable features without deploying new code. This allows features to be tested in production environments.	Flexibility in releasing and rolling back features Can be used for A/B testing.	Increased complexity in codebase potential performance implications.	Teams practicing trunk-based development or wishing to test features in production without affecting all users.
A/B Testing Deployment	Two or more versions are released to randomly selected users to test different features, designs, or functionality.	Direct comparison of user behaviour Data-driven decision making.	Requires sophisticated tracking and analysis tools May result in inconsistent user experience.	When direct feedback on specific features or changes is needed to guide development decisions.

Database Change Deployments

Code changes are relatively easy compared to database changes because it is hard to have two different database configurations in production at the same time, which invalidates a number of the deployment strategies used for code.

Method	Description	Benefits	Considerations	Best Suited For
Backward-Compatible Schema Changes	Adding new schema elements without removing or altering existing ones.	Ensures no disruption to existing application functionality.	May require cleanup of deprecated elements later.	All types of deployments, especially when aiming for zero downtime.
Expand and Contract Pattern	Expanding the schema by adding new elements, then contracting by removing deprecated ones after full transition.	Minimises risk by separating addition and removal of schema elements.	Requires careful planning and execution in two phases.	Systems requiring iterative schema evolution with minimal impact.
Dual-Write Strategy	Temporarily writing data in both old and new schema formats.	Ensures data integrity during transition Supports testing new schema under load.	Increases write load Complexity in maintaining consistency.	Environments where data loss cannot be tolerated.
Shadow Writes	Writing to the new schema without impacting the existing application logic, for testing purposes.	Validates new schema performance and integration without risk.	Additional overhead for discarding shadow writes post-validation.	High-traffic environments needing validation of schema changes.
Branch by Abstraction	Introducing an abstraction layer in the application for database interactions, facilitating schema transitions.	Decouples application logic from database schema changes.	Adds an abstraction layer complexity Requires significant upfront design.	Complex applications undergoing significant schema evolution.
Versioned API Endpoints	Creating new API endpoints that work with the updated schema, maintaining old endpoints for compatibility.	Allows parallel operation of different application versions.	Management of multiple API versions potential for increased complexity.	API-driven applications where backend changes frequently.
Data Migration Scripts	Scripts for migrating data to fit the new schema, executed before the full deployment.	Ensures data integrity and compatibility with the new schema.	Requires thorough testing to avoid data loss or corruption.	Deployments involving significant changes to data structures.

Inputs

Artifact	Description
Unvalidated Code	A feature that has been implemented but not yet validated with users.
Deployment Scripts	Scripts that automate the steps necessary to release the application to production.
Feature Toggles	The ability to enable or disable features without deploying new code so that features can be tested in production environments.
Automated Alerts	The ability to identify issues or variances from normal behaviour in production.
Automated Rollback Capabilities	The ability to automatically rollback changes if issues are detected in production.

Outputs

Artifact	Description	Benefits
Live Product	The code changes deployed to the production environment.	Enables rapid delivery of features and fixes to users.

Anti-patterns

Manual Intervention: Requiring manual approval for every deployment, slowing down the release process.
Failing to maintain a robust suite of automated tests: Since the code is deployed automatically, it is crucial to have a comprehensive set of automated tests to ensure the quality of the release.
Lack of monitoring and alerts for production: even with the best test suite in place, issues can still arise in production, and without proper monitoring and alerting, these issues can go unnoticed.