Download as PDF, PPTX
More Related Content
Similar to Trunk based development
![[Mas 500] Software Development Strategies](https://cdn.slidesharecdn.com/ss_thumbnails/mas-500-2-software-stategies-131113120840-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Trunk based development
- 1. Trunk Based DevelopmentTrunkBased Development Dutch PHP ConferenceDutch PHP Conference 2014-06-282014-06-28
- 2. Gordon OheimGordon Oheim SeniorCraftsman, PHP Documentor,Senior Craftsman, PHP Documentor, Stack Overflow Contributor & Moderator,Stack Overflow Contributor & Moderator, AgilistAgilist →→ http://twitter.com/go_ohhttp://twitter.com/go_oh →→ http://about.me/goohhttp://about.me/gooh →→ gooh@php.netgooh@php.net
- 6. Before we start…Before we start …
- 7.
- 8. Six months ago…Six months ago …
- 9. AdvantagesAdvantages ● Easy to understandwhen 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 endas 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
- 11. Welcome to MergeHellWelcome to Merge Hell
- 12. Trunk Based Development to therescue Image: https://commons.wikimedia.org/wiki/File:Placeholder_male_superhero_c.png (CC SA 3.0)
- 13. Trunk Based DevelopmentTrunkBased 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
- 14.
- 15. AdvantagesAdvantages ● leanlean ● can release atany 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 longerdocument 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 AbstractionBranchby 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 nutshellIna 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 ● featuresare 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
- 20. Feature Toggles atMVSFeature Toggles at MVS
- 21. Database ChangesDatabase Changes ● allchanges 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, …)
- 22. Any Questions sofar?Any Questions so far?
- 23. Example 1 -Migrate CodeExample 1 - Migrate Code Objective: replace a legacy component with aObjective: replace a legacy component with a newer componentnewer component
- 24.
- 25. Step One: DecoupletheStep One: Decouple the implementationimplementation
- 26. ProTipProTip ● In PHPStorm youcan 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: Changeall consumersStep Two: Change all consumers to use the Interfaceto use the Interface
- 28. Step Three: Addfeature toggleStep Three: Add feature toggle
- 29. Step Four: Addnew componentStep Four: Add new component
- 30. Step Five: CleanupStepFive: 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: ChangeAPIExample 2: Change API Objective: adapt a new API graduallyObjective: adapt a new API gradually
- 32. Change API -SetupChange API - Setup
- 33. Change API: isolatethe old APIChange API: isolate the old API
- 34. Change API: fadingoutChange API: fading out
- 35. Change API: cleanupChangeAPI: 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 aVerifyBonus: Using a Verify Objective: harden against failuresObjective: harden against failures
- 37. In a nutshellIna 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
- 38.
- 39.
- 40.
- 41.