Properly using SVN & CI

Question

I am setting up the development environment for my start-up just now. I use Hudson for continuous integration of source code. It polls the SVN repository for changes every 10 minutes and if there are any deploys them to the LIVE servers from our DEV servers.

What I would like though is to have another Hudson job which deploys from DEV to TEST. I want to be able to commit code to SVN and then manually deploy to TEST, do a manual QA check and then it to be transferred to LIVE.

Is there a way I can do this with branches and the trunks in SVN? I would like it to still poll every 10 minutes as there are plenty of occasions when it should go straight from DEV to LIVE. I thought maybe I could commit to a branch then have hudson automate the deployment to TEST and then if it works out fine commit the branch to the trunk. Am I right??

Thanks in advance

Answer 1

What we do using TeamCity is to build and then check in the binaries to a separate BINARY SVN for TEST using SVN LOAD_DIRS. Deploy those bits to TEST servers. If they look good, fire off another CI task manually that uses SVN LOAD_DIRS a second time to copy the bits over to a PRODUCTION SVN repository and then deploy those bits to production.

The advantage of this is that you have a copy of the exact bits you deployed to each server and can roll back easily, or can check out any specific version (say, last friday's) and test against that. You can also make changes to configuration files in the binary version and deploy those to production whilst still having a track record of who changed what, and when they did it.

This also gives you a deployment system with atomic properties - i.e. you get all or nothing when you try to update your servers to the new version, and never a partial / failed deployment.

Another advantage is that you can surgically replace individual content files in production with the latest version by checking out just those individual changed files - a handy feature at 4PM on Friday when you'd rather not risk a full deployment just in case some other change sneaked in to the binaries.

I can't see a scenario where we would ever want a direct deployment to LIVE - sounds risky.

Answer 2

I don't understand why you want a separate test step if there are still "plenty of occasions when it should go straight from DEV to LIVE" - which, as @Hightechrider says, sounds risky. The way I would do it is:

• Have Hudson detect changes every 10 minutes and deploy to TEST
• Carry out your manual testing
• Write another Hudson job which deploys the SVN revision you just tested from TEST to LIVE based on a trigger, for example sending an email to your Hudson server, if the tests pass (see the Hudson Wiki for details)

If your manual tests fail in step 2, I'm assuming you'll want to have your developers fix the code and repeat steps 1 and 2 before deploying to production.

I'm wondering if we're misunderstanding your scenario - if so, please add some more details on why you sometimes want to deploy to TEST and other times straight to LIVE.