Towards Continuous Delivery at SoundCloud
Vitor PellegrinoSoundCloud
> 11 hours of audio uploaded every minute
~ 300 million people every month
how it all started
➜ ~ rails soundcloud
sometime in 2007
SoundCloud, circa 2011
“Organizations produce systems whose design is a copy of the structure of the
organization”
Melvin Conway (1968)
(really) not a free lunch
tl;dr
• Rapid provisioning• Basic Monitoring• Rapid application deployment
http://bit.ly/sc-microservices
how long it would take to deliver a one line
change line in a project?
Idea-> Development -> Review -> Deployment
Value added time
Elapsed time
idea dev review deploy
1 day
2 weeks
10 minutes
1 week
5 minutes
one line change
Continuous Delivery
why is this so important?
compile package Testing Deploy
Quick feedback through automated tests
Late feedback and manual tests
instead of
Test automation using isolated environments
Testing in production
instead of
Deployment automation
Manual deployments
instead of
Build pipelines to orchestrate test and
deployment
Tribal knowledge and manual builds
instead of
Isolated and reliable production environments
Unstable production environments
instead of
Continuous Delivery collective
Continuous Delivery collective team
> git
SquashFS
> make
unit tests integration tests
acceptance tests perf tests
> make
/dev/null
> make > gitunit tests integration tests
unit tests integration tests
acceptance tests perf tests
what about infrastructure?
infrastructure should be excersized as part of
the pipeline
and it should be driven by a pipeline too
Compromise on implementation, never
on the vision
We iterated. A lot.
do the simplest thing that may work
driving SoundCloud towards this change
Continuous Integration
Trunk based development
Integration testing
e9t (aka environment)
Understand your workflow
be ready to show people the way
it is a long and exciting journey