Architecting a Culture of Quality

Python Nordeste 2014

Transcript

1. David Cramer twitter.com/zeeg Architecting a Culture of Quality
4. I work on Developer Productivity
5. (aka the build system + tooling)
6. ň+PGGFVQRWUJVJKUEJCPIGQWVTKIJVPQYʼn
8. How do we stop emergency pushes?
9. Identifying the Problems
10. Slow build process DQQVUVTCRRTQXKUKQPVGUVUGVE
11. Inaccurate or missing tests
12. Complex dependencies
13. Day 1 at Dropbox..
14. "Go through these manual steps to setup a dev environment”
16. "Why aren’t we using something like Vagrant?"
17. Keep Things Simple
18. “make” — a promise that it’s simple
19. .PHONY: develop setup-env ! # install dependencies develop: setup-env npm install bower install env/bin/pip install -e . ! ! # ensure virtualenv setup-env: virtualenv ./env
20. a Makefile is just one solution
21. Bootstrap affects
    our sanity
22. vagrant up
    ⇢ puppet apply
23. Bootstrap affects
    newly hired developers
24. Bootstrap affects
    rebuilding environments
25. Bootstrap affects
    ability and time to run tests
26. Remove Dependencies
27. You cannot reproduce your
    production environment
28. Stop Trying
29. Do you really need
    Apache? RTQDCDN[PQV
30. Do you really need
    HAProxy? UGTKQWUN[!
31. Do you really need
    RabbitMQ? JQYCDQWV4GFKU!
32. Do you really need
    Zookeeper? PQRG
33. Do you really need
    Hadoop? NQN
34. Do you really need
    Anything?
35. Justify your dependencies
36. Use build servers
    for whatever is left over
37. Find Your Bottlenecks [QWRTQDCDN[FQP VGXGPPGGFC8/
38. Does a using (and maintaining) a VM actually save you time?
39. Building A Testing Culture
40. Make testing so easy that you feel good about writing tests
41. "Oh hey, a test I can copy/paste" +VņUCDQWVVJGOCMKPIKVCEEGUUKDNG
42. Encourage building better testing tools and paradigms
43. pip install pytest
44. pip install flake8
45. pip install mock
46. Your goal is to
    make testing accessible
47. Automatically test individual commits
    to ensure every change is stable
49. Test Continuously
    Before code review
50. Test Continuously
    During code review
51. Test Continuously
    Post-code review (merge)
52. Keep a tight Feedback Loop PQQPGYCPVUVQHKPFQWVVJGPGZVFC[VJCVVJGKTEQFGYCUDTQMGP
54. Time to response is so important that we fanout to 25 servers per build
55. Prevent mistakes by blocking
    commits which fail the build cycle
56. Red builds can never be deployed
57. Use Code Review
59. Use Code Review to
    sanity check code
60. Use Code Review to
    influence testing culture
61. Use Code Review to
    educate developers
62. Use Code Review to
    decrease cycle time
63. "Does this change look sane?"
64. "No, this will break X, Y, and Z" FKF[QWGXGPMPQY:YCUCVJKPI!
65. Aim for Quality Patches
66. Changes happen outside of master
    causing master to be the new stable CMCVKRQTVTWPM
67. Quality Will Happen
68. Smaller, better commits
69. Accessibility is your goal
70. Accuracy breeds adoption
71. Scale culture through tooling
72. Thank You! ! twitter.com/zeeg