DevOps is always evolving. Continuous delivery made a major impact on the way software is deployed, but we don’t think the innovation stops there. As we move into more of a multi-cloud, hybrid development world, continuous delivery has continued to change into something more “progressive.”
Progressive Delivery isn’t exactly the new idea that continuous delivery was; it’s simply a continuation of it. What Progressive Delivery does is give more precision to the delivery process through new ideas and best practices, reducing the risks of one big, risky deployment. At GitLab, we think Progressive Delivery is the next logical evolution of DevOps beyond CI/CD and will become the default way to release software in the future.
We previously discussed how Review Apps can enable Progressive Delivery, and today we’ll discuss the targeted rollout process of Feature Flags.
What are Feature Flags?
Feature Flags (also known as feature toggles, feature flippers, or feature switches) give developers the ability to roll out features selectively without changing the source code. Incomplete features can be merged into the production code but flagged on or off, which allows many small, incremental versions of software to be delivered without the cost of constant branching and merging.
Feature Flags are designed to minimize the blast radius of releasing new features. By utilizing Feature Flags, developers can release to a subset of users and roll back easily through toggling, leaving the live code intact. A feature can also be tested before it’s completed and ready for release. This technique allows developers to release a version of a product that has unfinished features which are hidden (toggled) so they do not appear in the user interface.
Martin Fowler organizes Feature Flags into four different categories based on how long they’re typically in place and how dynamic they should be:
- Release toggles: A temporary flag which allows incomplete, latent code to be shipped to production and turned on or off, or perhaps never enabled at all.
- Experiment toggles: A short-lived toggle usually used for multivariate A/B testing, kept in place only long enough to gather results.
- Ops toggles: For releases that have unclear performance implications, this toggle allows system administrators to roll back quickly, but it’s not unheard of for long-term toggles to remain in place as a kill switch.
- Permission toggles: Manages features for specific users, such as “premium” features, alpha or beta features, or even internal features. These toggles can be very long-lived.
Feature Flags can be a quick way to do version control so that continuous delivery remains continuous. Their ability to turn off or on with simple commands makes Feature Flags a low-risk option for introducing new features. While they’re easy to use, they can have some drawbacks if not implemented properly.
Working with Feature Flags
Some worry about the added complexity with Feature Flags, since code may need to be tested with toggles on and off, essentially doubling the load. While it’s not necessary to test every toggle configuration, a best practice is for developers to test code that has the greatest likelihood of going live in production. According to Martin Fowler, a good convention is to enable existing or legacy behavior when a Feature Flag is Off, and new or future behavior when it's On.
Another risk of using Feature Flags is stale flags, a situation when flags are left in the code and forgotten about. As teams add more and more flags into their code, it can become harder to keep track of and verify the flags.
Today, organizations rely on feature management systems such as Launch Darkly or Optimizely in order to use Feature Flags. As with any link in a toolchain, this adds an additional level of oversight that can be hard to manage and maintain. Analysts recognize that feature-toggling capabilities are becoming more of what's fundamentally needed for a continuous delivery platform. While we are still in the early stages of Feature Flags, we do have some alpha Feature Flag capabilities already built into GitLab you can try out today, and we will be launching additional functionality in 12.2:
GitLab and Progressive Delivery
As we continue to iterate on our product vision for CI/CD, we’re adopting a Progressive Delivery mindset for how we implement new features into GitLab. As a complete DevOps platform, delivered as a single application, it’s important for us to offer a comprehensive solution that offers the latest best practices. Review Apps, Canary Deployments, and Feature Flags are just some of the ways we’re bringing Progressive Delivery to the GitLab community.
To learn more about how we’re using Feature Flags and Feature flag best practicies in GitLab, watch this deep dive with our Director of Product Management, Jason Yavorska.
Feature Flags can be a useful way to validate and measure performance before rolling out a feature to a broader audience. High visibility makes DevOps more efficient, and integrating Feature Flags into the same application where your code repositories, CI/CD, project planning, and monitoring occurs can overcome many of the challenges associated with Feature Flags.
Learn how GitLab’s built-in CI/CD helps teams implement Progressive Delivery tools such as Review Apps, Feature Flags, and Canary Deployments, without the complicated integrations and plugin maintenance.
Cover image by Chris Lawton on Unsplash
