Wow, I'm surprised by the negativity to this post from the majority of the developers here. The idea is spot on, but the article title and tone could be better - as in all things there is rarely a right or wrong answer to a problem.
I'm gonna argue the case for using one one branch - trunk/master. It may not work for your organisation, but for my organisation it's an essential way of shipping features to customers quickly.
We have 40+ engineers and we all commit directly to trunk - no branches, no pull requests, no QA department. Every push to git is deployed to production, provided that the push passes the pre-push test and quality checks, CI automated tests, etc. We pair-program on pretty much everything, the extra set of eyes is the equivalent of a pull request for us.
When bugs are introduced, it's trivial to rollback production to an earlier version and identify the commits that have likely introduced the problem. It's much harder to identify where a bug was introduced when you have multiple changes from multiple feature branches. Adrian is right failing fast is good! Quick feedback loop is incredibly useful. (That's why we all practise TDD, yeah?) When a problem does happen, engineers quickly pick up on the issue. ("Oh yeah, that was my recent commit on XYZ, I'll rollback production now and then revert those changes"). They are in the zone at that point. Compare that with a release that introduces a bug and engineers are already on a different task or feature. They have to context switch back to the earlier work, which makes problem identification harder. All engineers using the same code base and pushing to production daily helps with this rapid feedback loop.
Feature flags are not used simply as an on/off state to control "half-baked features" not being released. If you want to perform experimentation on your features or canary release features then feature flags are a must. Services like LaunchDarkly or SplitIO can provide matching rules for feature flags that allow you to target cohorts of users and give those users a different UI experience or feature. For example, we can easily create a new sign-in page and target 10% of all users to use that sign-in page while the other 90% get the existing sign-in. If all goes well and we don't get any major problems we can continue to rollout that new page to more users. Increasing or decreasing the percentage rollout is a configuration change and is instantly reflected on production. Experiments are also easy to implement with these feature flags. (For example, what's the affect on user registrations if we change the text? Make the register button bigger? Add a coloured background to the register button?). The results of these experiments allow us to continually improve the customer experience. Experiments and canary releases can also be turned off instantly (no deployment needed!).
If you don't want/need to deploy to production daily, then feature branches will work just fine. But, if you want to move towards continuous deployment, rapid feedback on experiments, canary releases then trunk based development and feature flags is a good approach. It's scary at first, but it's worth it. Not one of our engineers will go back to the bad old days of feature branches and merge conflict hell.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow, I'm surprised by the negativity to this post from the majority of the developers here. The idea is spot on, but the article title and tone could be better - as in all things there is rarely a right or wrong answer to a problem.
I'm gonna argue the case for using one one branch - trunk/master. It may not work for your organisation, but for my organisation it's an essential way of shipping features to customers quickly.
We have 40+ engineers and we all commit directly to trunk - no branches, no pull requests, no QA department. Every push to git is deployed to production, provided that the push passes the pre-push test and quality checks, CI automated tests, etc. We pair-program on pretty much everything, the extra set of eyes is the equivalent of a pull request for us.
When bugs are introduced, it's trivial to rollback production to an earlier version and identify the commits that have likely introduced the problem. It's much harder to identify where a bug was introduced when you have multiple changes from multiple feature branches. Adrian is right failing fast is good! Quick feedback loop is incredibly useful. (That's why we all practise TDD, yeah?) When a problem does happen, engineers quickly pick up on the issue. ("Oh yeah, that was my recent commit on XYZ, I'll rollback production now and then revert those changes"). They are in the zone at that point. Compare that with a release that introduces a bug and engineers are already on a different task or feature. They have to context switch back to the earlier work, which makes problem identification harder. All engineers using the same code base and pushing to production daily helps with this rapid feedback loop.
Feature flags are not used simply as an on/off state to control "half-baked features" not being released. If you want to perform experimentation on your features or canary release features then feature flags are a must. Services like LaunchDarkly or SplitIO can provide matching rules for feature flags that allow you to target cohorts of users and give those users a different UI experience or feature. For example, we can easily create a new sign-in page and target 10% of all users to use that sign-in page while the other 90% get the existing sign-in. If all goes well and we don't get any major problems we can continue to rollout that new page to more users. Increasing or decreasing the percentage rollout is a configuration change and is instantly reflected on production. Experiments are also easy to implement with these feature flags. (For example, what's the affect on user registrations if we change the text? Make the register button bigger? Add a coloured background to the register button?). The results of these experiments allow us to continually improve the customer experience. Experiments and canary releases can also be turned off instantly (no deployment needed!).
If you don't want/need to deploy to production daily, then feature branches will work just fine. But, if you want to move towards continuous deployment, rapid feedback on experiments, canary releases then trunk based development and feature flags is a good approach. It's scary at first, but it's worth it. Not one of our engineers will go back to the bad old days of feature branches and merge conflict hell.