Canary Release: This is just on blog among various others on a series of Agile Software Release Strategies.
Agile along with Continuous Integration has helped Software Product development teams reach market much faster than ever before. But the bone of contention between the testing team and dev team still lies at how close the testing data and context has been with production environment.
Canary release tries strike a middle ground here.
What is a Canary Release?
As hinted earlier, Canary Release is a combination of Testing and Release strategy. This can help you release newer version of your software to a smaller subset of users first, before you release to the larger population.
Video: Canary Releases
Background
This is typically used in releases, which is carrying HIGH RISK features. Some times certain features are built that touch upon too many areas of code and no amount of regression is enough. In such scenarios you would want to reduce the risk in release. Even if the release is damaging, it will minimize the impact.
The transition from a smaller subset of users to the complete population can be gradual and need not be limited to a single stage.
How to implement?
It depends on what you are trying to release. Which in turn determines how you can distribute your newer software to a smaller set of users. Let us consider in our example “A Website”:
Here you have advantage of “exposing” your newer version changes to a select few users by means of configuring your network load balancer/router/gateway. You can use this to determine a certain section of users to see the changes. The criteria can be any of the below:
- Geographical
- Time of the day
- Demographical factors
- Or even random % of requested routed to the newer version of the Software
Metrics
Now, such an implementation as this doesn’t make sense if you do not collect Metrics. Otherwise how would you know what’s going on?
Metrics can be any data that can throw insight into
- Quality aspects
- Traffic shape-up
- Risk factors
Once the metric provide good enough confidence, the team can decide to go to the next stage, which can either be gradually increasing the exposed population or direct exposing the changes to all users.
Benefits
Two major benefits are evidently visible:
- Testing Realistically: Liked we discussed before not all scenarios and data can be testing in lower environments. And that doesn’t mean management would approve to test everything in LIVE. Hence this strategy strikes a middle ground where Testing can be done in LIVE environment while not blowing up the entire system.
- Risk Impact: Continuing from previous benefit, you are drastically reducing the risk of any feature failure subject to only a few users using the system. This does not mean “0” risk. This rather means, minimal impact.
Possible downsides
- Unless you automate the entire cycle, this will be risk prone. You need to invest in dedicated resources during releases to mitigate it, which would in turn incur costs.
- Perhaps a bigger challenge would be, if your changes are tied up with database schema changes, then you have a bigger challenge of running both the version in parallel. This is quiet a common scenario isn’t it. This means, you need to plan this well right from your design phase of the feature.
Tools in Market
You need a suite of tools to implement the strategy. Some examples below:
- Proxy: HAProxy, Envoy
- Router: Ambassador Edge Stack (API Gateway)
- Continuous Integration: Jenkins, Harness
- Feature Enablement: Many applications manage this internally. Or you can use 3rd party SaaS platform
Conclusion
Although it is not one solution to all problems, it is wise to use this strategy in Projects which have volatile components. And in most of the releases the quality team is not confident on their testing in lower environments. Here this strategy comes in very handy. And moreover you can use this strategy only when required, and switch back to regular release technique if the release is not complex.
Our PMI® PMP®-Prep Course
If interested in this course, click here
- Case study based training
- LIVE instruction 36 Hours
- Post course guidance
- Exercise per topic
- 4 Mock exams for practice
- WhatsApp group support
Our PMI® ACP®-Prep Course
If interested in this course, click here
- WhatsApp group support
- 4 Mock exams for practice
- Exercise per topic
- LIVE instruction 20 Hours
- Post course guidance
- Case study based training
JD (Coach/Instructor/Writer)
JD (a.k.a Janakiram) is a Project Management Coach, Trainer Author and Practitioner @Zaidan Consulting. He comes with around 17+ Years of experience primarily from the Software Industry. He is certified on PMI® PMP®, ACP®, Scrum Alliance CSM and Microsoft Certified Solution Developer on C#.NET. He has also authored the book “Practical Agile for Beginners”
About Zaidan Consulting
Zaidan Consulting are specialists in Project and Program Management space. Our training offerings include:
- Project Management Training
- Agile Training
- PMI®-ACP® Prep Training
- PMI®-PMP® Prep Training
- PMI®-CAPM® Prep Training
- ScrumStudy™ Authorized Training Partner (A.T.P)
Or you can contact us @+(91) 7672011471
Or Email us: [email protected]