Continuous Delivery: Release Patterns
A list of different release patterns for different use cases
To decouple deployments from our releases that are driven by our marketing launching date, we can use certain release patterns. We avoid setting up deployments for Friday nights or weekends in order to reduce the risk of negative impacts on customers.
Continuous Delivery allows for deployments during normal business hours by using environment-based release patterns and application-based release patterns.
Environment-based Release Patterns
These patterns do not require any changes to the application code. We have multiple environments to deploy into, but only one of the environments receives customer traffic. One advantage of this is the reduction of the deployment’s lead time of new feature sets. Another one is the decoupling of our deployments from our releases.
The Blue-Green Deployment Pattern
This is the simplest pattern for us — we have two production environments: blue and green. Only one of these environments is serving customer traffic.
To prepare a new release candidate, we deploy into the inactive environment (the blue one), where we can perform several tests like acceptance test, integration tests, or performance tests, without interrupting or manipulating user data and user experience.
To execute the release we need to redirect the user traffic to the blue environment. So, the blue environment becomes active and the green one turns into staging. Rollbacks can be made by sending traffic back to the green one.
The blue-green release pattern can dramatically increase the safety of software releases.
Canary Release Pattern
The canary release pattern automates the release process of promoting to successively larger and more critical environments as we confirm that the code is operating as designed. [DevOps Handbook]
After a release in a specific environment we monitor how the software performs in each environment. If something seems wrong, we can easily roll back; otherwise, we deploy to the next environment.
Cluster Immune System Pattern
This pattern is based on the pattern of Canary Release and expands it by linking the production monitoring system to the release process and by automating the rollback of code when the performance of the production system is out of a expected range (user drop rate, latency rate, response times, and so on).
With this pattern, everything is automated and tested to detect errors. This way, we do not need to spent time debugging the code and system environment to find the issues.
Application-Based Release Patterns
With this kind of pattern we can modify our code to get greater flexibility in how we safely release new features to the customer. Because these patterns are implemented in application code, the development department is in demand here.
Feature Toggles
This pattern is also called Feature Flags.
With this pattern we selectively enable and disable features without requiring a production code deployment. So, this controls if a feature is visible and available to specific user segments (e.g., internal employees, test users, global users, specific customers).
Most of the time Feature Toggles are controlled by a configuration setting stored somewhere (environment variables, service mesh configuration, …). The simplest way is to wrap up specific UI elements with conditional statements, where features are enabled or disabled.
General advantages of feature toggles:
- Roll back easily
- Gracefully degrade performance
- Increase resilience through a service-oriented architecture
- Perform A/B testing
Dark Launching
In this release pattern we modify our applications by small configuration changes so that specific functionality is available for a small group of customers. An example is using Feature Flags that progressively expose new functionality in a specific environment (here production) to all developers, internal employees, a certain percentage of customers, or the entire customer base. So, the new functionality is staged to be launched in production and tested with production traffic before the actual release.
Conclusion
Different release patterns give us the freedom to use one that fits our culture, use case, or marketing model.
If we have the ability to customise our applications at the development level and the feature use cases allow it, we can use Feature Toggles or Dark Launches.
If we do not have the possibility to modify our applications, we can also fall back on Blue-Green Deployments, Canary Releases, and the Cluster Immune Pattern.
Thanks for reading! Follow me on Medium, or Twitter, or subscribe here on Medium to read more about DevOps, Agile & Development Principles, Angular, and other useful stuff. Happy Coding! :)
