4 ms·

TLDR Trunk-based development = putting unfinished work in the team's shared branch. Feature-branches = finishing your work first. Anyone who's ever completed

TLDR Trunk-based development = putting unfinished work in the team's shared branch. Feature-branches = finishing your work first. Anyone who's ever completed a complex PR knows how much plans change over the course of the work. Obviously those immature stages shouldn't be shared with the team, let alone be in main, whether behind feature flags or not.

hinkley 3y ago
The main observation of CI/CD is that problems don't get better by avoiding them. If something sucks, you either need to figure out how to stop doing it ever again, or grow callouses. The draw of feature branches is the same draw as quarterly or yearly releases: People don't know how to decompose problems into stand-alone subproblems that they can tick off one at a time. The solution is the same here. Don't avoid decomposing problems. Do it every week until you figure it out.
sebazzz 3y ago
Another practical issue with trunk-based development is that most code review tools only support reviewing complete branches and don't support reviewing a bunch of individual commits. Well, Jetbrains Upsource supports it, but unfortunately that has been canned by Jetbrains. However, trunk-based development allows high-paced development of applications, and testers can easily review the combined result on a test environment.
- gettodachoppa 3y ago
  Why would you want to review individual commits when the same lines can change from one commit to another? It seems like more work. Personally I want to see the final list of changes when I review, and not waste my time with intermediate stuff. I know some people are diligent about using rebase to present a clean commit history, but that's rare in practice in my experience. And it's incompatible with devs who aren't skilled at git.
  - sebazzz 3y ago
    That's why I said "a bunch of individual [related] commits"

hinkley 3y ago

The main observation of CI/CD is that problems don't get better by avoiding them. If something sucks, you either need to figure out how to stop doing it ever again, or grow callouses. The draw of feature branches is the same draw as quarterly or yearly releases: People don't know how to decompose problems into stand-alone subproblems that they can tick off one at a time. The solution is the same here. Don't avoid decomposing problems. Do it every week until you figure it out.

sebazzz 3y ago

Another practical issue with trunk-based development is that most code review tools only support reviewing complete branches and don't support reviewing a bunch of individual commits. Well, Jetbrains Upsource supports it, but unfortunately that has been canned by Jetbrains. However, trunk-based development allows high-paced development of applications, and testers can easily review the combined result on a test environment.

gettodachoppa 3y ago
Why would you want to review individual commits when the same lines can change from one commit to another? It seems like more work. Personally I want to see the final list of changes when I review, and not waste my time with intermediate stuff. I know some people are diligent about using rebase to present a clean commit history, but that's rare in practice in my experience. And it's incompatible with devs who aren't skilled at git.
- sebazzz 3y ago
  That's why I said "a bunch of individual [related] commits"