17 May 2016

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” »

11 May 2016

Feature Flagging for Back-End & Microservices

LaunchDarkly feature flagging for backend microservices

I sat down with LaunchDarkly Lead Software Engineer Patrick Kaeding to get his take on feature flags for the back-end and how feature flagging works with microservices.

Andrea: How does feature flagging help in back-end projects?

Patrick: It helps in general to be able to rollout to a small set of canary users and see if things go wrong. You can gather feedback from performance metrics or error logs. You can give a smaller customer access to the new feature or even a group of customers who know they are testing out something bleeding edge. Then you can make changes and react to the feedback and then roll it out to all users or roll it back. This helps mitigate risk and lets everyone sleep better at night.

Andrea: What was it like before you used feature flags?

Patrick: You would have to make a change – and test it of course, that part hasn’t changed – but then you would release it out to all of your users. You’d be watching everything to make sure nothing went wrong – and it would be a lot more stressful. You might have to time your deploy for a low traffic time, which meant staying up late on the weekend to be able to do the deploy at that time. And if something went wrong, you’d have to rollback the deploy. And if there’s any sort of data model change, sometimes rolling back to the old code is easier said than done. You might have to make sure you have a reverse migration in place and that adds a whole lot of complexity. Of course with feature flagging you still need to make sure both code paths still work in the data model. That’s still something you have to think about.   

Continue reading “Feature Flagging for Back-End & Microservices” »

03 May 2016

Feature flagging to mitigate risk in database migration

There comes a time in every developer’s life when you realize you need to migrate from one database to another. Maybe you started off with MongoDB, and it was great while your app was small, but it just can’t handle the load now that you made it to the big leagues. Maybe it’s time you bit the bullet and put that huge events database in DynamoDB (or Cassandra, or…).

Moving databases is no small task, but it doesn’t need to be so risky.

One of the common misconceptions is that feature flags are only useful for new features, or for cosmetic changes. It turns out they are extremely useful for doing things like database migrations. I won’t say that feature flagging your database migration will make everything easy, but it will make it easier to test it with real, live data (for a subset of your user base), and much easier to roll it back if something goes wrong.

Continue reading “Feature flagging to mitigate risk in database migration” »