Continuous Deployment Setup at 2morethin.gs

What about serious bugs? I think many people eyeing with continuous deployment shy back because the rollback might be too hard or difficult.

From what I’ve read elsewhere, people use an “immune system” (nice metaphor) to reject faulty builds from production.

It is an interesting research question to me just how that immune system could work. Ties nicely with some old work on biological framings of problems in computing and the Ultra-Large-Scale systems folks.

Dirk

Why don’t you just let the hook trigger deploy your application? You probably need root for the deployment (especially starting and stopping tomcat) so you created the cronjob workaround, but IMHO using “setuid” on your trigger is a much cleaner solution.

Next step is building a real(TM) Deployment Pipeline, with Smoketests triggering Unit Tests triggering Acceptance Tests, triggering promoted builds triggering Testers triggering Deployment ?

I’m looking forward to reading http://continuousdelivery.com/ in the late summer ..

I wonder how do you deal with database schema upgrade? Do you run special shell scripts in this case?

So, how do you prevent a developer from committing something which breaks your production setup? Is automated testing, with only a deploy on success, not a minimum requirement?

I know one can test locally, but I frequently see cases where the same tests then fail on a continuous integration box because the environment was slightly different.

At kaChing we have sub 5 minutes commit to release. Since cron job is at least once a minute you loose in average 30 sec on deployment. Therefore we use a post commit hook to start the testing (hudson) -> deployment -> monitoring/rollback process. You can easily start a hudson job from post hook commit.

Interesting post. Did you consider ‘Hudson’ as your CI server to trigger deployments instead of running a cronjob to check for a file? I found the idea of using an HAproxy to skip servers while down very interesting. I imagine to tacke your deployments in stages (so at least one server is up). WIll be interested in seeing how u do rollbacks in this type of setup.

I like the idea of deploying to a new server and adding pointers to HAproxy for both the old and new servers. Rollback then becomes just reverting a pointer back (or keep both pointers) until is decided that new deployment is safe and older deployment can be deprecated. Of course this is easier to do in a cloud environment (think EC2).

Interesting. I just discussed CD with a colleague and stated that I believe you can develop any site with CD. I’m curious about your progress with automated tests for smoke tests, junits and UI testing.

I’m with you on the “serious bugs need more test coverage”. And I think you have to keep in mind that you’ll develop in small steps too, so it’s harder to introduce a hidden bug that will break everything else. Having a good coverage on the code will help to find bugs even before starting the automated tests in the CD process.

Hope this post gets a 2nd part soon. ;-)

Varnish can do backend healthchecking (if configured to do so) so no need for extra proxy layer (HAProxy).

[...] blueprint for each table and then create as many different objects as you need in your PHP code. Code Monkeyism: Continuous Deployment Setup at 2morethin.gs Wie ein Continous Deployment Setup aussehen kann am beispiel von 2morethin.gs Writing Tests First [...]

[...] Stephan Schmidt’s post and a diagram of his infrastructure: http://codemonkeyism.com/continuous-deployment-setup-2morethings/ [...]