Staying sane with Small Incremental Releases

My presentation at GitHub Satellite about the advantages of shipping small incremental releases and how to get there.

Transcript

1. Staying sane with Small incremental releases
2. @roncohen ron@opbeat.com Ron Cohen CTO/PM, co-founder @ Opbeat
3. Next-gen performance monitoring.
5. •Story time •Why small incremental releases are better •How to get there
6. Ultimate goals Ship more
 Sleep more
7. Increasing velocity & quality
8. App store warning
9. Story time • Working on a new feature for three weeks • 39 commits, 20 changed files
10. Story time • Working on a new feature for three weeks • 39 commits, 20 changed files • Also: 6 bug fixes, 4 improvements
12. Roll back
13. Fix it Try again
14. Stressful Anticlimactic Demotivating
15. Why did it fail?
16. 6 bug fixes 4 improvements 1 feature Should have been shipped individually
17. Too much
18. Code review took half a day Not very thorough
19. Code Reviews
20. SCIENCE (-ish) 2500 code reviews, 50 programmers, and 3.2 million LOC at Cisco Systems SmartBear Software® code review study
21. You should ship Small incremental releases
22. Shipping feels good
23. What changed? Who can fix it?
24. One developer per release
25. Accountability
26. YOU, YOU, YOU ! You built it ⛵ You ship it # You fix it
27. Small releases • Easier rollbacks • More parallelism in team / less blocking
28. Okay, how do we get there?
29. Prerequisites
30. Reliable and fast deployments
31. Good automatic tests
32. Low overhead code reviews
33. “We have that”
34. Train of thought Feature A Building
35. Train of thought Feature A Building
36. Train of thought Feature A Building Module B Uses
37. Train of thought Feature A Building Refactor Module B Uses
38. risk in doing big releases overhead per release Can I roll this fix into the current branch? vs
39. What is the Smallest Release That Makes Sense? Each iteration
40. Ship a feature over multiple releases We can even
42. Practice makes perfect
43. Get code in production quickly
44. Get code in production quickly using feature flags
45. FF in Open Source?
46. gem 'rails', git: ‘git@github.com:rails/rails.git’, branch: ‘new-feature’ $ npm install expressjs/express@new-feature $ pip install git@github.com/django/django@new-feature
47. small = simple
48. “Do the simple thing first” – Mike Krieger, co-founder @ Instagram
49. Reinventing the wheel
50. Not Invented Here
51. The problems we need to solve are unique
52. The problems we need to solve are unique WRONG
53. The problems we need to solve are unique (Mostly) WRONG
54. “Lets build a distributed system in order to solve this”
56. If you want to deliver value Don’t invent Automatic failover Leadership election Encryption scheme
57. Open Source json parser json database
58. Ship more
 Sleep more Ultimate goals
59. Practice Smallest Possible Release Get code in production quickly Use feature flags Simple Don’t reinvent Summary
60. @roncohen ron@opbeat.com