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

Iterate and Ship

Iterate and Ship

How we iterate and ship at Sentry.

Armin Ronacher

May 10, 2016
Tweet

More Decks by Armin Ronacher

Other Decks in Programming

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