Continuous deployment in 5 easy steps(radar.oreilly.com)
radar.oreilly.com
Continuous deployment in 5 easy steps
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html
4 comments
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)?
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)?
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.
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.
Two options to deal with the "scary" part of big integrations in continuous deployment:
Don't. Commit early, often and in small chunks. Just search for Continuous Integration, more than enough has been said on it already.
When you must, roll out features independently of the code being live in production. This means things like using control logic to roll out the code to portions of users, intelligently. We roll out via: on/off switches (mitigate total failure), A/B tests (mitigate poor performance in front of customers), QA-rollout (mitigate bad experiences for customers), etc. Lots of flexibility here, including hidden rollouts: running the code without showing the results to users, so you can figure out scalability impacts.
Don't. Commit early, often and in small chunks. Just search for Continuous Integration, more than enough has been said on it already.
When you must, roll out features independently of the code being live in production. This means things like using control logic to roll out the code to portions of users, intelligently. We roll out via: on/off switches (mitigate total failure), A/B tests (mitigate poor performance in front of customers), QA-rollout (mitigate bad experiences for customers), etc. Lots of flexibility here, including hidden rollouts: running the code without showing the results to users, so you can figure out scalability impacts.
Continuous Deployment at IMVU: Doing the impossible fifty times a day. http://news.ycombinator.com/item?id=475017