Trunk-based development talk given at AgileDC 2014 in Washington, DC.

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. 47
big scary merge before a
big scary release

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:
new-file.jsp:
<%@include
file="hello.jspf"
%>
agivenbranch:
hello.jspf => hey.jspf
main.jsp:
<%@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. 67
big scary merge

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. Paul Hammant
iterative

89. Paul Hammant
big bang

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?