https://platformengineering.org logo
#general
Title
# general
n

Nick Perkins

12/22/2022, 6:00 AM
Anyone work in a team that uses trunk based development? Do you use short lived branches when working this way or always commit to main. I would like answers pertaining to how you work, not theoretical answers.
a

Asaf Erlich

12/22/2022, 6:49 AM
In the last 4 or so jobs I've worked, which all used git, this is how people developed. A single main/master/mainline branch and pushing to it triggers the start of a partially automatic (rarely fully automatic) pipeline. The end of the pipeline is a production deployment. Development is done on short lived branches which when ready you create a pull request or code review. Passing code review lets you merge to main or the trunk. This is sometimes enforced but if not it's expected. I will admit there are rare exceptions with a few services or clients when branches exist for different environments / stages like beta or stage or production. Those are part of the pipeline roll out or deployment up to production. I and most developers I've worked with really don't like this non trunk based development approach but often the choice was made before any current developers were here and change is very hard.
a

andrzej3393

12/22/2022, 8:05 AM
Only long lived branch is main/master/name-it-like-you-want. Development in 99% of cases is done on short lived feature branches. Very rarely (remaining 1%) we have medium lived (integration) branches for bigger features where several people work in parallel on different parts of feature. In that case devs work on their branches and then opens PRs to merge their work to integration branch and at the very end there's one big PR to merge integration branch into main.
n

Neil Millard

12/22/2022, 8:31 AM
We have a project (API with pipeline tests and deployment), where we work in pairs and commit directly to
main
. The majority of the github repos have branch protection with short lived branches and PRs.
d

Daniel Förberg

12/22/2022, 8:34 AM
Feature branches for all PRs and merge to main
g

George Aristy

12/22/2022, 2:20 PM
I've worked on teams with trunk-based development over the past several years. Devs would create short-lived feature/fix branches and post PRs/MRs for review + CI. If CI passed and PR got approval then it was merged to trunk where a CD pipeline would deliver it to either prod or staging. Committing directly to the trunk in a team bigger than some really low number (2?) sounds scary to me, especially if it's a high velocity team.
It's also important to set up some sort of merge queue to the trunk. I've used several tools for this in the past, the latest has been GitHub's (in beta).
You will most likely want CI in that merge queue, and optionally on each push to the feature/fix branch.
a

Asaf Erlich

12/22/2022, 3:19 PM
Can you define what a "merge queue" means?
g

George Aristy

12/22/2022, 3:22 PM
A queue where the PRs are placed in and then, one by one, integrated with the trunk on a "staging" area. You can configure your tests to run after this integration as well, and right before merging to trunk.
Examples: bors, github
a

Asaf Erlich

12/22/2022, 3:25 PM
Oh, interesting
I would say it's a tradeoff, I could see it being better for large monorepos where everyone is forced to hit update pull request and wait for CI what feels like a 100 times on any PR since so many prs get merged so frequently.
TIL
g

George Aristy

12/22/2022, 3:29 PM
Yep - I've been there (being forced to update my branch many times). It's painful and inefficient IMO.
a

Asaf Erlich

12/22/2022, 3:32 PM
It could introduce risk though. For example, I'm right now thinking about some of our very large terraform repos. We've already had incidents where people use CI to trigger terraform apply and didn't carefully look at changes they didn't intend to make, that caused an outage. Something their code changes didn't show.
Like with other automation you need the CI validations in place to rely on it
but maybe that's a good forcing function...
g

George Aristy

12/22/2022, 3:34 PM
Hmm, true. In that case, I would recommend CI on the PR itself. Have the CI pipeline post a comment with the TF's plan, and someone review that.
a

Asaf Erlich

12/22/2022, 3:34 PM
That already is done ^^
26 Views