Written By: Daniel Kulvicki, Solutions Director at Calavista
In my last two blogs, I went over the specifics of Continuous Deployment and gave some examples of how you can enforce quality and controls even though you are releasing at breakneck speeds. To finish off my series, we will dive into Dark Launches and Feature Toggling. These mechanisms allow our teams to deploy software as fast as possible while reducing risk of bugs or issues to our broader customer base.
Dark Launches
Let us start with the official definition of what it is to provide Dark Launches of software features.
“Dark launching is the process of releasing production-ready features to a subset of your users prior to a full release. This enables you to decouple deployment from release, get real user feedback, test for bugs, and assess infrastructure performance.”
Although that is the official definition of Dark Launches, I like to have my own interpretation. To provide releases as quickly as possible, you can also Dark Launch and not have any users test the new feature(s). Some companies prefer this as it allows for faster releases and reduces risks of issues. What you are essentially providing is a “turned off” feature (or features) in production. There is some risk since you need to ensure even if the feature is turned off that it does not impact other turned-on features in production. However, that means you are still deploying code at extremely fast speeds and minimizing risk due to being able to turn on the feature later and test it with whatever size audience you need!
Feature Toggle
Feature Toggle is one of the most popular architectures used for Continuous Deployment. At the beginning, the main usage of feature toggles was to avoid conflict that can arise when merging changes in software at the last moment before release. However, what quickly came to fruition was a structure by which to introduce new code quickly without causing breaking changes within an application. Some organizations that adopted Feature Toggles soon realized that they were on the verge of Continuous Deployment. As their release cadence became sound and fast, these companies were able to change their software product lifecycle to adapt to take advantage of this newfound speed.
Feature Toggles do have some downsides that will need to be addressed up front for an organization to adopt this style of architecture. If you are not careful, technical debt can occur since turning on features permanently can cause stagnant code. However, if you manage this correctly; the speed you gain will outweigh the management of the debt.
Conclusion
Well, hopefully I have shown you how one implementation of Continuous Delivery can help your organization be even more agile than it currently is with keeping the same level of quality your customers deserve. I do understand that Continuous Delivery is not a great fit for every organization and sometimes the overhead that it brings can be a bit too much for smaller groups. Most organizations do not even evaluate if it is a possibility. Hopefully, this series will help you and your team determine how more Agile you can become!
