26 Aug

3 Ways to Avoid Technical Debt when Feature Flagging

Feature flags are a valuable technique of separating out release (deployment) from visibility. Feature flags allow a software organization to turn features on and off at a high level, as well as segment out their base to allow different users different levels of access. However, feature flags have an (ill-deserved) reputation of “Technical Debt”. Used incorrectly, feature flags can accumulate, add complexity, and even break your system. Used correctly, feature flags can help you move faster. Here’s three easy ways you can avoid technical debt when using feature flags.

  1. Create a central repository for feature flags

Using config files for feature flags is “the junk drawer” of technical debt. If you have seven config files with different flags for different parts of the system, it’s hard to know what flags exist, or how they interact. Have one place where you manage all of your feature flags.

  1. Avoid ambiguously named flags

Give your flags easy to understand, intuitive names. Assume that someone other than you and your flag could potentially be using this flag days, months, and years into the future. Don’t have a name that could cause someone to turn it on when they mean off, or vice versa. For example “FilterUser”, when it’s off – does this mean users are filtered? or not?

  1. Have a plan for flag removal

Some flags are meant for permanent control, for example for an entitlements system. Other flags are temporary, meant for the purpose of a release only. If a flag can be removed (because it’s serving 100% or 0% of traffic), it should be removed, as quickly as possible. To enforce this rigor, when you write the flag, also write the pull request to remove it. That way, when it’s time to remove the flag, it’s a two second task.

10 Aug

NDC Sydney: Developer Tools Down Under

I was honored to speak at NDC Sydney last week on “Faster and less risky releases with feature flags”. Just for clarification, NDC is “Norwegian Developer Conference”, which is so popular that they now have a London and Sydney event. NDC focuses on Microsoft technologies (.Net/Azure) and Agile. Attendees were a great crowd of Australians from Sydney, Brisbane, Perth and all over, as well as many international speakers. The talks were a good mix of practical (Damian Brady‘s demo on Octopus Deploy) to the theoretical (“What is Technical Debt?”). Adam Cogan had seen me speak at Microsoft Build and suggested I apply, and I was happy I attended.

At my talk on feature flagging, attendees were split between those who were already feature flagging and wanted tips on how to get better, and those who wanted to incorporate feature flagging into their development process. There was general buy-in that feature flagging was a valuable tool to help reduce risk and iterate quicker.

NDC Sydney did a good job of mixing in networking with talks. There was a Sydney Harbor Boat Cruise, as well as PubConf, with Ignite talks. The talks were so funny I wished I could have tweeted them, but organizer Todd Gardner said they were off the record.

I even managed to feature flag myself in Sydney. At a conference happy hour, I tell the group I’m here to speak about feature flagging:

IMG_8173 (1)

Sydney Flagged for Olympics

Guy: “Feature flagging? That’s the way all development is going.”
Me: “Yep! Absolutely”
Him “Do you think feature flagging as a service will take off?” he asks the group around us. Everyone jumps in with an opinion.
Him “There’s a company in Silicon Valley doing feature flagging as a service, can you believe it?”
Group weighs in with thoughts.
Then the guy pulls up a phone and shows everyone – the website of our company. LaunchDarkly.

At this point, it’s far more interesting to me to hear everyone else’s thoughts on feature flagging. It’s a loud bar at 7 pm, which is 2 AM my time. I’m jet lagged and soaking in candid feedback of the merits of feature flagging/toggling.

About 20 minutes later, I go talk to the original guy.

“Just so you know, I work for a feature flagging company…LaunchDarkly”.

Him: OH!

(more feature flagging geekery)

10 minutes later.. him – “So, the CEO of LaunchDarkly is a female.”

Me “Yes, that’s me”.

Him “!!!”

In short, I’d recommend NDC Sydney for any developer who wants both practical as well as cultural talks, as well as anyone who wants to connect with friendly Australian developers.

09 Aug

To Be Continuous: Using Continuous Delivery To Find Product/Market Fit

In this episode, Edith and Paul discuss discuss how you should use the principles of Continuous Delivery to find product/market fit for your startup, tool, or service. Along the way, they highlight common reasons startups fail to find product/market fit, from undervaluing sales and marketing teams, to simply believing that if you build it, they will come.  This is episode #23 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Using Continuous Delivery To Find Product/Market Fit” »

02 Aug

Feature Flag-Driven Releases

Feature flag strategy meeting

Using feature flags to incorporate a release strategy into your development process

 

The Old Way

The “old way” of software releases is characterized by an explicit waterfall hand-off between teams – from Product (functional requirements) to Engineering (build and deploy). This old way did not explicitly promote release planning in the development process. The full release burden was shifted from one team to another without plans for a feedback loop or integrated release controls.  Hence, it was difficult for teams to continuously deliver software, gather feedback metrics, and take full control over software rollouts and rollbacks.

With the rise of continuous delivery, teams are integrating feature release and rollout controls into the product development process.  This is ushering in a new era of DevOps where teams collaborate on release strategies during the initial design phase in order to manage a release throughout the development cycle, from local, QA, staging, and to production.

How will the feature be released?  Who will be getting this feature first?  Will it be gradually rolled out? Who will alpha/beta test it?  What if something doesn’t go right?  All of these considerations (and more) are typically not discussed in initial planning meetings. By codifying a release strategy from the start, you can ensure that your software release matriculates smoothly from build to release to sunset.

Release Strategy

Release strategy is a DevOps concept where teams integrate feature release planning into the development process.  Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases.  Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional.  The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.  It basically compels teams to incorporate a release strategy into the development process.

Josh Chu, Director of Engineering at Upserve, explains how his team incorporates release strategy:

“A lot of times people would say ‘let’s roll this out’ and not think about how to actually get adoption. The fact that you have a feature flag story raises visibility. Engineers start thinking about how their feature is going to get rolled out rather than just ‘push it to production, it’s done’. The product team is encouraged to take a more hands-on approach to pre-release feedback, which directly feeds into obtaining post-rollout traction.”

 

LaunchDarkly Rollout and Release Strategy Feature Flags and Feature Toggles

Strategic Rollouts Using Feature Flags

In this section, we illustrate an example of how a release strategy can be incorporated into a traditional design, build, test, and release process.

Stage 1 – Feature Design

  • Design the feature’s functionality, examine the target audience and use case, and develop a timeline for implementation.

Stage 2 – Release Strategy

  • Collaborate on rollout and release strategy.  Should the feature flag be a front-end flag, back-end flag, or both? (Front-end flags are mainly used to control UI visibility, while back-end flags can control APIs, configurations, and even routing).  What should be behind the flag?  Is this a permanent or temporary flag? (ex. permanent = ‘maintenance mode’, temporary = ‘new signup form’) Who has rights to change the flag?  Is the flag intended to control a percentage rollout? How will we incorporate user feedback? How will we measure adoption and traction?

Stage 3 – Build

  • Develop and integrate, using the feature flag to manage the feature’s progression through multiple development environments.

Stage 4 – Test

  • Test the feature in QA and Staging, using the feature flag to control rollout and user targeting.

Stage 5 – Release

  • Deploy the feature as ‘off’ in production and then implement your release and rollout strategy.  This could be an incremental percentage rollout, individual user targeting, or targeting groups of users.

LaunchDarkly Rollout and Release Strategy Using a Feedback Loop Feature Flags and Feature Toggles

Feedback Loop

By adopting a release strategy, Engineering, Product, and Design teams can continuously collaborate on release and rollout plans, assessing user and performance feedback along the way.  Bryan Jowers, Product Manager at AppDirect, comments on the benefits of controlled rollouts, “It allows us to bring product to market faster, test, get data, and iterate… Engineering, Product, and leadership are all looking to deliver product with low risk… and we do that with tightly controlled rollouts.”

Instead of pushing a future to production and being done with it, teams should be designing release strategies that incorporate targeted/incremental rollouts with the intention of iterating based on feedback.  This creates a continuous feedback loop because teams can synthesize performance metrics and transform those metrics into better, faster iterations.

Take-Aways

Release strategy incorporates release and rollout planning into the development process.  It forces teams to plan for feature rollouts and develop methods for aggregating user feedback, analyzing metrics, and assessing traction.  One of the proven ways to do this, as used by teams at Upserve and AppDirect, is to use feature flags to launch, control, and measure features from development to release.

 

LAUNCHDARKLY HELPS YOU BUILD BETTER SOFTWARE FASTER BY HELPING MANAGE FEATURE FLAGS AT SCALE. START YOUR FREE TRIAL NOW.

 

14 Jul

To Be Continuous: Scott Raney of Redpoint Ventures on Why Continuous Delivery Matters

In this episode, Edith and Paul are joined by Scott Raney, Partner at Redpoint Ventures. Edith, and Paul hear from Scott why continuous delivery matters in modern software development. This is episode #21 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Scott Raney of Redpoint Ventures on Why Continuous Delivery Matters” »

08 Jul

Feature Branching Using Feature Flags

Feature Branching Using Feature Flags Github LaunchDarkly

Feature branching allows developers to effectively collaborate around a central code base by keeping all changes to a specific feature in its own branch.  With the addition of feature flags, feature branching becomes even more powerful and faster by separating feature release management from code deployment.

The Pains of Long-Lived Branching

Traditionally, new development has been done via branching.  These branches typically live for months at a time, with silos of developers attempting to work in parallel.  Long-lived branches often become the “I owe you”  of Gitflow: “I promise to address these merge conflicts… later.”  The pain points that Git was supposed to address — merge conflicts, missing dependencies, and duplicate code — gradually emerge the longer a branch lasts.  We then concentrate all the pain of reworks and conflict remedies until the end, which arguably makes the pain much worse.  To avoid these long-lived branching issues, branching with feature flags enables devs to effectively manage short-lived feature branches and continuously deliver better software.

Feature Branching

To help coordinate development, engineering teams have adopted distributed version control systems (like GitHub and BitBucket).  These systems allow developers to collaborate within a central codebase and use branches to make updates or develop new features.  Feature branching, therefore, has become a staple of modern development cycles because they allow developers to function without encroaching on each other’s progress.

One of the shortcomings of feature branching is that feature release management is still tied to code deployments.  In isolation, feature branching forces engineers to manage software delivery within the confines of their version control system.  Non-technical users can’t (and shouldn’t) manage feature visibility and distribution for customers from GitHub.  It is currently not possible for developers to turn features on or off in real-time, as a way to manage risk or gradually introduce a new feature.

Feature Branching Without Feature Flags LaunchDarkly

This diagram illustrates how developers create feature branches to manage feature development, ensuring that the current build is always in a deployable state.  While every company’s branching structure will be different, the basic premise is that you branch from a repository to make a new feature.

Feature Branching Using Feature Flags

This is where the introduction of feature flags makes feature branching exceptionally powerful.  Feature flagging allows developers to take full control of their feature lifecycles independent of code deployments.  Application features can be enabled or disabled without requiring code to be reverted or redeployed.

This process is called feature flag driven development, where continuous delivery teams manage feature rollouts separate from code deployments.

Feature Branching With Feature Flags LaunchDarkly

Benefits

Feature flagging allows developers to take full control of their feature lifecycles without depending on code deployments.  When you merge a feature branch into master (production), it is already wrapped in a feature flag.  This allows you to deploy the feature “off” and then gradually roll it out to users.  It also allows you to quickly “kill” the feature if it is not working well, without having to redeploy.  Other benefits include:

  • Better team communication
      • Developers continuously collaborate on new releases, coordinate efforts, and ensure that everyone is moving forward in tandem.
  • Logical deployments to prevent blocking
      • Deploy code in logical chunks without resorting to long-lived branching.  Even if a feature is not fully ready, it can be flagged ‘off’, but still deployed.
  • Exposed dependencies
      • Short-lived branching allows you to manage dependencies by removing the ones that are unnecessary.
  • Faster development
      • Spend less time addressing merge conflicts and refactoring old code.  Spend more time delivering features that users want.
  • Risk mitigation
      • A feature can be flagged throughout the entire development process, from local, QA, staging, and production.  This means that it can be toggled on or off in isolation, without impacting other development environments.
  • Manageable code reviews
    • Because you are merging more often, code reviews become less tedious and merge conflicts less onerous.

Better, Together

Modern DVCS combines the benefits of short-lived branches and feature flags.  Tools like GitHub and Bitbucket enable continuous delivery and short-lived branching, while feature flags help make branching faster, less risky, and more manageable.
Therefore, feature flagging does not replace branching, it is complementary and makes it more powerful. Feature branching provides the flexibility to decide when and what to release, while feature flagging lets you take full control of the release itself.  Together, branching and flagging help you maintain and integrate short-lived branches faster and with less risk.