Feature flagging is a technique development teams deploy to enable easy switches between codepaths in their systems, at runtime. In simpler terms, they’re control structures that toggle on and off the code inside them. Dev teams use feature flags for a wide variety of purposes, from canary releases to A/B testing, from dark launching, to controlled rollouts.
Today, we’ll take a look at one of the most common use cases for feature flags: continuous deployment. Before we dive into CD, we first need to cover CI.
Feature Flags and Continuous Integration
Many teams implement continuous integration (CI) before continuous deployment or delivery (CD). Continuous integration is the process of constantly merging to trunk (or main) to avoid the “merge hell” which often comes from trying to merge many different feature branches created by many different developers or development teams. It saves time in the development cycle — the key benefit of “continuous” anything — by fixing potential merge conflicts early on.
Because teams often set up automated testing as a part of continuous integration, this lays the foundation for both continuous delivery and continuous deployment.
Continuous Delivery vs. Continuous Deployment
People often confuse continuous delivery with continuous deployment. They are similar development processes, to the point that they share an acronym (CD), but they have a very important difference in quality assurance and testing.
With continuous delivery, developers push every new feature which has passed automated tests to a clone of the production environment, where the new code is manually tested. While continuous delivery is the more traditional development process, as it is much easier for development teams to attain and has more fault tolerance, it is relatively inefficient and frequently creates a backlog of new features waiting for manual testing.
With continuous deployment, however, there is no manual testing process before new code is released to production: any code that passes the automated testing process is deployed straight to end-users. This speeds up the deployment process significantly since the deployment of new features is no longer limited by the capacity of the testing team.
Teams implementing continuous deployment (without feature flags) need to be very thorough in their automated testing processes because they are the only safeguard between the new code and the end-users. If there is a bug or issue which makes its way through automated testing, the people who find it will be the users, which will have negative consequences for the company’s reputation and the perceived stability of their software.
Feature Flags and Continuous Deployment
While continuous deployment is possible without feature flags, it is very difficult and the stakes are high. Implementing feature flags adds safety to a continuous deployment process by putting a kill switch on each new feature. If it turns out that a bug made it past automated testing and into a feature release, you don’t need to do a complicated rollback, only turn off the feature toggle. This minimizes the number of end users who are exposed to the error and means you only have to disable the specific feature with the bug, not the entire feature release.
In order to implement continuous deployment with feature flags at scale, many development teams have chosen to use feature flag management systems, which help them to not only use feature flags but track them. This way, they can see the status of their features and feature flags, and retire old or outdated features, and remove feature flags that are no longer in use. In addition, many feature management platforms are open source, which enables third-party integrations and add-ons as well as personalization.
In addition to using feature flags to manage continuous deployment, you can also take continuous deployment to the next level with something we will call micro-deployments. These are ultra-small code deployments that allow you to deploy one feature at a time whenever they’re ready instead of bundling multiple features into a larger package. This enables maximum release speed, allowing development teams to get new features in front of users at essentially the pace they’re created.
Learn More About Feature Flags, CI/CD, and Experimentation
The use of feature flags can facilitate continuous deployment and micro-deployments and can improve the effective quality of your software by reducing the visibility of bugs and errors to end users while simultaneously speeding up your software release train.
If you’d like to learn more, we recommend these additional resources from our team here at Split:
- Adaptability in Software Development Must be Powered by Informed Action
- Why You Need Feature Flags as a Service
- Database Migrations with Feature Flags
- To Feature Flag is to Experiment
- How to Compare Trends in Your Experiments
As always, we’d love to have you follow along as we release new features and build new resources like those linked above. Check out our YouTube channel (and don’t forget to subscribe!), and follow us on Twitter @SplitSoftware.
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.