One of DevOps’s core principles is feedback. Feedback is one of the “Three Ways” from which all DevOps patterns can be derived. Faster feedback means fewer problems and better features.
Accelerating the feedback loop is a force multiplier because it enables faster technical and business decisions. It’s not a straight line to success. Faster feedback makes you good at course correcting and guiding you to the right decisions.
Product teams are always looking for ways to build a better understanding of the impact created by a new feature and the ways users interact with it. Depending on the feedback, teams can draw conclusions from real-life use and decide if a feature should become generally available. The faster teams can make these decisions, the more successful they will be.
This is where dark launches come in. Dark launching is a deployment strategy that can provide safety and faster feedback by limiting the impact of new features to only a subset of users.
A safe way to gauge interest in a new feature
Dark Launching is similar to Canary deployments. However, the difference here is that you are looking to assess users’ responses to new features in your front-end rather than testing the performance of the backend.
The concept is that rather than launch a new feature for all users, you instead release it to a small set of users.
Usually, these users aren’t aware they are being used as guinea pigs for the new feature, and often you don’t even highlight the new feature to them, hence the term “Dark” launching.
You can use UX instrumentation to monitor if the feature improves the user experience or increases your revenue (e.g., the new feature may encourage them to spend longer using your app and thus consume more ads or make more in-app purchases).
This process is precisely what any product manager is doing when assessing how well an app performs. The only difference is that you are now looking at the performance of a single new feature.
Use feature toggles to incrementally roll out a new feature to more and more users and assess performance.
A feature toggle is a technique that attempts to provide an alternative to maintaining multiple source code branches. Feature toggles hide, enable or disable the feature during run time. A feature can be tested even before it is completed and ready for release.
Dark Launching enables product teams to roll back features that are not performing well or fully launch features that users love.
Empower the DevOps team to safely experiment
Dark launching empowers DevOps teams to safely experiment with new features and new software versions at a lower risk. This creates faster feedback cycles so that product teams can adjust features and software versions to the needs and wants of the users and the markets they serve faster than their competitors.
Gauge interest in new features
Product teams can gauge interest and adoption of new features with dark launches and feature toggles. They can make rollout decisions based on how the current subset of users accept the new feature and determine how it will help with the success of the product and company.
Allows you to deploy a new feature in a controlled way
Like canary releases, dark launching and feature toggles will enable you to roll out new features in a controlled manner. However, dark launches and feature toggles do not require you to run multiple versions of an application in an environment simultaneously, which you must do for a canary release.
Reduces pre-production testing
Organizations can save time and money since features can safely be tested by actual users instead of QA engineers in production. Feedback would be directly from the users in a real-world production environment.
It might be challenging to adopt
Dark launches and feature toggles require you to change the code in the application you want to deploy. Development teams will need to design, code, build, maintain, and deploy this support. Implementing this support for legacy applications with large codebases could be problematic.
Feature Toggles could lead to more technical debt
Feature toggles require code updates to support the new feature. Once the feature has been tested and accepted, the feature toggle is no longer necessary. If you don’t have a process to maintain, update, and remove old temporary feature toggles, technical debt will increase.
Harder to understand and less secure
As more feature toggles are added, the code can become more fragile and brittle, harder to understand and maintain, and less secure. Feature toggling is about your software being able to choose between two or more execution paths based on a toggle configuration. This increases the complexity of the code and makes it harder to test, support, and secure.
Encapsulate feature toggles with the business logic it supports
As a general rule of thumb, you should try to encapsulate your feature toggle with its supported business logic. This will help avoid having other areas of your codebase be aware of the context needed for toggling the feature. Sometimes, this is impossible, so the toggle should be placed closest to the service call, passing a parameter to the target services.
Establish a baseline of service levels to monitor and test for success
Ensure that you are setting service-level objects and determining service level indicators to track the service or feature impacted performance. It’s critical to have the tools and infrastructure to assess the system’s performance, monitor for unexpected responses to client requests, and compare any system deviation to a baseline.
Create a retirement plan and process for feature toggles
Development and delivery teams are asked to add toggles for various reasons but aren’t often asked to remove a toggle after it has served its purpose. Teams need to put processes in place to ensure that toggles are eventually retired. Whether adding a toggle retirement task to the team’s work backlog or creating an expiration notification event when a toggle’s expiration date has passed, you should have an automated system that manages the lifecycle of a feature toggle.
Dark launching is a deployment strategy that high-performance DevOps teams use to deliver new features to customers in a safer, low-risk environment, allowing teams to experiment, adjust, and continually improve their products and services.
There is a lot to consider and many other strategies, but the good news is that the best strategies are in the OpsMx Advanced Deployment Strategies eBook. The eBook summarizes the most common deployment strategies used by companies like Google, Netflix, and Amazon. The ebook covers strategies, benefits, challenges, and best practices. It also gives you a primer on Progressive Delivery.