Shipping Sentry

Transcript

1. 1.

   Armin Ronacher Shipping Sentry

2. 2.

   Armin Ronacher @mitsuhiko Flask / Sentry / Lektor

3. 3.

   Find the Slides at lucumr.pocoo.org/talks

4. 4.

   reach out to me! I want to talk :)

5. 5.

   sentry.io

6. 6.

   None
7. 7.

   None
8. 8.

   None
9. 9.

   None
10. 10.

    None
11. 11.

    「 THE TWO PRODUCTS 」

12. 12.

    sentry vs ‘getsentry’

13. 13.

    sentry open source repo on-premise monthly releases

14. 14.

    ‘getsentry’ billing & quotas depends on sentry hourly deploys

15. 15.

    「 GROWING THE TEAM 」

16. 16.

    2.5 to 25 more process keep processes light keep developers

    happy
17. 17.

    2 locations process in code natural for us because of

    the Open Source nature
18. 18.

    「 THE GOALS 」

19. 19.

    deploy in seconds be unable to screw up and if

    you do: instant rollbacks
20. 20.

    tag a release once a month

21. 21.

    「 WORKFLOW 」

22. 22.

    commit review integration deploy

23. 23.

    requires good test coverage requires good local setup makes it

    easier for newcomers
24. 24.

    「 COMMITTING 」

25. 25.

    lint on commit!

26. 26.

    1 Release / Month 5 Deployments / Day On Prem:

    Hosted:
27. 27.

    None
28. 28.

    master is stable

29. 29.

    1. branch off master 2. pull request 3. merge

30. 30.

    all the pull requests

31. 31.

    !! AVOID DOWNTIME !!

32. 32.

    postgres <3 transactional ddl, concurrent indexes, cheap alter table add

    nullable columns
33. 33.

    bidirectional compatibility

34. 34.

    separation of state and connections

35. 35.

    「 CONTINUOUS TESTING 」

36. 36.

    sentry travis-ci.org test all the code

37. 37.

    ‘getsentry’ travis-ci.com test code relevant for us

38. 38.

    「 CONTINUOUS DELIVERY 」

39. 39.

    FREIGHT wait for travis > build > ship

40. 40.

    bidirectional communication with the main slack channel

41. 41.

    dev never matches prod :(

42. 42.

    thus: fast rollbacks! (backwards + forwards compatibility)

43. 43.

    「 CODE STRUCTURE 」

44. 44.

    large systems are organisms

45. 45.

    not all things will run the same code at the

    same time
46. 46.

    data schema ~ code behavior

47. 47.

    break up larger features

48. 48.

    feature flag it! (we shipped some code to on-prem we

    backed out)
49. 49.

    「 REPO STRUCTURE 」

50. 50.

    move towards “monorepos” (but within what is possible with our

    tools) {not as mono as we would like}
51. 51.

    「 MOVING PARTS 」

52. 52.

    keep dev basic: fewer parts

53. 53.

    do not diverge dev from prod too much

54. 54.

    virtual machines and docker are not an acceptable dev environment

55. 55.

    「 REPRODUCIBLE BUILDS 」

56. 56.

    pip freeze / yarn

57. 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. 58.

    build once > ship to many

59. 59.

    「 BINARY DEPS 」

60. 60.

    OS X & “manylinux”

61. 61.

    C/C++/Rust Modules for Python

62. 62.

    Build in Docker on old CentOS

63. 63.

    Debian / RHEL / Ubuntu

64. 64.

    「 MONITOR FAILURES 」

65. 65.

    associate failures to users

66. 66.

    map support requests to failures

67. 67.

    use sentry :-)

68. 68.

    「 FRIENDLY ROBOTS 」

69. 69.

    replace yourself!

70. 70.

    bots and webhooks

71. 71.

    github hooks

72. 72.

    notify to communication hub

73. 73.

    testing danger.systems

74. 74.

    「 BETTER CLIMATE 」

75. 75.

    the more robots, the better the integration, the smaller the

    fear of doing damage
76. 76.

    If you can launch a feature on your first day

    of work that's motivating
77. 77.

    also: happy customers

78. 78.

    Q&A reach out to me! I want to talk :)