5 ms·

The biggest advantage I see of branch based development is that you land a single fix/feature with one merge commit. This makes it relatively easy to revert a c

by Aaargh20318 3y ago

The biggest advantage I see of branch based development is that you land a single fix/feature with one merge commit. This makes it relatively easy to revert a change if necessary as it's more or less an atomic change.

barrkel 3y ago
That's actually an advantage of trunk-based development. Instead of needing to roll back a whole feature, you just roll back the commit which broke stuff. This derisks big feature branches. It also forces the use or development of more incremental approaches to schema migration, feature flags and so on, which also reduce risk, and enable things like canary releases, A/B testing and so on.
- tremon 3y ago
  you just roll back the commit which broke stuff You are conflating branch-based development with commit squashing. It is perfectly possible to revert a single commit even if it was developed on a separate branch and then merged.
- Aaargh20318 3y ago
  > . Instead of needing to roll back a whole feature, you just roll back the commit which broke stuff. What if it's the whole feature that broke stuff? What if we decide just before release that based on our release tests this particular feature isn't ready for production yet? Do you expect me to hunt through the entire commit log and identify and revert every single commit related to the feature?
  - barrkel 3y ago
    No, flip the feature flag. You have a feature flag because there's multiple commits for the feature and it can't be enabled until it's complete. And since you're continuously deploying, even if you did have to look for a commit, it wouldn't be more than a day or two old. Of course you wouldn't enable the feature all at once if at all possible. You'd do a canary first, sending a proportion of traffic. And your production system alerting would notice an elevated error rate on the canary and drain traffic to it, so you're not up in the middle of the night searching for a flag to flip or commit to roll back, at least not very often.

barrkel 3y ago

That's actually an advantage of trunk-based development. Instead of needing to roll back a whole feature, you just roll back the commit which broke stuff. This derisks big feature branches. It also forces the use or development of more incremental approaches to schema migration, feature flags and so on, which also reduce risk, and enable things like canary releases, A/B testing and so on.

tremon 3y ago
you just roll back the commit which broke stuff You are conflating branch-based development with commit squashing. It is perfectly possible to revert a single commit even if it was developed on a separate branch and then merged.
Aaargh20318 3y ago
> . Instead of needing to roll back a whole feature, you just roll back the commit which broke stuff. What if it's the whole feature that broke stuff? What if we decide just before release that based on our release tests this particular feature isn't ready for production yet? Do you expect me to hunt through the entire commit log and identify and revert every single commit related to the feature?
- barrkel 3y ago
  No, flip the feature flag. You have a feature flag because there's multiple commits for the feature and it can't be enabled until it's complete. And since you're continuously deploying, even if you did have to look for a commit, it wouldn't be more than a day or two old. Of course you wouldn't enable the feature all at once if at all possible. You'd do a canary first, sending a proportion of traffic. And your production system alerting would notice an elevated error rate on the canary and drain traffic to it, so you're not up in the middle of the night searching for a flag to flip or commit to roll back, at least not very often.