Trunk-based development talk given at Agile India 2014 in Bangalore.

1. Multiple projects, different
goals, one thing in
common: the codebase!
Carlos Lopes
@carlosaml

2. why?

3. blog.crisp.se

6. Jon Wolter

7. ok

8. a little story

9. an online store
(of whatever)

10. 10

11. 11

12. 12

13. 13

14. 14

15. 15

16. 16

17. 17

18. 18

19. 19

21. 21

22. 22

23. 23

24. 24

25. what’s next?

26. 26

27. 27

28. 28

29. 29

30. 30

31. now what?

32. 32

34. 34

36. HOWEVER

38. 38

43. 43

44. merge hell

45. a LOT going on for
at least months...
45

46. 46

47. big scary merge
before a big scary
release
47

48. syntactic conflict
class 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
! }
}

49. semantic conflict
class BlaBlaBla {
! public void something(Bla bla) {
<<<<<<< HEAD
! ! bla = bla.plus(14);
=======
! ! bla = bla.minus(7);
>>>>>>> change
! ! //other stuff
! }
}

50. integration conflicts
main.jsp: <%@include
file="hello.jspf" %>
trunk:
agivenbranch:
new-file.jsp:
hello.jspf => hey.jspf
<%@include
main.jsp:
file="hello.jspf"
%>
<%@include
file="hey.jspf" %>

51. and so forth

52. regressions

53. however...

54. the loyalty program
team learnt
something...

57. merge monkey

59. 59

60. 60

61. continuous
integration?

62. 62

63. how many
pipelines for this?
63

64. and how effective
would they even be?

65. 65

66. still need to “integrate”
66

67. big scary merge
67

68. promiscuous integration
martinfowler.com/bliki/FeatureBranch.html

69. 69

70. how about
refactoring?

71. undeployable code

72. only trunk was releasable
at any given time
72

73. $$$$$

74. ok, so what do
we do?

75. “Feature branching is a poor man's
modular architecture, instead of
building systems with the ability to easy
swap in and out features at runtime/
deploytime they couple themselves to
the source control providing this
mechanism through manual merging.”
Dan Bodart

77. “The bigger the apparent
reason to branch, the more you
shouldn’t branch.”
Jez Humble / David Farley

78. “Don't separate differing
concerns by using a VCS, use an
abstraction instead.”
Stacy Curl

79. solutions?

80. branch by
source control
abstraction
paulhammant.com/blog/branch_by_abstraction.html

82. trunk-based
development

83. trunk-based
development
shopping cart?

84. trunk-based
development
shopping cart?
loyalty program?

85. if (myFeatureIsOn) {
doSomething();
}
martinfowler.com/bliki/FeatureToggle.html

86. feature
toggles/flags/bits

87. martinfowler.com/bliki/BranchByAbstraction.html

88. iterative
Paul Hammant

89. big bang
Paul Hammant

90. enables refactoring
gowebbaby.com/magento-responsive-design/

91. 91

93. 93

94. always releasable

95. 95

96. test
coverage

97. branching patterns

98. 98

99. 99

100. 100

101. 101

102. 102

103. paulhammant.com/2013/03/13/facebook-tbd-take-2/

104. “Feature branching is a poor man's
modular architecture, instead of
building systems with the ability to easy
swap in and out features at runtime/
deploytime they couple themselves to
the source control providing this
mechanism through manual merging.”
Dan Bodart

106. questions?