Pro Yearly is on sale from $80 to $50! »

Shipping Sentry

Shipping Sentry

How we ship Sentry to production and on premises.

181de1fb11dffe39774f3e2e23cda3b6?s=128

Armin Ronacher

November 15, 2016
Tweet

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