continuous deployment of rails applications
TRANSCRIPT
Continuous Deployment@dianecessna
Engineering Team Lead
What is Continuous Deployment?
Continuous Deployment is when a developer is at a hackathon and passes out with their face on the keyboard and accidentally
runs the deploy script all night long
What is Continuous Deployment?
Continuous Deployment is when every change is automatically deployed to production after all tests pass
• Continuous Delivery - You are able to deploy at any time
• Continuous Deployment - You automatically deploy after every change
Continuous Deployment vs Continuous Delivery
• Reduced risk when deploying • Faster feedback from users and stakeholders • A lot less communication overhead
Benefits of Continuous Deployment
• Engineer writes code, checks into master • Jenkins runs tests, builds application, deploys to staging • Some time later, engineer communicates the changes about
to be deployed • Product Managers communicate major changes to users, and
give engineers permission to deploy • Engineer deploys to production (via Capistrano)
Life at Sharethrough before CD
• Communication overhead associated with a growing team and remote office • Change logs were long and not easy to decipher what was going to be deployed • Lots of changes in each deploy so risk was high even though we were deploying
at least every 1 to 2 days • multiple breaking migrations + very long migrations = major downtime
Why did we need to change?
First Attempt: Deploy more often!
• Timothy Fitz • Coined the term ‘Continuous Deployment’ • Early Technical Lead at IMVU • http://timothyfitz.com/ • @TimothyFitz
Second Attempt: Bring in an Expert
• Everyone should be committing to master • No more pull requests or branches • Getting comfortable committing code that is a work in progress • Smaller commits and more often
Step 1 - Reduce Risk
• Get to the point where you don’t need to announce deploys
• Use feature flags for all new features
• Give the product team control of turning features on/off through a UI
Step 2 - Make deploys a non-event
• Slack Integrations • Jenkins - notify when the build fails • Airbrake - notify when there are production errors • Capistrano - notify when there is a deploy and list the commits
Step 3 - Notifications
Step 4 - Automate Deploys
• Speed up any extremely slow tests • Break tests into suites and run them in parallel on Jenkins using the Multijob Plugin
Step 5 - Optimize
• Involve the product team early so they are not surprised • If something breaks horribly it means we have a flaw somewhere in the
pipeline - fault is not on the developer • If you’re not committing multiple times a day you might be putting too
much in one commit • The time it takes to get a bug fix into production becomes more
important
Lessons Learned
• Be more explicit about when a feature needs to be feature flagged (we use a label in Pivotal Tracker)
• Smaller stories work better when making enhancements that don’t need to be feature flagged
• Always add a chore to remove the feature flag and old code once a feature is released
Lessons Learned (cont.)
• It’s only scary for a couple of days • Committing to master is safer than you think • Bugs are caught and fixed faster than ever • Productivity is increased • Developers are happier
Lessons Learned (cont.)
• Reduce risk by making smaller changes to master • Use feature flags to make deploys a non-event • Automate communication about deploys & failures • Automate deploys to production • Speed up your build time
Summary
• http://engineering.sharethrough.com/blog/2015/04/22/inching-towards-continous-deployment/
• https://teamgaslight.com/blog/how-continuous-deployment-boosts-developer-morale-and-productivity
• http://timothyfitz.com/2009/02/08/continuous-deployment/
• https://www.airpair.com/ruby-on-rails/continuous-deployment
• http://martinfowler.com/bliki/ContinuousDelivery.html
Resources