Automation for web development

Automation for web development

Automation as a form of pre-commitment to best practices in web development. A talk given to the University of Melbourne's Web Information Technology class (Sem 1, 2013), based on experiences at 99designs.

Ef621203799c7dcc735dc469d1aaee6f?s=128

Lars Yencken

May 15, 2013
Tweet

Transcript

  1. Automation for web development A talk by @larsyencken to the

    University of Melbourne's Web Information Technologies class (Sem 1, 2013)
  2. Hi! I'm lars @larsyencken

  3. My background

  4. Early web hacking

  5. None
  6. None
  7. None
  8. 0 225000 450000 675000 900000 Jan-07 Jan-08 Jan-09 Jan-10 Jan-11

    Jan-12 Jan-13 Designs submitted
  9. Why automate? }

  10. people! Why automate? }

  11. People...

  12. have good intentions

  13. but , have lots to do!

  14. cut corners

  15. don't write tests

  16. don't run tests

  17. don't share instructions

  18. don't follow instructions

  19. are non-deterministic

  20. I have all these problems I should know...

  21. automation is pre-commitment

  22. Pre-commit to...

  23. Pre-commit to... testing your code

  24. Pre-commit to... shipping often and early

  25. Pre-commit to... disposing your infrastructure

  26. Pre-commit to testing "continuous integration"

  27. Pre-commit to testing running tests

  28. Jenkins TravisCI JuiCI

  29. developer

  30. developer remote repo git push

  31. developer remote repo git push CI server post

  32. developer remote repo git push CI server post tests run

  33. developer remote repo git push CI server post tests run

    notifies
  34. developer remote repo git push CI server post tests run

    notifies mark status
  35. Github integration

  36. Pre-commit to testing writing tests

  37. Test driven development

  38. Test driven bug-fixing

  39. Calculate test coverage

  40. Enforce coverage in test runs

  41. Pre-commit to testing 1. Set up automated tests which run

    every time you push code 2. Test before coding wherever possible, to make sure your design will allow for testing 3. Measure coverage of your tests, and fail your test run unless coverage increases
  42. Pre-commit to shipping early and often "continuous deployment"

  43. waterfall plan far ahead, ship at the end

  44. agile plan a fortnight, ship every fortnight a “sprint”

  45. continuous ship a feature whenever it’s ready

  46. Make dev tasks one-step

  47. Rake rake ctags Shovel shovel ctags Grunt grunt ctags GNU

    Make make ctags
  48. Make deployment one-step

  49. Capistrano cap deploy Fabric fab deploy GNU Make make deploy

  50. Feature-flipping

  51. continuous ship a feature whenever it’s ready

  52. feature-flipping ship features to admins until they’re ready use guards

  53. feature-flipping ship features to admins until they’re ready use guards

    http://99designs.com/tech-blog/blog/2012/03/01/feature-flipping/
  54. Pre-commit to shipping early and often 1. Make builds, deploys

    and other tedious tasks one-step 2. Use your test suite as a sanity check during deployment 3. Use feature flipping to get your code into the live site earlier
  55. Pre-commit to disposing of servers "software as infrastructure"

  56. None
  57. “build recipes, not systems”

  58. Babushka Chef Puppet JuJu

  59. None
  60. Commit to disposing of servers 1. Write recipes for servers

    which start from a basic machine image (e.g. Ubuntu) 2. Use tools like Vagrant to prototype new server types and test recipes
  61. thanks!