Feature Flagging 101: What Does Coding With Feature Flags Look Like?

Coding with feature flags

Last week, we told the story of what coding without feature flags looks like. We (intentionally) left a lot of bottlenecks unaddressed, so that we could tell the story of what coding with feature flags looks like today. 

If you know anything about DevCycle, you know we’re huge proponents of using feature flags alongside CI/CD to build really great software. For today's purpose, let’s pretend your development team is using feature flags and a trunk based branching strategy with a Continuous Delivery pipeline. Note: in Continuous Delivery, someone has to “press the deployment button” to deploy code (...unlike Continuous Deployment, where code is automatically released to your end users.) 

Let's see how the story unfolds:

It’s 9 am on a Thursday. (But remember, with feature flags, you can release code at 4 pm on a Friday if you really want to 😉) 

For the third time this week, your product team has come up with a new feature for your application. They expect the feature to be ready by the end of the day.

After daily standup, everyone is on board and knows what is expected of them.

With feature flags, your developers are not dependent on one another to complete their ticket, so each developer starts working on their respective tickets right away. They can work in their own feature branch or collaborate together in one. And the release of the entire feature is never held up by the longest-standing ticket.

Instead, devs simply work on their part of the code, and features can be released in small, incremental parts, allowing for faster release cycles. 

By 11 am, some of the code is already deployed to the development environment to be tested. Your automated end-to-end tests will run here to be sure everything is functioning properly. Your product manager can then review the code to make sure it’s good, and the feature can be manually deployed to production. 

In the production environment, your devs can release the feature to a small groups of users, such as internal employees or external beta users. From here, they can get valuable feedback on the functionality, look, and feel of the code.

At 2 pm, all of the code is completed, merged, and deployed to production.

Your dev team uses DevCycle’s gradual rollouts feature to release the code to your users incrementally (i.e. 5%, then 10%, then 20% and so on). This allows them to identify and fix issues before the feature is released to 100% of their users. 

There is no need for a post-code release celebration. (Unless you feel like celebrating, of course. We’re not here to rain on your parade. We just think you’ll eventually get tired of celebrating releases when they’re happening 5 times a day.) With feature flags, releasing code multiple times per day is woven into the fabric of your entire organization. 

And even better, there’s no post-code release anxiety. There’s no need for your developers to clear their calendars or sit around their computers anxiously awaiting bug reports. Instead, they can simply move on to tickets for the next feature release, attend their 1-1’s and retros, and go about their days.

They’re fairly confident that there is no issue with the code since it was thoroughly tested in a production environment prior to the release and gradually released to your users. But they know that, should an issue arise, they can quickly disable the entire feature flag and limit the impact to a smaller group of users.

They also know that it’ll be very easy to find the source of the problem, because the code was released in small increments (with smaller change footprints) than the large releases they were used to. They can quickly trace the issue back to the specific feature flag that was causing the issue. This allows for faster resolution of issues and minimizes the impact on users.

By 3 pm, your devs have started on their next release – all in a day’s time. 

Wrapping up

So you see, what used to take your team an entire month now takes 6 hours. Your release cadence and deployment frequency have improved. Your devs are more productive and more confident. You’re releasing impactful features and responding to user feedback faster than ever before. Feature flags can change the narrative. We would know, they changed ours. 

We hope you’re enjoying our Feature Flagging 101 blog series! So far, we’ve taken a deep dive into what feature flags really are, what coding without them looks like, and now, what coding with feature flags looks like. Stay tuned for more content coming this week!