Trunk-based development is a workflow where developers work directly on a main branch called the "trunk". The trunk is always in a deployable state. Short lived branches are used for developing new features which are then merged into the trunk after passing tests. Releases are cut from the trunk periodically. This allows for continuous integration and deployment while maintaining a stable release.

1. 1
Trunk Based
Development for
Beginners
March 2019

2. 2
Agenda
● Branching strategies
● Git concepts
● Trunk-Based Development Workflow
● Benefits of Trunk-Based Development

3. 3
Software Development
What is your process?

4. 4
Develop
Test
Integrate
Version Control System

5. 5
Branching Strategy
● Strategy that helps developers collaborate and
develop new functionality while minimizing disruption
to the existing code base.
● What’s the most efficient, safe way we can develop
software.

6. 6
Git Concepts

7. 7
Git Concepts
commits
branches
tags

8. 8
Commits

9. 9
● “Snapshot” of our repository.
● Provide us with information about any new changes that were
made since the last commit.
commit 221de65cba907e322c456ye... (HEAD -> mr/issue-5, origin/mr/issue-5)
Author: Matthew Ramirez <matthewxprogramming@gmail.com>
Date: Fri Mar 6 11:33:46 2020 -0800
created VPC module, referenced in root module us-west-2

10. 10
Branches

11. 11
[master] mkgh278 Merge branch ‘branch-2’ into master - Mr. T
[branch 2] e99f104 Finish up my feature part 3 - Mr. T
[branch 2] e188fa9 Develop a feature part 2 - Mr. T
[branch 2] 3e893c8 Develop a feature part 1 - Mr.T
[master] mkgh278 Merge branch ‘branch-1’ into master - Betty
[branch-1] jkfl2113 Add a cool widget part 2 - Betty
[branch-1] adsf833 Add a cool widget part 1 - Betty
[master] 6c6faa4 Initialize repo with README.md - Bob
● Reference a specific git commit
● Allow for parallel iteration

12. 12
Tags

13. 13
● Another way to references a specific commit
● conventionally immutable
0.1.0

14. 14
Trunk Based Development

15. 15
● Developers iterate on a single branch. AKA “the trunk” or
master.
● Master is always in a deployable state.
● Releases are cut off from master (periodically or on an
add-need basis) and are used in production environments.
(Apps and infra!)
The “Trunk”

16. 16
Developing New Functionality
● Short-lived branches are created for feature development (couple of
days max).
● New branches are then merged back into master after a Pull Request
is opened and new functionality passes build automation/tests.

17. 17
● Continuous Code Review
○ Makes current work visible
○ Triggers CI build/verification of branch
Pull Requests (PR)
● A PR must be opened for all feature branches that will be integrated into
master.

18. 18
Master
branch-1
branch-2
The Development
Process
Open PR Update PR Update
PR
WIPWIP READY
Open PR Update PR
WIP READY
test

19. 19
Masterbranch-1
branch-2
Rebasing
branch-2
● Rebasing of master branch on our feature branch ensures that
we’re up-to-date
● Merge Conflicts

20. 20
● This assumes that you have access to master, the process when
iterating on a forked repo is a little different.
1. Rebase remote master on local master :
git checkout master && git pull --rebase origin master
2. Rebase local master on feature branch :
git checkout my-branch && git rebase master
Rebasing

21. 21
Releases and
Hotfixes

22. 22
● Give us a “stable” version of our codebase to reference
○ NO developers are commiting to the release branch
○ The only way a commit can get on the release branch is a
hotfix.
○ Great for staging
● Allow master to keep moving forward
○ Should be created periodically and on an as-needed basis
Release Candidate Branches

23. 23
● Release tags are cut from release candidate branches
● “Immutable”
○ Great for production
○ Give us a stable version of our codebase to reference
● Allow master to keep moving forward
○ Should be created periodically and on an as-needed basis
Release Tags

24. 24
master
b1
The Release Process
b2 b3
RC/ 0.1.0
release candidate branch = RC
b4 b5 b6
RC/ 0.2.0
tag 0.1.0 tag 0.2.0
sprint 1 sprint 2
b7
sprint 3
deploy
master
deploy
master

25. 25
master
b1
Hot Fixing a Release
b2 b3
RC/ 0.1.0
release candidate branch = RC
b4 b6
RC/ 0.2.0
tag 0.1.0 tag 0.2.0
sprint 1 sprint 2
b7
sprint 3
b5 (hot fix)
Cherry pick
merge of
commit(s)
tag 0.1.1
● Used to fix bugs in releases, and get needed functionality into release
ASAP

26. 26
The Benefits

27. 27
● Increased development frequency
● Increased deployment frequency
● Increased collaboration and transparency of work in progress
The Benefits

28. 28
Thank You!
https://www.nebulaworks.com/#subscribe
https://trunkbaseddevelopment.com