Published January 29, 2021
by Doug Klugh

Managing Risk

Deploy features in a way that facilitates the gradual release to select groups of users in order to manage the risk of software releases.  Start with small groups of low-risk users, then gradually expand the user base to include higher risk users.  This will limit the blast radius in the event of something going wrong and contain the impact to your most loyal customers.  It also provides an opportunity to test new features in a production environment, gather telemetry, gauge user response, and attain customer feedback.

Start by assigning users to different segment (or rings).  These rings can be categorized and named in any way that is meaningful to your organization, but be sure to assign users that are most tolerant to failure to the inner most rings, then assign higher-risk users as you move outward.  One way might be to assign innovators to the inner ring, early adopters to the second ring, then all other users to the third, most outter ring.  Of course, if you need to split your users further, you can always add more rings.

Ring deployments offer an approach to software deployments that help mitigate risks associated with releasing new software versions.  Although they appear to be similar to other deployment strategies, there are subtle differences. 

Canary Releases mitigate risks in a very similar way to Ring Deployments.  They also release new features gradually to small groups of users, but those users are selected randomly.  Ring Deployments are used to roll out new features to specific, low-risk users first, then continue to release based on the users' risk profile.

Blue/Green Deployments mitigate risks associated with software deployments by enabling the ability to quickly roll back to the prior software version.  But Blue/Green Deployments are used to release new software versions to all users at the same time, while Ring Deployments are used to release new software versions gradually to specific groups of users.  In either case, if something goes wrong after the release, it is easy to quickly revert back to the prior software version.

Dark Launching is a strategy used to facilitate CI/CD.  Through the use of Feature Toggles, development teams can hide new features from users until they are ready for release.  Then any approved stakeholder can flip a switch to enable those features.  Dark Launching mitigates risk by enabling new features to be tested in a production environment without impacting customers.