When you do Continuous Deployment you can deploy whenever you want: you made it as easy as possible and you have become very good at it. Every engineer knows how to deploy the application to any environment. The Product Department can always see the latest bells and whistles as they are built because you have Stable servers running the latest versions of the application. You implement big changes gradually and show them to Product while keeping the customer's experience stable. When you decide to release, you have made sure all things will work and you know how to react if nevertheless they break, without fires or panic. Continuous Deployment also forces you to do many right things: repeatable builds; the exact same deployment process in all environments, including the developer's machines and a development environment that is as close to Live as possible; backwards-compatible database changes; easy rollbacks; code that is split into components; good tests... In this talk I give an introduction to Continuous Deployment: why you should care, what it means and I propose a few first steps towards introducing this methodology. I presented this talk at DjangoCon EU 2013.

1. Continuous
Deployment
Òscar Vilaplana
@grimborg
dev@oscarvilaplana.cat DjangoCon EU 2013

2. """We're hiring!"""
from paylogic import (code, highavailability,
challenge)
from netherlands import (fun, nature, bikes,
beer)
def hire(you):
email('oscar.vilaplana@paylogic.eu', you.cv)
return challenge.accept()

5. """We're hiring!"""
from paylogic import (code, highavailability,
challenge)
from netherlands import (fun, nature, bikes,
beer)
def hire(you):
email('oscar.vilaplana@paylogic.eu', you.cv)
return challenge.accept()

6. intro

7. deploy

8. easy

9. good at it

10. everyone

11. Product Owner

12. Stable

13. latest versions

14. big changes

15. gradually

16. acceptance

17. stable

18. works

19. Done

20. breaks

21. don't panic

22. forces

23. Right Things

24. repeatable

25. identical

26. deployment

27. environments

28. backwards
compatible

29. rollback

30. components

31. tests

32. yes it does!

33. start working

34. energy

35. download

36. setup.py

37. broken

38. dependency

39. pip install

40. setup.py

41. nope

42. docs
&
hack

43. for(;;)

44. pip uninstall
giveafuck

48. Life life = new Life()

54. taming a lion
1800s

55. beat into submission
fear
guns & whips
confusion

56. taming a lion
present

57. understand
conditioning
behaviour → signal
reward
trust

58. taming a lion
1800s

59. beat into submission
fear
guns & whips
confusion

60. deploy by hand, hack
fear
guns & whips
confusion

61. deploy by hand, hack
but it works!
guns & whips
confusion

62. deploy by hand, hack
but it works!
hack till it works
confusion

63. deploy by hand, hack
but it works!
hack till it works
special decisions

65. taming a lion
present

66. understand
conditioning
behaviour → signal
reward
trust

67. deploy: hard
conditioning
behaviour → signal
reward
trust

68. deploy: hard
CI
behaviour → signal
reward
trust

69. deploy: hard
CI
push → test → green
reward
trust

70. deploy: hard
CI
push → test → green
happy
trust

71. deploy: hard
CI
push → test → green
happy
it works in Live

73. what you needwhat you need

74. team

75. working software

76. repeatable build

77. deployment

78. rollback

79. release

80. team

81. committed
to
quality

82. process
can't
compensate

83. pip install
giveafuck

84. everyone
deploys

85. identical
environment

86. everyone
is
responsible

87. learn

88. working
software

89. tests

90. unit tests
functional tests
acceptance tests

91. acceptance:
user's
viewpoint

92. continuous
integration

93. quick
reliable

94. slow test: fail

95. no pylint: fail

96. keep it green

97. check in often
always ready to
rollback

98. responsible:
dev + qa

99. quality

100. broken:
triage

101. right now
vs
asap

102. repeatable
build

103. automated

104. used by everyone
everywhere

105. no manual changes

106. deployment
script

107. used by everyone
everywhere

108. deploy.sh
<environment>
<version>

109. not just code
configuration
infrastructure

110. always follow
pipeline

111. even on
emergencies

112. buggy changes
unknown state
irreproducible
what went wrong?

113. what went wrong?

114. rollback

115. blue-green
green is live
release to blue
test, accept
blue is new green

116. canary
show new version
to a few

117. database:
keep backwards-
compatible

118. release

119. last step
automatic

120. small changes
frequent
experience
less risk

121. maybe
not for you

122. tips

123. split in components

124. rehearse releases
get very good
at them!

125. infrastructure
manage and test

126. all environments
equal
use vagrant

127. automate
everything
(not possible?
document)

128. Questions?
Answers?
@grimborg
dev@oscarvilaplana.cat Thank you!