$30 off During Our Annual Pro Sale. View Details »

Shipping Sentry

Shipping Sentry

How we ship Sentry to production and on premises.

Armin Ronacher

November 15, 2016
Tweet

More Decks by Armin Ronacher

Other Decks in Programming

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