The document discusses the importance of continuous delivery through early and frequent deployment of software. It emphasizes that the goal should be to define "done" as deployed in production and provide repeatable feedback through automated deployment pipelines that build, test and deploy code changes continuously to reduce risk and get early user feedback. It highlights issues that can arise from manual, late or infrequent deployments and provides examples of how some companies implement continuous delivery.

1. Andrzej Grzesik

2. CONTINOUS DELIVERY
Andrzej Grzesik

3. @ags313
andrzej@grzesik.it
andrzejgrzesik.info

4. ABOUT:ME
Present
Past

5. GEECON 2013
I HATE COMPUTERS
disclaimer
17th-19th May, Krakow, Poland

6. I HATE COMPUTERS
disclaimer

7. QUESTIONS?
ask them right away!

8. GREAT BOOKS!

9. FACTS FIRST

10. is more fun than

11. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.

12. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.

13. DELIVERY

14. DELIVERED
when?

15. DEPENDS…
(ultimate answer in computers)

16. #DEFINE DONE

17. WHAT IS DONE?

18. WHAT IS DONE?

19. WHAT IS DONE?
Coded

20. WHAT IS DONE?
Coded Reviewed

21. WHAT IS DONE?
Coded Reviewed Checked-in

22. WHAT IS DONE?
Coded Reviewed Checked-in Built

23. WHAT IS DONE?
Coded Reviewed Checked-in Built Tested

24. WHAT IS DONE?
Coded Reviewed Checked-in Built Tested Demoed

25. NOT REALLY :-)

26. #REDEFINE DONE

27. NOT READY
TILL DEPLOYED

28. DONE === RELEASED

29. ERIC RIES, THE LEAN STARTUP
build&
ideas& deploy&
learn& measure&
data&

30. If we can
reduce the time between major iterations
we can increase our odds of success
Eric Ries, Lean Startup

31. RELEASES
give us

32. FEEDBACK!

33. How long would it take your organization to deploy a
change that involved just one single line of code?
Do you do this on a repeatable, reliable basis?
Mary and Tom Poppendieck,
Implementing Lean Software Development

34. RELEASE == FEEDBACK

35. REPEATABLE FEEDBACK

36. HOW?!

37. entreth:
THE DEPLOYMENT PIPELINE

38. THE DEPLOYMENT PIPELINE

39. THE DEPLOYMENT PIPELINE
compile

40. THE DEPLOYMENT PIPELINE
compile
unit test

41. THE DEPLOYMENT PIPELINE
compile
unit test
package

42. THE DEPLOYMENT PIPELINE
compile
unit test
package
artifact repository

43. THE DEPLOYMENT PIPELINE
compile
Acceptance
unit test
testing
package
artifact repository

44. THE DEPLOYMENT PIPELINE
compile
Acceptance Capacity
unit test
testing testing
package
artifact repository

45. THE DEPLOYMENT PIPELINE
compile
Acceptance Capacity Manual
unit test
testing testing testing
package
artifact repository

46. THE DEPLOYMENT PIPELINE
compile
Acceptance Capacity Manual
unit test Release
testing testing testing
package
artifact repository

47. BUILD ONLY ONCE!

48. THE DEPLOYMENT PIPELINE

49. THE DEPLOYMENT PIPELINE
compile
Acceptance Capacity
unit test
testing testing
package
artifact repository

50. THE DEPLOYMENT PIPELINE
compile
Acceptance Capacity Manual
unit test
testing testing testing
package
artifact repository

51. THE DEPLOYMENT PIPELINE
compile
Acceptance Capacity Manual
unit test Release
testing testing testing
package
artifact repository

52. THE DEPLOYMENT PIPELINE

53. THE DEPLOYMENT PIPELINE
Acceptance Capacity
testing testing

54. THE DEPLOYMENT PIPELINE
Acceptance Capacity Manual
testing testing testing

55. THE DEPLOYMENT PIPELINE
Acceptance Capacity Manual
Release
testing testing testing

56. THE DEPLOYMENT PIPELINE
fear!
compile
Acceptance Capacity Manual
unit test Release
testing testing testing
package
artifact repository

57. AUTOMATE EVERYTHING!
(almost)

58. AUTOMATE EVERYTHING!

59. AND?

60. WELL, IT’S BIG

61. ALL CODE
IS PRODUCTION READY

62. EVERY VERSION IS
A RELEASE CANDIDATE

63. QUALITY GOES UP
people care

64. idea from: paulklipp.com/blog

65. PRO TIP: --VERSION

66. WHY VERSIONS?

67. 185.0.1
is more friendly than
0cdfc45df874354265b3be910b52c41398de79ca

68. ANTIPATTERNS

69. DEPLOYING RARELY/LATE
symptomps: “alpha”, “beta”, “gold”

71. LATE FIRST CONTACT WITH
REALITY

72. UNREALISTIC ASSUMPTIONS

73. WELL TESTED IN.. DEV

74. DEPLOYING MANUALLY
is evil!

75. ERROR-PRONE
http://www.flickr.com/photos/aaronjacobs/64368770/

76. ALWAYS DIFFERENT
repeatable

77. IMPOSSIBLE TO TEST

78. VOODOO
http://flickr.com/photos/35541100@N00/2486381001/

79. 2 AM DEPLOYS
http://www.flickr.com/photos/dhdesign/1096464615/sizes/z/in/photostream/

80. THE “DEPLOY” TEAM

81. DO YOU AVOID DEPLOYS?

82. HOW OFTEN DO YOU
DEPLOY?

83. IF IT HURTS
DO IT MORE OFTEN!
practice, practice, practice

84. INCREMENTAL, FREQUENT
RELEASES REDUCE RISK

85. PROVIDE DATA

86. GIVE ROLLBACK POINTS

87. SOME STATS
Facebook - every 10 minutes
Etsy - 50-60 deploys/day
GitHub - >50 deploys/day
project X - 1374 commits, 1057 deployments, <8 months

88. ENVIRONMENTS

89. IF I ERASED ALL YOUR PRODUCTION
MACHINES, HOW LONG WOULD YOU NEED
TO BE BACK UP?

90. WELL, CODE IS IN GIT
mercurial, subversion, ClearCase, whathaveyou

91. IMAGINE:
http://www.flickr.com/photos/roadhunter/68017745/

92. INFRASTRUCTURE AND CONFIGURATION
IS JUST AS IMPORTANT

93. VERSION IT!
(puppet, chef, etc)

94. BEFRIEND SOME ADMINS :-)

95. AND VERSION EVERYTHING

96. MANUAL CONFIGURATION
OF ENVIRONMENTS

97. PRIVILEGED DEPLOY TEAM

98. NOT REPEATABLE

99. SLIGHT DIFFRENENCES

100. DOESN’T SCALE

101. HARD TO TRACK

102. ROLLBACK, ANYONE?

103. TRUCKS

105. MEANWHILE,
IN THE REAL WORLD

106. MY SYSTEM IS ***

107. WHERE TO START?

108. WITH PRODUCTION
and fix things backwards

109. AUTOMATE DEVELOPMENT
and bring automation forward

110. DEPLOYS
how do I?

111. DEPLOYS
• blue-green
• canary
• emergency fixes

112. BLUEGREEN
tr affic

113. FULL BLUEGREEN IS COSTLY
but great for availability

114. CANARY
old old old new
old old old new

115. EMERGENCY FIXES

116. EMERGENCY FIXES
go the same way

117. DON’T BREAK RULES

119. CAVEATS!

120. STATE

121. LONG RUNNING *

122. SAGAS?
http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

123. DATASTORES
EACH APP HAS IT’S OWN
ideally

124. DATASTORES
SCRIPTED
must

125. DATASTORES
MIGRATIONS
nice

126. DATASTORES
TEST
all of them

127. MAYBE EVENT SOURCING?

128. VERSION YOUR ENTITIES
and code accordingly

129. BRANCHING

131. FEATURE SWITCHES
instead

132. if your system
looks like that

133. CUT!

135. • have integration tests
• have a “test” system

136. DESKTOPS
• LOVE your autoupdate
• build-in version checking and inform user

137. DESKTOPS
Do or

138. LOVE YOUR AUTOUPDATE

139. PUSH USER UP

140. IN PRACTICE

141. MODULES^N

142. PRE-TESTED COMMITS
rock, a bit

143. DVCS
rock, a lot!

144. VMS
rock a lot!

145. THERE ARE TOOLS

146. IS AWESOME
but

148. +

149. GLU
http://linkedin.github.com/glu

151. GO ($$$)

152. PALDIES!
kthxbye!

153. @ags313
andrzej@grzesik.it
andrzejgrzesik.info
tweet please!

154. RESOURCES
• http://continuousdelivery.com
• http://lmgtfy.com/?q=continuous+delivery