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

Architecting a Culture of Quality

Architecting a Culture of Quality

Python Nordeste 2014


David Cramer

May 02, 2014


  1. David Cramer twitter.com/zeeg Architecting a Culture of Quality

  2. None
  3. None
  4. I work on Developer Productivity

  5. (aka the build system + tooling)


  7. None
  8. How do we stop emergency pushes?

  9. Identifying the Problems


  11. Inaccurate or missing tests

  12. Complex dependencies

  13. Day 1 at Dropbox..

  14. "Go through these manual steps to setup a dev environment”

  15. None
  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

  39. Building A Testing Culture

  40. Make testing so easy that you feel good about writing

  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

  48. None
  49. Test Continuously Before code review

  50. Test Continuously During code review

  51. Test Continuously Post-code review (merge)


  53. None
  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

  58. None
  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