1

Currently, we use a simple branching strategy, with a single main branch and one layer of feature branches; no branches on branches on branches. We also have many pipelines that run against each PR to check the code before it is merged to the main branch, including but not limited to,

  • code quality
  • linting
  • security assurance

In a trunk-based approach, how does one run these tests before code is merged, without a PR?

I have seen Trunk Based Development - release branch testing but it did not fully answer my question. Thanks in advance for your patience with a n00b question :D

James Geddes
  • 251
  • 2
  • 7

1 Answers1

2

You can still use pull requests with Trunk-Based Development. Especially with larger teams, using short-lived feature branches, you would open a pull request into the trunk, which would start the build process. Depending on your environment and desire to have rapid merges, you could merge the pull request automatically, perhaps based on things like no new style violations, sufficient code coverage, tests pass, and no new static analysis violations, and defer the human review for later.

Thomas Owens
  • 333
  • 1
  • 8
  • Is that still trunk based though? Your suggestion sounds like people should create feature branches rather than committing directly to main, which is our current situation. – James Geddes May 04 '22 at 12:09
  • @JamesGeddes Did you see what site the links point to? Yes, that's from the definition of trunk-based development. – Thomas Owens May 04 '22 at 13:27
  • I did, however not committing to main is surely not pure trunk based dev https://youtu.be/ASOSEiJCyEM – James Geddes May 04 '22 at 14:19
  • @JamesGeddes In that video, Dave Farley is talking about human-gated pull requests. I mentioned this in my answer - you can still use pull request tools (like GitHub, Bitbucket, and perhaps others) to perform automated checks and automatically merge, while deferring human reviews for later. However, there is no way to both commit to trunk and run your pipeline before a merge. You need to decide what is more important - waiting a short period of time (hopefully minutes) to get your automated results and merging or integrating faster and getting results later. – Thomas Owens May 04 '22 at 14:56
  • Ah with you. I thought Dave Farley is saying that all PRs are always evil. Automated testing ftw. – James Geddes May 04 '22 at 15:00
  • @JamesGeddes I'd have to rewatch that video to be 100%, but I watched it when it came out (his channel is great). I highly doubt he'd object to your pipeline blocking a merge, but I suspect he's say that you should be aiming to get your branch into main (meaning it passes the pipeline) within a day or two of opening it. That also has implications for how long your pipeline should take to execute - 10 or 15 minutes could be a very long pipeline. You can always defer more to post-merge - it's all about balancing ensuring quality, reducing risk, and letting people use your changes to buildon. – Thomas Owens May 04 '22 at 15:06
  • @JamesGeddes From a purely Git perspective, this debate is kind of funny. In Git, a branch is a pointer to a commit that has a name. If the "trunk" is called main on the remote, and you call your local branch main, then it's TBD. If you rename your local branch to my-branch then TBD magically changes into "Feature Branch Workflow", which is also known as GitHub Flow and many other popular CI workflows. PR's are fine, just temporarily rename (or copy) your local main to something else and push it out so you can use the PR tool functionality, if you want to. – TTT Sep 07 '22 at 20:11