At LinkedIn, it’s almost entirely automated. “Humans have largely been removed from the process,” Scott says. “Humans slow you down.”
It encourages learning and teams that deploy it get faster over time
This is a little older post from Eric Ries from June 2009, but with lots of good stuff in it.
The goal of continuous deployment is to help development teams drive waste out of their process by simultaneously reducing the batch size and increasing the tempo of their work.
Great idea to split database deployments in 2 steps.
- expansion scripts
- contraction scripts (cleanup)
The expansion scripts are run at some point prior to upgrading the application and the contraction scripts are run once the system has been upgraded and considered stable. This produces a nice benefit of decoupling database migrations from application deployments. The expansion scripts could be run a day or more in advance of the application deployment at a time that is convenient for database changes. The contraction scripts could be run potentially days after the deployment once everything has been validated with the new release.
Interesting facts about Facebooks code:
- 1 binary
- 1.5GB in size
- PHP into heavily optimized C++ code
- Rollout takes ~ 30min
- minor updates every single business day
- Deployment doesn’t need scheduled downtime or cause any other disruption to the website
MS catching up with appHarbor!
Dev checks in code, and afterwards your change is visible on your Azure website.
I wonder how that new build template looks like
Deploying a previous version was never so easy!!! #appharbor
This reminds me to the old times with TFS/msbuild/msdeploy where I had to jump through some hoops in order to deploy a previous version… (Powershell scripts)