Iterate and Ship

Transcript

1. 1.

   Armin Ronacher iterate and ship

2. 2.

   Armin Ronacher @mitsuhiko Flask / Sentry / Lektor

3. 3.

   ̿ SENTRY ̀

4. 4.

   None
5. 5.

   None
6. 6.

   None
7. 7.

   ̿ THE TWO PRODUCTS ̀

8. 8.

   sentry vs ‘getsentry’

9. 9.

   sentry open source repo on-premise monthly releases

10. 10.

    ‘getsentry’ billing & quotas depends on sentry hourly deploys

11. 11.

    ̿ THE GOALS ̀

12. 12.

    deploy in seconds be unable to screw up and if

    you do: instant rollbacks
13. 13.

    tag a release once a month

14. 14.

    ̿ WORKFLOW ̀

15. 15.

    commit review integration deploy

16. 16.

    requires good test coverage requires good local setup makes it

    easier for newcomers
17. 17.

    ̿ COMMITTING ̀

18. 18.

    lint on commit!

19. 19.

    1 Release / Month 5 Deployments / Day On Prem:

    Hosted:
20. 20.

    None
21. 21.

    master is stable

22. 22.

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

23. 23.

    all the pull requests

24. 24.

    !! AVOID DOWNTIME !!

25. 25.

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

    nullable columns
26. 26.

    bidirectional compatibility

27. 27.

    separation of state and connections

28. 28.

    ̿ CONTINUOUS TESTING ̀

29. 29.

    sentry travis-ci.org test all the code

30. 30.

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

31. 31.

    ̿ CONTINUOUS DELIVERY ̀

32. 32.

    FREIGHT wait for travis > build > ship

33. 33.

    bidirectional communication with the main slack channel

34. 34.

    dev never matches prod :(

35. 35.

    thus: fast rollbacks! (backwards + forwards compatibility)

36. 36.

    ̿ CODE STRUCTURE ̀

37. 37.

    large systems are organisms

38. 38.

    not all things will run the same code at the

    same time
39. 39.

    data schema ~ code behavior

40. 40.

    break up larger features

41. 41.

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

    backed out)
42. 42.

    ̿ MOVING PARTS ̀

43. 43.

    keep dev basic: fewer parts

44. 44.

    do not diverge dev from prod too much

45. 45.

    virtual machines and docker are not an acceptable dev environment

46. 46.

    ̿ REPRODUCIBLE BUILDS ̀

47. 47.

    pip freeze / npm shrinkwrap

48. 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. 49.

    build once > ship to many

50. 50.

    ̿ MONITOR FAILURES ̀

51. 51.

    associate failures to users

52. 52.

    map support requests to failures

53. 53.

    use sentry :-)

54. 54.

    ̿ FRIENDLY ROBOTS ̀

55. 55.

    replace yourself!

56. 56.

    bots and webhooks

57. 57.

    github hooks

58. 58.

    notify to communication hub

59. 59.

    ̿ BETTER CLIMATE ̀

60. 60.

    the more robots, the better the integration, the smaller the

    fear of doing damage
61. 61.

    If you can launch a feature on your first day

    of work that's motivating
62. 62.

    also: happy customers

63. 63.

    Q&A