4 ms·

I'm not quite sure I understand all of your comment, but I can respond to why one might want feature toggles rather than branches. One of the activities that c

I'm not quite sure I understand all of your comment, but I can respond to why one might want feature toggles rather than branches. One of the activities that can really improve the quality of code on a team is continuous integration. Now, I don't mean setting up a "CI" server to run tests for you when you push your code. I mean actually merging your code with your fellow programmers every 20 minutes or so. The reason this is such a powerful technique is that it gets people to see what you are doing pretty much as soon as you do it. If you do something stupid (as we all do), they complain instantly because they will merge in your code every 20 minutes. If you do CI well, there are no lingering surprises or hard decisions of "Well, maybe you should start all over again". The problem is that all the code is mixed up. This is completely fine if you have 1 or 2 week sprints and deploy at the end of the sprint. The problem is that this kills another really power technique called "continuous deployment". Ideally, we would like to deploy as soon as a story is finished. But if it's mixed up with a whole bunch of other code, then you need to make sure that the other code isn't going to break something. Enter feature toggles. It's a challenge to support both CI and CD at the same time. You can never break any code. It takes a lot of discipline, but if you can manage it, I guarantee pretty enormous improvements in both productivity and code quality (and even programmer happiness). And before you ask, yes I have had teams which did CI well, but no, we didn't do CD. It's not for everyone. But as I said, it's pretty powerful if you manage it.

kbenson 11y ago
But that's the point of a branch, a place to put your code before it's integrated into the whole as an "atomic operation" so: You aren't possibly breaking live code You making lots of changes to code other people might be changing, causing conflicts You don't need to either go back and remove the old branches after the deployment or leave them in to clutter the code. You don't have to worry as much about overlooking some portion of the codebase using the old code (if you change the API enough to make it incompatible), since you can literally remove old APIs and cause compile errors or easily detectable runtime errors. You can change data structures with conversion scripts where it's not feasible to overlap functionality (whether those be code constructs, or disk/DB format).
- geocar 11y ago
  No, that's not the point of the branch. The point of a branch is to label concurrent development. There's nothing about a branch that says it must be "test code" or "pre-release" code, but your perspective is common: Everyone wants blue/green or to fully distinguish between "live code" and "test code" because they think the problem isn't theirs to solve: That their manager doesn't give them enough time, or their predecessor didn't like clean code like you do, or that's just what test databases are for. Infrastructure that really supports branching is uncommon because it's difficult and it requires very careful consideration with regards to the entire architecture. Some examples of systems that actually use branching correctly: * Implement random 0.5%, 1%, 5% etc traffic diverted to test branches * Front-end web service selects branch from URL or cookie * Backend service compares 5% live queries against test database and compares results If your system doesn't have something like this, you're really missing out: Really big applications (the kind that span multiple continents) don't have an "atomic operation" to their deploy, and you shouldn't try to pretend that they do. That's how we got IPv6.
onion2k 11y ago
You can never break any code. That's a ludicrous expectation will lead to developers being scared of merging changings, which will in turn lead to them hiding mistakes, refusing to talk through their code, and ultimately hacking things in to the codebase that "work" but are terrible solutions to problems. It's far better to have a safe environment where a dev can branch a new feature, break the whole codebase completely if necessary, and only merge things back in when they're confident that their solution is a good one (with a review of the pull request by a maintainer or two). The aim of writing software is to make a good product that solves a problem. It is not to 'never break the build' or 'merge as often as possible'.
- lmm 11y ago
  > That's a ludicrous expectation will lead to developers being scared of merging changings, which will in turn lead to them hiding mistakes, refusing to talk through their code, and ultimately hacking things in to the codebase that "work" but are terrible solutions to problems. Maybe, but it can just as easily lead to good practice. E.g. if you're scared to change a particular piece of code, that's a red flag that that particular piece of code is inadequately tested - and "am I scared?" is a much better metric than automated test coverage reports.
tajen 11y ago
Most CI build tools can test branches. They can even merge from upstream on a temporary branch, return the failing tests, tell you when they started failing or being flaky (was it on a commit introduced to master by a recent merge?), then you know for every commit whether it would be green when you merge to master.

kbenson 11y ago

But that's the point of a branch, a place to put your code before it's integrated into the whole as an "atomic operation" so: You aren't possibly breaking live code You making lots of changes to code other people might be changing, causing conflicts You don't need to either go back and remove the old branches after the deployment or leave them in to clutter the code. You don't have to worry as much about overlooking some portion of the codebase using the old code (if you change the API enough to make it incompatible), since you can literally remove old APIs and cause compile errors or easily detectable runtime errors. You can change data structures with conversion scripts where it's not feasible to overlap functionality (whether those be code constructs, or disk/DB format).

geocar 11y ago
No, that's not the point of the branch. The point of a branch is to label concurrent development. There's nothing about a branch that says it must be "test code" or "pre-release" code, but your perspective is common: Everyone wants blue/green or to fully distinguish between "live code" and "test code" because they think the problem isn't theirs to solve: That their manager doesn't give them enough time, or their predecessor didn't like clean code like you do, or that's just what test databases are for. Infrastructure that really supports branching is uncommon because it's difficult and it requires very careful consideration with regards to the entire architecture. Some examples of systems that actually use branching correctly: * Implement random 0.5%, 1%, 5% etc traffic diverted to test branches * Front-end web service selects branch from URL or cookie * Backend service compares 5% live queries against test database and compares results If your system doesn't have something like this, you're really missing out: Really big applications (the kind that span multiple continents) don't have an "atomic operation" to their deploy, and you shouldn't try to pretend that they do. That's how we got IPv6.

onion2k 11y ago

You can never break any code. That's a ludicrous expectation will lead to developers being scared of merging changings, which will in turn lead to them hiding mistakes, refusing to talk through their code, and ultimately hacking things in to the codebase that "work" but are terrible solutions to problems. It's far better to have a safe environment where a dev can branch a new feature, break the whole codebase completely if necessary, and only merge things back in when they're confident that their solution is a good one (with a review of the pull request by a maintainer or two). The aim of writing software is to make a good product that solves a problem. It is not to 'never break the build' or 'merge as often as possible'.

lmm 11y ago
> That's a ludicrous expectation will lead to developers being scared of merging changings, which will in turn lead to them hiding mistakes, refusing to talk through their code, and ultimately hacking things in to the codebase that "work" but are terrible solutions to problems. Maybe, but it can just as easily lead to good practice. E.g. if you're scared to change a particular piece of code, that's a red flag that that particular piece of code is inadequately tested - and "am I scared?" is a much better metric than automated test coverage reports.

tajen 11y ago

Most CI build tools can test branches. They can even merge from upstream on a temporary branch, return the failing tests, tell you when they started failing or being flaky (was it on a commit introduced to master by a recent merge?), then you know for every commit whether it would be green when you merge to master.