Iterate and Ship

Iterate and Ship

How we iterate and ship at Sentry.

181de1fb11dffe39774f3e2e23cda3b6?s=128

Armin Ronacher

May 10, 2016
Tweet

Transcript

  1. Armin Ronacher iterate and ship

  2. Armin Ronacher @mitsuhiko Flask / Sentry / Lektor

  3. ̿ SENTRY ̀

  4. None
  5. None
  6. None
  7. ̿ THE TWO PRODUCTS ̀

  8. sentry vs ‘getsentry’

  9. sentry open source repo on-premise monthly releases

  10. ‘getsentry’ billing & quotas depends on sentry hourly deploys

  11. ̿ THE GOALS ̀

  12. deploy in seconds be unable to screw up and if

    you do: instant rollbacks
  13. tag a release once a month

  14. ̿ WORKFLOW ̀

  15. commit review integration deploy

  16. requires good test coverage requires good local setup makes it

    easier for newcomers
  17. ̿ COMMITTING ̀

  18. lint on commit!

  19. 1 Release / Month 5 Deployments / Day On Prem:

    Hosted:
  20. None
  21. master is stable

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

  23. all the pull requests

  24. !! AVOID DOWNTIME !!

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

    nullable columns
  26. bidirectional compatibility

  27. separation of state and connections

  28. ̿ CONTINUOUS TESTING ̀

  29. sentry travis-ci.org test all the code

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

  31. ̿ CONTINUOUS DELIVERY ̀

  32. FREIGHT wait for travis > build > ship

  33. bidirectional communication with the main slack channel

  34. dev never matches prod :(

  35. thus: fast rollbacks! (backwards + forwards compatibility)

  36. ̿ CODE STRUCTURE ̀

  37. large systems are organisms

  38. not all things will run the same code at the

    same time
  39. data schema ~ code behavior

  40. break up larger features

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

    backed out)
  42. ̿ MOVING PARTS ̀

  43. keep dev basic: fewer parts

  44. do not diverge dev from prod too much

  45. virtual machines and docker are not an acceptable dev environment

  46. ̿ REPRODUCIBLE BUILDS ̀

  47. pip freeze / npm shrinkwrap

  48. 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
  49. build once > ship to many

  50. ̿ MONITOR FAILURES ̀

  51. associate failures to users

  52. map support requests to failures

  53. use sentry :-)

  54. ̿ FRIENDLY ROBOTS ̀

  55. replace yourself!

  56. bots and webhooks

  57. github hooks

  58. notify to communication hub

  59. ̿ BETTER CLIMATE ̀

  60. the more robots, the better the integration, the smaller the

    fear of doing damage
  61. If you can launch a feature on your first day

    of work that's motivating
  62. also: happy customers

  63. Q&A