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

1 Answer 1

1

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.

6
  • 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. May 4 at 12:09
  • @JamesGeddes Did you see what site the links point to? Yes, that's from the definition of trunk-based development. May 4 at 13:27
  • I did, however not committing to main is surely not pure trunk based dev youtu.be/ASOSEiJCyEM May 4 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. May 4 at 14:56
  • Ah with you. I thought Dave Farley is saying that all PRs are always evil. Automated testing ftw. May 4 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.