Kommentare zu: DIY dark-launching feature toggle in 16 lines of Ruby http://blog.hendrikbeck.com/2015/02/02/ruby-rails-dark-launch-feature-toggle-diy/?utm_source=rss&utm_medium=rss&utm_campaign=ruby-rails-dark-launch-feature-toggle-diy Tech Startup Craftsmanship Sun, 03 Apr 2016 21:59:00 +0000 hourly 1 http://wordpress.org/?v=3.8.1 Von: Fredrik Wendt http://blog.hendrikbeck.com/2015/02/02/ruby-rails-dark-launch-feature-toggle-diy/#comment-75 Sun, 03 Apr 2016 21:59:00 +0000 http://blog.hendrikbeck.com/?p=695#comment-75 Well, I’ve seen code _very_ similar to that work just fine. The biggest challenge I’ve seen with toggles is knowing what you’ve tested, since all those flippers/switches/toggles/gates can be … toggled/switched on/off and typically at runtime. So what code paths did we actually massage in our pipeline(s) – where they relevant to what we’ll have running in production? (Second biggest issue is maintenance and knowing when to remove switches, but that’s highly tied to the context and whether you have control of all production sites or not (not = you deliver to other organisations who in turn develop software based on what you’ve built).)

I think the point of “dark launching” is that whatever you just deployed (let’s call it “next” version), is actually taking on load from real production data (calls, requests, queues, …) so you can observe the “next” version’s behavior without exposing it publicly (so, “in the dark”). (Thus, if the code deployed is not processing production data, I wouldn’t call it a “dark launch”.) This way, you could say that the problem above – “what did we test, and does it say anything about what will run in production?” – is handled by letting the “next” version run along side the “current”, until we’re sufficiently happy that it will work and perform as needed.

Does this makes sense to you?

]]> Von: hendrikbeck http://blog.hendrikbeck.com/2015/02/02/ruby-rails-dark-launch-feature-toggle-diy/#comment-72 Sun, 03 Apr 2016 21:16:00 +0000 http://blog.hendrikbeck.com/?p=695#comment-72 Hey Fredrik,

thanks for your comment.

I don’t actually want to try too hard to defend what I did here, wasn’t really my finest hour and more of a little hack than anything serious.

But since for the sake of the argument: I would say you could use the toggle to limit access to new features on different levels. For example, the pieces of code that receive calls can be open and let load onto the system while at the same time limiting certain UI features that give users access to the new data. In that case it would satisfy your definition of dark launching, wouldn’t it?

So, my point is that it’s rather up to how you use it whether it’s dark launching or just toggling a few lines of code. What do you think?

Cheers
Hendrik

]]> Von: Fredrik Wendt http://blog.hendrikbeck.com/2015/02/02/ruby-rails-dark-launch-feature-toggle-diy/#comment-71 Sun, 03 Apr 2016 19:59:00 +0000 http://blog.hendrikbeck.com/?p=695#comment-71 Hi Hendrik!
I wouldn’t call this Dark launching, as the new code is not exercised. I would call this simply (binary) a feature toggle. For it to be a Dark launch, I expect the new system or code to receive calls, so that you can observe whether the “dark” system/code will handle the load it will receive once public, and the correctness of the results it produces. These results, however, aren’t made public. Hence the system operates in the “dark”, in the shadows of the real system that the public can see.

]]>