How Using Feature Flags Across CI/CD Increases Insights and Productivity

There’s no question that continuous integration (CI) and continuous deployment (CD) make life easier and more productive for technology teams. Quality and customer satisfaction increase when you give them tools that deliver code faster.

Feature flags are one of the tools that make your CI/CD pipeline work better. They help your team shepherd features through your pipeline safely, quickly, and effectively. They make your team more productive while giving them feedback on how they’re doing at the same time.

We’ll talk about some of the pitfalls and best practices you should consider with feature flags and CI/CD in this post. Then we’ll go over how the flags can give your technology teams a boost as they monitor and test your development pipeline.

Feature flags are a way to change application behavior without modifying code or deploying a new version. They give you the ability to safely deliver new features to clients quickly with minimal risk.

A flag is a software toggle that enables or disables blocks of code. Think of an “if” statement in your favorite program language that is true only if the related feature flag is enabled. If it’s on, the block of code is available. If it’s off, the code is not.

A feature is a set of application behavior. Depending on how you implement it, it may comprise more than one block of code. So, feature toggle tools have a way to group blocks into a single toggle, giving you a way to associate a single flag with all the code related to a feature.

CI means integrating code changes from development teams, often ideally more than once a day. Developers frequently push their code changes to a source code repo, and automated tools merge the changes, trigger a build, and run automated tests.

CD is preparing software for delivery to environments often and automatically. Like CI, CD should deliver code several times a day. It relies heavily on automated tools for testing and packaging software. People usually associate continuous delivery and continuous deployment with each other. With continuous delivery, the software is ready for deployment. With continuous deployment, you deploy the software automatically, as soon as it’s ready.

CI and CD have many benefits because when they work together, they shorten the software development cycle. Product teams receive a constant stream of feedback on their work. You release fixes faster since you no longer wait for periodic releases. They also reduce errors and bottlenecks since you automate all the repetitive tasks in the release process.

CI/CD looks and sounds great on paper. Who wouldn’t want to get the benefits of a shorter release cycle and fewer errors? But it’s not risk-free. Software has bugs, and delivering code continuously can quickly turn from an asset to a liability.

That’s where feature flags come in. Since they give you a way to enable or disable new features without a build or a deployment, they act as a safety net. You can push out new features and turn them on or off as needed.

If you want to turn a feature on or off, it needs a feature flag. It doesn’t matter how trivial or complicated a feature is, flags must become a standard part of software creation for all developers to get maximum impact of their benefits.  

A fix or enhancement to an existing feature might be an opportunity for a flag, too. Adding the toggle may duplicate some code, but the ability to turn the new code on or off is often worth it. The extra code can be factored out when the flag is retired.

How big is a new feature? The answer may change when you add feature flags to the mix.

For feature flags to work safely, the features need to operate independently. Development and product management will need to work together to make sure that toggling one element doesn’t leave another in a bad state.

The initial response here is to put a single toggle around a large set of features.  But that defeats the point of both feature flags and CI/CD. It’s reverting to the waterfall process, with added complexity.

The right approach is to break the behavior down into smaller chunks and introduce them into the CI/CD pipeline gradually. You need to change both the way you specify features and how you released them. But again, enterprise flag management platforms have taken this into consideration and allow you to track dependencies between flags and features.

When you add a flag to the codebase, it needs to start as toggled either on or off. Then you have to communicate the state to the operations team. The flag’s state is part of the software release process. It’s an important release artifact, not a footnote or undocumented feature.

This state will change. It may be toggled enterprise wide or for different environments or clients, depending on how it’s used. Here again, the operations team needs to know.

An enterprise-wide view of feature flag states is a critical resource. Feature flags can become a liability without shared governance, and for that reason, enterprise flag management platforms are focused on creating pipeline-wide shared visibility of flag status across all teams. 

Feature flags have a life cycle, whether you plan one for them or not. If you don’t plan, that life cycle looks something like “forever.” Depending on what kind of flags they are, that means they turn into a code smell.

You can put flags into at least four categories:

1. release

2. experiment

3. ops

4. permissioning

Release flags should have short life cycles tied to the feature they toggle. When the feature is complete, you remove the flag. Experiment toggles can live for a long time since you can repeatedly refine the experiment. Permissioning flags might live forever, so the code they control needs to be designed with the flag in mind. Having a flag management tool that can determine which type of flag is which, and provide recommendations for flag removal or monitoring helps eliminate the bloated code headaches created from feature flags.

CI/CD means constant activity. Code moves through a pipeline that starts at each developer’s desk and ends in production. How do you know what’s working and what’s failing? Feature flags can help with that.

The first step is to use your feature flags in testing. Each test is an opportunity to toggle a flag and find unexpected side effects and undesired dependencies. This is true at CI time, with automated unit tests, and between delivery and deployment with your integration tests.

Testing doesn’t end when code transitions to production, though. The results of A/B experiments, alpha and beta testing, and staged rollouts are all made possible by adding feature flags to your CI/CD toolbox.

If you need to know how new code will impact performance, add a flag, even if it’s not a new feature that clients will know about. Now you have a new tool for evaluating performance. You can create a new A/B test or conduct a staged rollout. You can run your tests based on the state of the new toggle, and you can use them to evaluate performance reports from clients.

We mentioned how critical it is to share and agree on flag life cycles and states across all product teams. But a common view of feature toggle status is also an asset. When all stakeholders have visibility into a flag’s state, they all have an opportunity to apply it to their reporting and gain new insights. This is true across product management, development, operations and the executive teams viewing the data this is funneled into. 

We covered some of the governance and organizational changes you need to consider to make feature flags work well with CI/CD. We saw how your development teams need to use them when they add new code and how your product and operations teams need to factor them into defining features and rolling them out to clients. 

We also discussed how flags make it easier to track features as they move through your development pipeline. You can test your new features, target them to specific clients, and use them to measure changes in application performance.

This is the final blog in a three-part series on feature flags in CI/CD. To read the first blog on feature flags in CI, click here. To read the second blog on features flags in CD, click here.

Want to learn more?

• Download CloudBees Feature Flags Across CI/CD whitepaper and see how easy it is to improve your CI/CD pipeline with CloudBees Feature Management.

Ready to take the next steps

• Get started today! Sign up for CloudBees platform – Free up to 5 users