Source Branching
3 minute read
Trunk-based development, is a requirement for Continuous Integration.
Recommended Practices
- All changes begin with a branch from trunk and integrate back to the trunk.
- Branches should live no longer than 24 hours. The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change.
- Pull requests reviewed by a second party are a compliance requirement.
- Trunk can always be built and deployed without breaking production.
- When needed, use techniques like the Branch by Abstraction pattern or feature flags to ensure backwards compatibility.
- All changes to trunk include all appropriate automated tests.
- Branching vs. Forking: It is important that the right process be use for the right reason. Branches are the primary flow for CI
and are critical for allowing the team to have visibility to work in progress that the team is responsible for completing. Forks
are how proposed, unplanned changes are made from outside the team to ensure quality control and to reduce confusion from
unexpected branches.
- Forks should be used for:
- Contribution from a contributor outside the team to ensure proper quality controls are followed.
- Contribution that may be abandoned and that lost work will not impact team goals.
- Branches should be for:
- All planned work done inside the team to prevent lost work due to illness or emergency.
- Forks should be used for:
Tips
- Story Slicing helps break development work into more easily consumable, testable chunks.
- You don’t have to wait to be story/feature complete as long as you have tested and won’t break production.
- Pull requests should be small and should be prioritized over starting new development.
Common Issues
Trunk based continuous integration often takes workflow adjustments on the team. The main reasons teams struggle with CI are:
- Test architecture
- Work that is too big and / or lacks proper refinement
- Issues with source code ownership (one repo owned by more than one team)
- Workflow management within the team
References
Value
As a team, the use of trunk-based development enhances our ability to deliver small, value adding, functional enhancements to trunk while also decreasing the time it takes to get feedback on our changes.
Acceptance Criteria
- All Development begins with branching from trunk.
- The artifact resulting from changes to trunk is running in production.
- Branches live an average of less than 24 hours.
- Team members hold each other accountable to the size and frequency of integrations.
- Repositories only have short-lived branches and trunk.
FAQ
- Pre-requisites for TBD
- Benefits of using TBD
- Releasing From Trunk
- Handling Infrequent Releases
- Handling Bug Fixes
- Handling Incomplete Code/Features
- Validating Release Quality
- Transitioning to Trunk Based Development
- Trunk Based Development- You’re doing it wrong
Last modified October 13, 2022: Corrected broken links (#8) (d324154)