Are you sick of Merge Hell? Do your feature branches go rogue? Do you spend more time fiddling with your Version Control System than doing actual development work? Then Trunk Based Development might be for you. Facebook does it. Google does it. Instead of messing with multiple branches, just use your master branch. Always. In addition to giving you an overview about how Trunk Based Development works, where it shines and where the pitfalls are, this talk will also cover the necessary techniques to succeed with it, such as Branch By abstraction, Feature Toggles and backwards compatible Database Migrations.
9. AdvantagesAdvantages
●
Easy to understand when used properlyEasy to understand when used properly
●
Branches document Sprints/FeaturesBranches document Sprints/Features
●
Isolated development cannot break masterIsolated development cannot break master
branchbranch
10. ProblemsProblems
●
assumes Sprints end as plannedassumes Sprints end as planned
●
rogue branches might be impossible to mergerogue branches might be impossible to merge
●
requires more communication about what wasrequires more communication about what was
merged yetmerged yet
●
merge conflicts are postponedmerge conflicts are postponed
●
merge conflicts are more expensivemerge conflicts are more expensive
12. Trunk Based
Development
to the rescue
Image: https://commons.wikimedia.org/wiki/File:Placeholder_male_superhero_c.png (CC SA 3.0)
13. Trunk Based DevelopmentTrunk Based Development
●
everyone commits to master at least once per dayeveryone commits to master at least once per day
●
remote branches are only made for releasesremote branches are only made for releases
●
developers may use local branchesdevelopers may use local branches
●
hotfixes are also committed to masterhotfixes are also committed to master
●
hotfixes are cherry picked into supported releaseshotfixes are cherry picked into supported releases
●
only Release Managers may branch releaseonly Release Managers may branch release
branchesbranches
15. AdvantagesAdvantages
●
leanlean
●
can release at any timecan release at any time
●
merge problems surface earlymerge problems surface early
●
merge problems are smallermerge problems are smaller
●
release branches are cheaprelease branches are cheap
16. ProblemsProblems
●
Branches no longer document featuresBranches no longer document features
●
Needs a way to hide/disable unfinished workNeeds a way to hide/disable unfinished work
●
Requires additional care with db changesRequires additional care with db changes
●
Requires OOD knowledgeRequires OOD knowledge
17. Branch by AbstractionBranch by Abstraction
"Branch by Abstraction" is a technique for making a large-"Branch by Abstraction" is a technique for making a large-
scale change to a software system in gradual way thatscale change to a software system in gradual way that
allows you to release the system regularly while theallows you to release the system regularly while the
change is still in-progress.change is still in-progress.
- Martin Fowler- Martin Fowler
18. In a nutshellIn a nutshell
●
modularity through design not through VCSmodularity through design not through VCS
●
add an abstraction over any code you are going to change in aadd an abstraction over any code you are going to change in a
featurefeature
●
new features are added through Adapters and Interfacesnew features are added through Adapters and Interfaces
●
production code keeps old implementations while feature isproduction code keeps old implementations while feature is
incompleteincomplete
●
development code uses the new implementationsdevelopment code uses the new implementations
●
when the feature is ready, the new implementations arewhen the feature is ready, the new implementations are
rolled outrolled out
19. Feature TogglesFeature Toggles
●
features are hidden until readyfeatures are hidden until ready
●
hides features at the entry pointshides features at the entry points
●
easy to configure via config fileeasy to configure via config file
●
easy to implement with a small POPOeasy to implement with a small POPO
●
can be tailored to specific user groupscan be tailored to specific user groups
●
bonus:bonus: allows for easy A/B testingallows for easy A/B testing
21. Database ChangesDatabase Changes
●
all changes to the database need to beall changes to the database need to be
backwards compatiblebackwards compatible
●
one statement per migrationone statement per migration
●
migrations should be transactionalmigrations should be transactional
●
needs to be integrated into the build processneeds to be integrated into the build process
(DBDeploy, Liquibase, …)(DBDeploy, Liquibase, …)
23. Example 1 - Migrate CodeExample 1 - Migrate Code
Objective: replace a legacy component with aObjective: replace a legacy component with a
newer componentnewer component
25. Step One: Decouple theStep One: Decouple the
implementationimplementation
26. ProTipProTip
●
In PHPStorm you can right-click class code andIn PHPStorm you can right-click class code and
select Refactor Extract Interface→ →select Refactor Extract Interface→ →
●
If your IDE doesn't support Extract Interface,If your IDE doesn't support Extract Interface,
try https://github.com/gooh/InterfaceDistillertry https://github.com/gooh/InterfaceDistiller
27. Step Two: Change all consumersStep Two: Change all consumers
to use the Interfaceto use the Interface
29. Step Four: Add new componentStep Four: Add new component
30. Step Five: CleanupStep Five: Cleanup
●
remove the toggle from bootstrapremove the toggle from bootstrap
●
optional: remove the interface againoptional: remove the interface again
●
Done o/Done o/
31. Example 2: Change APIExample 2: Change API
Objective: adapt a new API graduallyObjective: adapt a new API gradually
35. Change API: cleanupChange API: cleanup
●
when ready, remove the old API codewhen ready, remove the old API code
●
run your tests to make sure it worksrun your tests to make sure it works
●
remove the Migration Adapter from bootstrapremove the Migration Adapter from bootstrap
●
inject the component with the new API onlyinject the component with the new API only
●
done o/done o/
36. Bonus: Using a VerifyBonus: Using a Verify
Objective: harden against failuresObjective: harden against failures
37. In a nutshellIn a nutshell
●
Verify adds additional safety to the migrationVerify adds additional safety to the migration
●
fail fast and tell you where at runtimefail fast and tell you where at runtime
●
is basically a Runtime Assertionis basically a Runtime Assertion
●
isis NOTNOT a replacement for your test QAa replacement for your test QA