This document discusses the importance of process for software development teams. It argues that good process allows even great teams to succeed, while bad process can cause great teams to struggle. It also notes that deployment and delivery are often not given the same attention as development activities. The document then outlines several processes used at Codeship that help speed innovation, such as repository-driven infrastructure, developer automated deployment, full system automation, immutable infrastructure, and automating every layer. It argues these processes help teams innovate faster by reducing fear and inertia.

1. Why I Learned to Stop
Worrying and Love the Process
Flo Motlik
@flomotlik
flo@codeship.io
1
bit.ly/codeshipprocess

2. As Developers we love
process
2

3. • TDD
• Code Review,
• Branching & Merging
• Pair programming
• …
3

4. Good process makes good
teams win
4

5. Bad process makes great
teams suck
5

6. Deployment/Delivery is 2nd
class citizen
6

7. “Unshipped Code is technical debt.
No benefits, only costs”
Alex Tacho
@alexandertacho
7

8. Hard to resolve
8

9. Not just technical problem
9

10. Customer Feedback
essential
10

11. late feedback, slow
improvement
11

12. Money not a barrier to entry
12

13. All about speed of innovation
13

14. Processes that helped
us at Codeship
14

15. Repository driven
infrastructure
15

16. Developer Automated Deployment
Push to production branch
Notify when ready
or problems
16

17. Full automation to focus on
development
17

18. Repo is one true source
18

19. • No Misunderstandings
• One last commit per Branch
• We live in our repos
19

20. Eventually consistent
infrastructure
20

21. You push to repo, eventually
infrastructure is up to date
21

22. Full system
automation
22

23. • Testing
• Deployment
• Metrics & Health Checks
• Validation
• Recovery
• Feedback and Notifications
23

24. Updating servers often risks
inconsistent server state
24

25. Rip out and replace
25

26. Stop thinking “single server”,
start thinking “part of a system”
26

27. Immutable
Infrastructure
27

28. Build new images for every
change
28

29. Test in Isolation
29

30. Replace in production
30

31. Start 1 or 500 instances from
same image
31

32. • Atomic Deployments
• Reversible
• Ephemeral
• Forces State isolation and boundaries
• Fast Recovery
• Testability
32

33. Automate every layer
33

34. Empty machine to full image
must be automated
34

35. Why we needed to
build this way
35

36. make innovation faster and
remove fear
36

37. “Fear is the path to the dark side. Fear
leads to Inertia. Inertia leads to Paralysis.
Paralysis leads to going out of business.”
37
DevOps Yoda

38. As developers we are
responsible for shipping our
features
38

39. Code in repo is not shipping
39

40. It’s shipped when at customer
and we get actionable metrics
40

41. Need to embrace process and
push for it, not wait for somebody
else to come up with it.
41

42. Codeship.io
42
Continuous Delivery as a service