Shipping Sentry

How we ship Sentry to production and on premises.

Transcript

1. Armin Ronacher Shipping Sentry
2. Armin Ronacher @mitsuhiko Flask / Sentry / Lektor
3. Find the Slides at lucumr.pocoo.org/talks
4. reach out to me! I want to talk :)
5. sentry.io
11. 「 THE TWO PRODUCTS 」
12. sentry vs ‘getsentry’
13. sentry open source repo on-premise monthly releases
14. ‘getsentry’ billing & quotas depends on sentry hourly deploys
15. 「 GROWING THE TEAM 」
16. 2.5 to 25 more process keep processes light keep developers happy
17. 2 locations process in code natural for us because of the Open Source nature
18. 「 THE GOALS 」
19. deploy in seconds be unable to screw up and if you do: instant rollbacks
20. tag a release once a month
21. 「 WORKFLOW 」
22. commit review integration deploy
23. requires good test coverage requires good local setup makes it easier for newcomers
24. 「 COMMITTING 」
25. lint on commit!
26. 1 Release / Month 5 Deployments / Day On Prem: Hosted:
28. master is stable
29. 1. branch off master 2. pull request 3. merge
30. all the pull requests
31. !! AVOID DOWNTIME !!
32. postgres <3 transactional ddl, concurrent indexes, cheap alter table add nullable columns
33. bidirectional compatibility
34. separation of state and connections
35. 「 CONTINUOUS TESTING 」
36. sentry travis-ci.org test all the code
37. ‘getsentry’ travis-ci.com test code relevant for us
38. 「 CONTINUOUS DELIVERY 」
39. FREIGHT wait for travis > build > ship
40. bidirectional communication with the main slack channel
41. dev never matches prod :(
42. thus: fast rollbacks! (backwards + forwards compatibility)
43. 「 CODE STRUCTURE 」
44. large systems are organisms
45. not all things will run the same code at the same time
46. data schema ~ code behavior
47. break up larger features
48. feature flag it! (we shipped some code to on-prem we backed out)
49. 「 REPO STRUCTURE 」
50. move towards “monorepos” (but within what is possible with our tools) {not as mono as we would like}
51. 「 MOVING PARTS 」
52. keep dev basic: fewer parts
53. do not diverge dev from prod too much
54. virtual machines and docker are not an acceptable dev environment
55. 「 REPRODUCIBLE BUILDS 」
56. pip freeze / yarn
57. nothing is more frustrating than a failed deploy because a dependency of a dependency of a dependency of a dependency pushed out a broken release
58. build once > ship to many
59. 「 BINARY DEPS 」
60. OS X & “manylinux”
61. C/C++/Rust Modules for Python
62. Build in Docker on old CentOS
63. Debian / RHEL / Ubuntu
64. 「 MONITOR FAILURES 」
65. associate failures to users
66. map support requests to failures
67. use sentry :-)
68. 「 FRIENDLY ROBOTS 」
69. replace yourself!
70. bots and webhooks
71. github hooks
72. notify to communication hub
73. testing danger.systems
74. 「 BETTER CLIMATE 」
75. the more robots, the better the integration, the smaller the fear of doing damage
76. If you can launch a feature on your first day of work that's motivating
77. also: happy customers
78. Q&A reach out to me! I want to talk :)