Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Trunk-based development blends well with task branches

Tuesday, April 18, 2017 Pablo Santos 0 Comments

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.
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

0 comentarios: