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

Continuous Deployment@dianecessna

dcessna@sharethrough.com