Trunk-based development blends well with task branches
This is the third installment in the series of blogposts telling how we develop Plastic SCM. In the first two posts, we covered what our new working cycle looks like once we moved to trunk based development and then we gave a brief overview of the meaning of release versus deploy.
In this third blog post, we will be looking back and filling in some gaps. What exactly is trunk-based development and how does it blend with task branches?
What is trunk-based development
It is a technique to ensure all changes reach trunk fast, and every change is correctly reviewed and tested. You can find out all about it in Hammant's super site here. Trunk is the main development line, "main" in Plastic jargon.
Trunk-based development is the foundation of "continuous delivery".
It requires continuous integration: changes get continuously merged into trunk as soon as they are known to be good (peer-reviewed and tested with an automated test suite).
Trunk-based development is not the same as mainline development. Remember the old days with everyone just doing checkin to the main branch? (SVN anyone?). No, it is not the same thing. Trunk is all about making sure the build is stable, ready to be deployed. Nothing to do with the old mess.
Task branches blend well with Trunk-based development
Before you cringe, trunk based development is compatible with short-lived task branches.
I wouldn't even call these branches "feature branches" at all because it might be misleading. A feature can take long to implement, so the branch grows too old.
I rather prefer "task branches", which sometimes is used interchangeably, although the meaning is quite different.
Tasks are short, or at least they should be. How short? 4h short, 8h short, ideally not longer than 16hours short.
Features are longer than that, so we just split them up. Task branches are great for that purpose and they blend nicely with trunk-based development.
Why I insist in using task branches instead of just doing checkin?
Well, suppose you are working distributed. You can checkin locally and then push, can't you? This ends up being a "local branch" after all, and you have a place to checkin as frequently as you need before hitting "main". You can do this with Plastic when you work distributed, of course.
Now, why should it be different if you are working centralized? You can create branches, checkin often, then set the branch as ready to be merged to main.
In both cases (distributed and centralized) short task branches bring lots of benefits:
- The task branch is the actual "change container". You are not tied to a "single checkin", you can checkin as often as you need. (I tell a story in my checkins, so reviewers can go changeset by changeset following my train of thought instead of hitting the full diff. It is great for big refactors).
- You can easily review the code before it gets merged. It is a branch after all. No need to create other artifacts (like temporary checkins, or send the diffs around to a code review system). Just review the branch.
- The branch can be merged in a single step. If something goes wrong (build, tests, whatever), the entire branch gets rejected.
0 comentarios: