How Intercom Ships Code to Production 100 Times a Day

Presented at Shipitcon 2017 - http://shipitcon.com

Intercom has practiced Continuous Deployment since the very early days of the company. This has meant that our engineering culture and practices have evolved around, and heavily rely upon, our build and deployment infrastructure. With the rapid growth we’ve experienced over the last few years, maintaining and improving these systems has been critical to keeping our ability to move fast and iterate quickly. This talk will cover the evolution of Intercom’s internal deployment system, Muster, as our engineering organisation has grown from 4 people hacking on a Rails app to a team of almost 100 working on multiple applications in a constellation of languages and frameworks.

Transcript

1. How Intercom ships code to production 100 times a day Eugene Kenny Senior Engineer,
 Intercom
3. ¯\_(ツ)_/¯
4. 2013 2017 Engineers 10 100+ Applications 1 70 Languages 1 7
5. Deploys per day 0 12.5 25 37.5 50 2013 2014 2015 2016 2017
6. Deploys per day 0 17.5 35 52.5 70 2012 2013 2014 2015 2016 2017 Intercom Embercom
8. In the beginning • Intercom originally deployed to Heroku • Built Muster in 2012 • Based on experience with similar tools at previous companies @eugeneius
9. Getting up to speed • I joined Intercom in 2013, with no experience in continuous deployment • Came from a smaller company that deployed code manually • How hard could it be? @eugeneius
11. Every change is automatically deployed to production @eugeneius
12. The latest change is automatically deployed to production @eugeneius
13. The latest change that passed CI is automatically deployed to production @eugeneius
14. The latest change that passed CI is automatically deployed to production unless the pipeline is locked or rolled back @eugeneius
16. (we haven’t implemented any of this) @eugeneius
17. Build Deploy @eugeneius
19. In the beginning • Check out the code • Run: – bundle install – rake assets:precompile • @eugeneius
20. Additional languages • New Java service needed to be deployed • Taught Muster about different project types, configuration files… • Added complexity, but unblocked the team @eugeneius
21. Ruby upgrade problem • Upgrade different apps at different times • Use different version from Muster itself • Containers… Heroku? @eugeneius
24. Deploying frontend apps • Muster assumed the release would be deployed and run on EC2 instances • Doesn’t fit with frontend apps (Ember.js) • Implemented an S3 deployment target • Muster is now more complex (again!) @eugeneius
25. Muster used to deploy itself • Seemed awesome - dogfooding! • It was (sometimes) not awesome • Weird failure modes @eugeneius
27. Why not buy it? • Started in 2012, not many options • Broad responsibilities: build, deployment, infrastructure management… • Have tried to replace individual components, with mixed results @eugeneius
28. Story Time @eugeneius
30. Thank You! @ShipItCon #ShipItCon2017