Shipping Sentry

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

6. None
7. None
8. None
9. None
10. None

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:
27. None

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 :)