Trunk-based development

trunk-based-development.md

You don't simply do TBD

• embed it in a proper workflow
• implement fast and specific feedback loops on all stages
  • analysis
  • development
  • CI pipeline
  • shipping working software to PROD afap

Build review in

• lean manufacturing: reduce waste
  • changeover time is waste
  • reducing changeover time means reducing waste
  • pull-request based reviews involve 2 changeovers
    1. reviewer has to "stop" her work and switch context to reviewed code
    2. developer implementing the change has to come back to the code later, re-establish context in her brain...
• better: have review during coding
  • pair programming
  • proper rotation in team across stories and topics
• involve PO, BA, QA early and often

Hone your engineering skills by optimising for TBD

• think about a good migration path
• small changes less likely cause breaking change
• spend less time in code reviews and shift the time to improve your infrastructure / pipeline / test suite

Speed up the feedback loop

• commit early & often leads to integrate early and often
• the fresher the code is in your mind, the easier to fix it, hence the cheaper to fix it

Engineering practises that enable TBD

• feature toggles
• a good test suite
  • balanced test suite / testing pyramid
  • integration tests
  • PACT tests
• tech huddles, have everyone involved

"Issues" with feature branches

• delay integration == delay feedback
  • you only know whether changes are properly working once you integrate into master, which happens quite late
  • possibly many intermediate changes to master
• undermine the concept of continuous integration
• increases complexity of your CI process
  • exponential explosion of possible combinations to check every branch with every other branch