Tbd demystified agiles2011

554 views
511 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
554
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Tbd demystified agiles2011

  1. 1. Trunk Based Development Demystified Carlos Lopes Guilherme Lacerda ThoughtWorks FACENSA/UniRitter TargetTrust/Surya Software Innovation
  2. 2. agendathe problemimpactssolutions!when to branch?
  3. 3. the problem
  4. 4. different streams, same codebase
  5. 5. branches!
  6. 6. Ronald Widha
  7. 7. merge hell
  8. 8. syntactic conflictclass BlaBlaBla {<<<<<<< HEAD public void bla(Bla oldBla, New newBla) { oldBla.bla(); newBla.newBla();======= public void bla(Bla oldBla, Other otherBla) { oldBla.bla(); otherBla.otherBla();>>>>>>> other commit }}
  9. 9. semantic conflictclass BlaBlaBla { public void something(Bla bla) {<<<<<<< HEAD bla = bla.plus(14);======= bla = bla.minus(7);>>>>>>> change //other stuff }}
  10. 10. integration conflicts main.jsp: <%@include file="bla.jspf" %>master: agivenbranch:new-file.jsp: bla.jspf -> ble.jspf<%@includefile="bla.jspf" %> main.jsp: <%@include file="ble.jspf" %>
  11. 11. the merge man/monkey
  12. 12. promiscuous integration Martin Fowler
  13. 13. $$$$
  14. 14. Jon Wolter
  15. 15. regressions
  16. 16. Jon Wolter
  17. 17. Jon Wolter
  18. 18. “the bigger the apparentreason to branch, the more you shouldn’t branch.” Jez Humble / David Farley
  19. 19. “dont separate differingconcerns by using a VCS, use an abstraction instead.” Stacy Curl
  20. 20. “feature branching is a poor mans modular architecture, instead of building systems with the ability to easy swap in and outfeatures at runtime/deploytime they couple themselves to the source control providing this mechanism through manual merging” Dan Bodart
  21. 21. all right, but how to solve this?
  22. 22. branch bysource control?
  23. 23. there’s hope!
  24. 24. approaches
  25. 25. hide new functionality
  26. 26. abstraction
  27. 27. big bang Paul Hammant
  28. 28. iterative Paul Hammant
  29. 29. small releasable changes
  30. 30. componentization
  31. 31. enable flowacross teams
  32. 32. KEEP IT ALWAYS RELEASABLE
  33. 33. KEEP IT ALWAYS RELEASABLE
  34. 34. CONTINUOUS INTEGRATION
  35. 35. CONTINUOUS INTEGRATION
  36. 36. program level product owner/championknows each project champion and how to reach people
  37. 37. Uncle Bob
  38. 38. but when to branch?
  39. 39. large change - headaches!spikes- if you throw them awaynew release- hmm
  40. 40. Paul Hammant
  41. 41. branching vs. freezing
  42. 42. more infowww.codingbyexample.org
  43. 43. thanks!

×