

Continuous deployment in 5 easy steps - TimothyFitz
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html

======
smanek
I like the idea of automatically doing a full compile and running all unit
tests after every commit (assuming your code base is small enough to make it
feasible). But, it seems a little crazy to automatically deploy commits to
production.

I sometimes have merged a large feature into the repo's trunk (thousands of
lines of code) - and it seems a bit scary to automatically deploy something
that large into production (even with adequate testing). Although, I would
like deploying onto a test server/vm automatically.

In my experience, changes to the production service have always been manual.
Has anyone ever tried having commits automatically deploy to production (when
they pass unit tests)?

~~~
arebop
Yes, I've had good luck with branches for trunk, qc, and production. The
production branch is always a copy of qc as it existed at some point in the
past, so that guarantees that everything's been tested together and without
anything extra.

Beyond the benefits of just automating deployment (independent of source
control and continuous integration), it's convenient to use source control as
a historical record about the state of the production systems, and it's good
not to have to remember rarely-used combinations of parameter values in
deployment scripts.

------
listic
A more practical article was already posted on this topic:

Continuous Deployment at IMVU: Doing the impossible fifty times a day.
<http://news.ycombinator.com/item?id=475017>

