4 ms·

[I work at flickr and gave the presentation linked to above] You don't need to test every permutation. Pretty much all of the flags in the codebase are indepen

[I work at flickr and gave the presentation linked to above] You don't need to test every permutation. Pretty much all of the flags in the codebase are independent of each other - someone might be working on changes to our admin interface in some files while someone else is changing the way comments are displayed elsewhere. There's no overlap in the changes. If the flags do interact with each other then in most cases the features will launch one after another, so you only need to test a handful of states (foo off bar off, foo on bar off, foo on bar on) If the flags interact with each other and the features will be launching at the same time (or the betas overlap) then you have to do the same amount of integration testing that you'd have to do with landing several branches into trunk at once. This is complex, we don't do it very often. And we clean up flags once they're not needed any more, which minimizes the possible combinations. I was skeptical about this before I started working at flickr, now I can't imagine working any other way.

mmastrac 17y ago
How do you guys handle plumbing work on different layers? Do you ever launch something that doesn't correspond to a specific user feature (say a cleanup to make something more reliable or efficient)? We're looking at what we can do to adopt continuous deployment in our own shop. I suspect that it requires a bit of rethinking how development happens.
- paulhammond 17y ago
  All the time. For example, we switched from one video transcoding backend to another recently. Having a single config flag used to chose which codepath a video went through meant we could launch it for staff only at first. Then, as we rolled it out to more people we could very easily switch to the old codepath if we found issues. We've used flags for changes at all layers within the application code itself - whether to use the more optimized javascript, the new css sprites, the new database access layer, the new database schema, the new spam detection system etc etc. You get even more out of config flags when deploying non-user facing changes - nobody knows if you roll it back so you can turn it off and on as many times as you need to get detailed data on exactly what impact the new code has on your metrics (both business and infrastructure). One thing we don't use flags for is changes in the layers below the application - the OS, web server, php libraries etc. It's much easier to roll these out server by server.

mmastrac 17y ago

How do you guys handle plumbing work on different layers? Do you ever launch something that doesn't correspond to a specific user feature (say a cleanup to make something more reliable or efficient)? We're looking at what we can do to adopt continuous deployment in our own shop. I suspect that it requires a bit of rethinking how development happens.

paulhammond 17y ago
All the time. For example, we switched from one video transcoding backend to another recently. Having a single config flag used to chose which codepath a video went through meant we could launch it for staff only at first. Then, as we rolled it out to more people we could very easily switch to the old codepath if we found issues. We've used flags for changes at all layers within the application code itself - whether to use the more optimized javascript, the new css sprites, the new database access layer, the new database schema, the new spam detection system etc etc. You get even more out of config flags when deploying non-user facing changes - nobody knows if you roll it back so you can turn it off and on as many times as you need to get detailed data on exactly what impact the new code has on your metrics (both business and infrastructure). One thing we don't use flags for is changes in the layers below the application - the OS, web server, php libraries etc. It's much easier to roll these out server by server.