Diego Pacheco reflects on source control management (SCM), discussing the implications of using branches in CI/CD, their impact on refactoring, and how they can create bottlenecks. He advocates for trunk-based development over traditional branching methods like Gitflow, emphasizing the importance of reducing feedback cycles and increasing deployment frequency. Pacheco suggests that effective architecture should minimize the need for branches to enhance collaboration and streamline code integration.

1. Reflections on SCM
Diego Pacheco

2. @diego_pacheco
❏ Cat's Father
❏ Head of Software Architecture
❏ Agile Coach
❏ SOA/Microservices Expert
❏ DevOps Practitioner
❏ Speaker
❏ Author
diegopacheco
http://diego-pacheco.blogspot.com.br/
About me...
https://diegopacheco.github.io/

3. Every company works with Branches

4. Git Made branches much less painful...

5. But do we think about the implications?
❏ How much they affect CI/CD ?
❏ How much they affect Refactoring?
❏ How much they create bottlenecks?
❏ How much they hide architectural complexity?
❏ They optimized for Local, remote, colarotation or what?

6. Back do Lean/Agile/DevOps Principles
❏ Increase Feedback into the system
❏ Reduce Feedback cycles
❏ Reduce Batch size (lower delta, lower risk)
❏ Increase deployment frequence
❏ Experiment often
… it’s branches aligned with that?

7. Branch by Abstraction
❏ Long lived Branches
❏ Easily can live for 2 weeks (1 Sprint) or even much longer
❏ Benefits: Easily to Pause or Cancel
❏ How to:
❏ Introduce Abstraction, Wrote a second implementation
❏ Enable to all, remove old, on/off switch

8. Branch per Release
❏ Team pushes to prod or regular schedule (Sprint, Monthly)
❏ Also will need to push bug-fix releases in between.
❏ Stable place since devs are still committing on Trunk
❏ CI/CD Teams don't use this technique.

9. Release form Trunk
❏ Teams with high release cadence release from Trunk.
❏ No Slow down in releases
❏ Branches can be created retroactively

10. CI/CD
❏ XP technique
❏ CI by definition is single integration Source.

11. Trunk Based Development
❏ How CI/CD High Performance DevOps teams Work!
❏ Incompatible with GitFlow
❏ Works best for fast interactions/releases and SR engineers.

12. GitFlow

13. GitFlow: Commit Races
❏ Lots of changes
❏ First to Commit win
❏ Also known as PR Races
❏ It happens !!!

14. Issues with Branches
❏ Don’ t encourage Refactoring (Harder Merges)
❏ Shallow Review: Fast LGTM
❏ Batch size Problem (Anti-Lean)
❏ No Real CI happening
❏ Core Team Vs External Contributors

15. Other alternatives to branches...

16. The Issue with Release Trains / Calendars

17. Github Flow

18. Git OPS

19. PRs, PP/Mob and Code Review
❏ PR can create “interruptions”.
❏ Branches are good for individuals and bad for teams.
❏ Pair Programing is Code Review (no need to submit a PR)
❏ PP/Mob help to share knowledge
❏ PP/Mob is much faster Feedback

20. Branches and Architecture
❏ Good Modular Architecture
dont require branches.
❏ Mobile Might require
branches by nature.
❏ Isolation is the ultimate
branch blast radius
reducer.
❏ Code is Dynamic, Branches
are static.

21. Wrapping Thoughts
❏ Branches and PRs are cheap and the norm today.
❏ Most of companies see CI/CD as tools and not as principles.
❏ It's common to see people that don't want increase deployment frequency.
❏ Good Architecture require less or no branching.
❏ High Frequency releases and gitflow don't match.
❏ Lower Delta, Lower Risk, Release Often, Get more feedback.

22. Reflections on SCM
Diego Pacheco