Experimenting with continuous deployment for feature branches

My lightning talk was given at Sydney DevOps on the 16 May, 2013. It was based on an earlier blog post (http://tatey.com/2013/05/06/experimenting-with-continuous-deployment-for-feature-branches/)

Transcript

1. Experimenting with continuous deployment for feature branches @tatejohnson tatey.com
3. Time between pushing code and user testing was too long
4. • Ask non-technical person to come to my computer • Manually deploy to staging server. Merge branches. Run migrations. Update sample data. • Distraction. Take away from meaningful work.
5. We can do better
6. • Developer pushes code • Application is immediately deployed on disposable instance with sample data • Accessible to anyone • Zero impact on developer’s workflow • Cheap ($)
7. We built an internal tool called Tug
8. • Listens for web hooks from GitHub • Queues deploy for new and existing branches • Queues teardown for deleted branches • Announces result on Campfire
9. We’re using Heroku
10. • Right amount of abstraction on top of AWS EC2 • We see Heroku as a tool for provisioning instances • Could easily be some combination of Puppet, Chef or Vagrant
11. New branches • Create new instance • Set add-ons • Set environment variables • Create database • Seed with sample data
12. Existing branches • Update add-ons • Update environment variables • Drop database • Create database • Seed with sample data
13. Deleted branches • Automatically cleanup • Delete existing instance
16. Configuring our application
17. Environment Variables • Sourced from application.yml or configuration variables (Heroku for ENV) • Tug injects configuration variables at deploy time • Mostly used for configuring external services (Eg: SMTP and AWS S3)
18. External services • All external services have distinct credentials • Nothing is shared with production instances • For simplicity, staging instances share credentials
19. • 1x web dyno running unicorn with three children processes • 1x worker dyno running delayed job for working off queue in background • PostgreSQL (Dev tier) • Difference between staging instances and production instances is number of dynos, database tier and monitoring add-ons Dynos and Add-ons
20. Cheap ($) • 750 free dyno hours per month • Shuts down after 1 hour of inactivity • Unless someone is consuming all the time, pretty much free • Add-ons use free tier
21. Results have been great
22. • No more waiting to try changes • We can turn around from discussion, to implementation and into the hands of a tester in less than a day
23. • Caught out failed deploys before they hit production (Eg: Asset pipeline failed to compile) • Experiment with new configuration under controller conditions (Eg: Switch from Thin to Unicorn)
24. • “End of iteration” demo’s are pain free. Nothing to setup, just go. • Better code reviews on pull requests. Try out code without stashing changes locally
25. Plans for the future
26. • Deploy after build is green • Continuous deployment for production • Make Tug available to other organisations if people think it’s valuable
27. Thanks @tatejohnson tatey.com