Continuous Deployment is defined as automatically deploying code changes to production after tests pass. This document outlines Sharethrough's journey to implementing Continuous Deployment, including initial attempts at more frequent deploys, bringing in an expert, reducing risk through feature flags and smaller commits, automating notifications, deploys, and optimizing the process. Lessons learned include making deploys a non-event, fixing bugs faster, and increasing developer productivity and morale. Resources on Continuous Delivery and Deployment are also provided.

1. Continuous Deployment
@dianecessna
Engineering Team Lead

2. 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

3. What is Continuous Deployment?
Continuous Deployment is when every change is
automatically deployed to production after all tests pass

4. • Continuous Delivery - You are able to deploy at any
time
• Continuous Deployment - You automatically deploy
after every change
Continuous Deployment vs Continuous Delivery

5. • Reduced risk when deploying
• Faster feedback from users and stakeholders
• A lot less communication overhead
Benefits of Continuous Deployment

6. • 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

7. • 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?

8. First Attempt: Deploy more often!

9. • Timothy Fitz
• Coined the term ‘Continuous Deployment’
• Early Technical Lead at IMVU
• http://timothyfitz.com/
• @TimothyFitz
Second Attempt: Bring in an Expert

10. • 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

11. • 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

12. • 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

13. Step 4 - Automate Deploys

14. • Speed up any extremely slow tests
• Break tests into suites and run them in parallel on Jenkins using the Multijob Plugin
Step 5 - Optimize

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

16. • 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.)

17. • 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.)

18. • 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

19. • 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

20. Continuous Deployment
@dianecessna
dcessna@sharethrough.com