Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

    View Slide

  2. Armin Ronacher
    @mitsuhiko
    Flask / Sentry / Lektor

    View Slide

  3. ̿ SENTRY ̀

    View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. ̿ THE TWO PRODUCTS ̀

    View Slide

  8. sentry vs ‘getsentry’

    View Slide

  9. sentry open source repo
    on-premise
    monthly releases

    View Slide

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

    View Slide

  11. ̿ THE GOALS ̀

    View Slide

  12. deploy in seconds
    be unable to screw up
    and if you do: instant rollbacks

    View Slide

  13. tag a release once a month

    View Slide

  14. ̿ WORKFLOW ̀

    View Slide

  15. commit
    review
    integration
    deploy

    View Slide

  16. requires good test coverage
    requires good local setup
    makes it easier for newcomers

    View Slide

  17. ̿ COMMITTING ̀

    View Slide

  18. lint on commit!

    View Slide

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

    View Slide

  20. View Slide

  21. master is stable

    View Slide

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

    View Slide

  23. all the pull requests

    View Slide

  24. !! AVOID DOWNTIME !!

    View Slide

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

    View Slide

  26. bidirectional compatibility

    View Slide

  27. separation of state and connections

    View Slide

  28. ̿ CONTINUOUS TESTING ̀

    View Slide

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

    View Slide

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

    View Slide

  31. ̿ CONTINUOUS DELIVERY ̀

    View Slide

  32. FREIGHT
    wait for travis > build > ship

    View Slide

  33. bidirectional
    communication with
    the main slack channel

    View Slide

  34. dev never matches prod :(

    View Slide

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

    View Slide

  36. ̿ CODE STRUCTURE ̀

    View Slide

  37. large systems are organisms

    View Slide

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

    View Slide

  39. data schema ~ code behavior

    View Slide

  40. break up larger features

    View Slide

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

    View Slide

  42. ̿ MOVING PARTS ̀

    View Slide

  43. keep dev basic: fewer parts

    View Slide

  44. do not diverge dev from prod
    too much

    View Slide

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

    View Slide

  46. ̿ REPRODUCIBLE BUILDS ̀

    View Slide

  47. pip freeze / npm shrinkwrap

    View Slide

  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

    View Slide

  49. build once > ship to many

    View Slide

  50. ̿ MONITOR FAILURES ̀

    View Slide

  51. associate failures to users

    View Slide

  52. map support requests to failures

    View Slide

  53. use sentry :-)

    View Slide

  54. ̿ FRIENDLY ROBOTS ̀

    View Slide

  55. replace yourself!

    View Slide

  56. bots and webhooks

    View Slide

  57. github hooks

    View Slide

  58. notify to communication hub

    View Slide

  59. ̿ BETTER CLIMATE ̀

    View Slide

  60. the more robots,
    the better the integration,
    the smaller the fear of doing damage

    View Slide

  61. If you can launch a feature on your first
    day of work that's motivating

    View Slide

  62. also: happy customers

    View Slide

  63. Q&A

    View Slide