22 Aug

Feature flagging and testing

Sam Stokes, Rapportive co-founder, has this tip on testing and feature flagging:

“I’ve found that explicitly testing both sides of the flag can help with managing the increased complexity a flag introduces.  It helps you catch changes down the line that would have broken the old, forgotten code path that 10% of customers are still on.  It provides reminders to clean up the old code and delete the flag (via occasionally breaking the tests).  And it provides some pushback against having too many interacting flags (if you had to write 8 tests for one function because it depended on three separate feature flags, maybe it’s time to refactor that function, or retire some flags).”

Sam Stokes regularly blogs here.

17 May

How to use feature flags without technical debt

Or, won’t feature flags pollute my code with a bunch of crufty if/then branches that I have to clean up later?

People often ask for advice on maintaining feature flags after they roll out the new code to all users. Here is one way to approach the issue of cleaning up the old code paths. It works pretty well for our team. If you have any other ideas, please let us know!

Write the new feature

Step one is to write the new feature, gated by the feature flag, on a short-lived feature branch off of master (call it pk/awesome-xyz-support):

Next, before you submit your pull request for this change, create a second branch, off of the first, and call it cleanup/awesome-xyz. This branch removes the feature flag, leaving just the new code:

Continue reading “How to use feature flags without technical debt” »

13 May

LaunchDarkly – Now Serving Billions of Feature Flags at Warp Speed

It’s been a busy spring for LaunchDarkly, the leading feature flag management company.  We’ve hit a huge milestone – we’re serving  Billions (with a B) feature flag events daily, for companies all over the world. 

LaunchDarkly helps companies with better DevOps by managing code deployment separately from business logic. We allow an entire product development organization to control who gets the right feature, when. Developer tool companies like CircleCI, Apiary and AppDirect use us to power their own DevOps.  But, LaunchDarkly isn’t just for developer tool companies to reduce risk and iterate quickly on feature release.  Across industries, companies like Ten-X, Behalf, Handshake, and TrustPilot integrated LaunchDarkly into their development and release cycles to move faster with higher quality. 

Why are companies moving so quickly to LaunchDarkly?  We offer true polyglot support for web and mobile applications. Have a Node.js web application with Go micro-services and a mobile app written in Swift?  We got you covered.  And, more importantly, we allow companies like CircleCI and Behalf to go beyond DevOps to transform the way they deliver software from idea to delivery by uniting product management, engineering, QA and operations. We offer end to end feature flag management to allow an entire product development organization to control who gets the right feature, when.

To help spread the word about the power of feature flagging, we also have awesome partners.  We were thrilled to participate in the Microsoft Build in March.  I was part of the Microsoft DevOps Keynote, showing our end to end integration with Visual Studio Team Services.  And we’re proud to power feature rollouts for effective DevOps at companies like: Continue reading “LaunchDarkly – Now Serving Billions of Feature Flags at Warp Speed” »

26 Apr

To Be Continuous: DevOps 2.0

In this episode, Edith and Paul discuss the emergence of the term DevOps 2.0 and try to decide what it means, they talk about the incredible early validation powers continuous delivery gives your team, and they denounce the unnecessary risks of April Fools jokes not backed by continuous delivery. This is episode #18 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: DevOps 2.0” »

26 Apr

Zombies eating your AWS bill?

Zombies AWS Bill LaunchDarkly Feature Flags

The near-infinite elasticity of Amazon’s EC2 service is amazing. You can easily and cheaply spin up new instances whenever you need them. At LaunchDarkly, we provision new instances every time we deploy a new version of one of our services, which often happens multiple times in a day. We use Ansible to orchestrate the provisioning and deploy process, which means that we have easily repeatable deploys, and no server is a snowflake. Using the ‘cattle, not pets’ mindset, we routinely create and destroy instances. The script basically does the following steps:

  1. Provisions a fresh set of instances using a base AMI image that we have created
  2. Pulls down the latest code and config files from S3 (which is where our build server publishes to)
  3. Runs a few smoke tests to be sure the app has started up
  4. Swaps the load balancer configuration so the load balancers start sending traffic to the new instances
  5. Waits for the old instances to finish processing any requests that they had received before the load balance switch
  6. De-provisions the instances running the old version of the code

Continue reading “Zombies eating your AWS bill?” »

26 Feb

To Be Continuous: Staging Servers and Continuous Delivery

In this episode, Edith and Paul discuss a blog post by Edith in ReadWrite. In the article, Edith asserts that you should kill your staging servers so that continuous delivery can live. This is episode #14 in the To Be Continuous podcast series all about continuous delivery and software development. Continue reading “To Be Continuous: Staging Servers and Continuous Delivery” »