Iterate and Ship

How we iterate and ship at Sentry.

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