4 ms·

Overall feature toggles are an interesting idea. I'm not quite as adverse to long lived branches as some seem to be, especially with CI systems that can automat

by cpitman 11y ago

Overall feature toggles are an interesting idea. I'm not quite as adverse to long lived branches as some seem to be, especially with CI systems that can automatically detect merge conflicts when they first occur and run automated tests on the merged code base. However, this part seems strange to me: > The team particularly appreciate that this will allow them to test their new algorithm without needing a separate testing environment. Even with feature toggles, I would never want to test a new feature for the first time in my production environment. Sure, the feature isn't on for everyone. But it still can have a performance defect that brings the overall system to its knees or a functionality defect that corrupts the data store for everyone.

benjiweber 11y ago
I find it amusing when CI tooling is used like this, to allow people to keep changes isolated in separate branches with less pain from delaying the integration. It's more Continuous Isolation than Continuous Integration. There are ways to test features for performance/accuracy in the production environment with reduced risk. One approach I've used successfully is branch by abstraction with verification. http://www.alwaysagileconsulting.com/articles/application-pattern-verify-branch-by-abstraction/ http://www.alwaysagileconsulting.com/articles/application-pa... Essentially you first extract a common interface for the component you are replacing. Then you release both versions and send (all or a percentage of) input events to both the old and the new implementation. You discard the response from the new implementation and continue using the old codepath for responding to users / performing calculations, but importantly - you compare the old and new results and alert/log if they differ. This allows you to gain confidence in a new implementation's behaviour in the production environment and integrate your code with the rest of the system with significantly reduced risk. When you're happy you can flip over to the new implementation and delete the old. There are also various other techniques for reducing the risk of datastore corruption that you mention. I've written about some of them here http://benjiweber.co.uk/blog/2015/03/21/minimising-the-risk-of-data-damage/ http://benjiweber.co.uk/blog/2015/03/21/minimising-the-risk-... Most of these risks are actually smaller with more frequent and smaller releases of functionality into production. Releasing more regularly also encourages you to think about how to properly mitigate these risks.
sambe 11y ago
There is a substantial section of the article about modifying their high level tests to test both branches and keeping the toggle off in production whilst turning it on for some exploratory testing.
qwer 11y ago
> I'm not quite as adverse to long lived branches as some seem to be, especially with CI systems that can automatically detect merge conflicts when they first occur and run automated tests on the merged code base. This system of branching is clearly the best way to maximize large merge conflicts, if you think about it. Let me restate this: The main reason that you branch (to avoid conflicts with other devs) is the single scenario that this system does the absolute worst at. Conversely, if you're not having problems with this system, you never needed it in the first place.

by cpitman 11y ago

benjiweber 11y ago

I find it amusing when CI tooling is used like this, to allow people to keep changes isolated in separate branches with less pain from delaying the integration. It's more Continuous Isolation than Continuous Integration. There are ways to test features for performance/accuracy in the production environment with reduced risk. One approach I've used successfully is branch by abstraction with verification. http://www.alwaysagileconsulting.com/articles/application-pattern-verify-branch-by-abstraction/ http://www.alwaysagileconsulting.com/articles/application-pa... Essentially you first extract a common interface for the component you are replacing. Then you release both versions and send (all or a percentage of) input events to both the old and the new implementation. You discard the response from the new implementation and continue using the old codepath for responding to users / performing calculations, but importantly - you compare the old and new results and alert/log if they differ. This allows you to gain confidence in a new implementation's behaviour in the production environment and integrate your code with the rest of the system with significantly reduced risk. When you're happy you can flip over to the new implementation and delete the old. There are also various other techniques for reducing the risk of datastore corruption that you mention. I've written about some of them here http://benjiweber.co.uk/blog/2015/03/21/minimising-the-risk-of-data-damage/ http://benjiweber.co.uk/blog/2015/03/21/minimising-the-risk-... Most of these risks are actually smaller with more frequent and smaller releases of functionality into production. Releasing more regularly also encourages you to think about how to properly mitigate these risks.

sambe 11y ago

There is a substantial section of the article about modifying their high level tests to test both branches and keeping the toggle off in production whilst turning it on for some exploratory testing.

qwer 11y ago

> I'm not quite as adverse to long lived branches as some seem to be, especially with CI systems that can automatically detect merge conflicts when they first occur and run automated tests on the merged code base. This system of branching is clearly the best way to maximize large merge conflicts, if you think about it. Let me restate this: The main reason that you branch (to avoid conflicts with other devs) is the single scenario that this system does the absolute worst at. Conversely, if you're not having problems with this system, you never needed it in the first place.