Sébastien Barbieri's blog

Option 1

post commit auto deploy

In 4 steps

1. svn commit to the repository
2. the pre-commit hook will check the code with svnlook and will validate the commit message (based on regexp such has bug# …, text minimal size…)
3. the post-commit hook will try to connect to the ITT (Integration Team Testing) if you have the good acronym, I’ll update
4. once connected a script should be launched (and forgot &;) This script should:
   • Do a svn checkout locally so the code could be tested (in /var/www …). This method has several drawback: instability of the site while exporting, destruction of ITT generated file (if any)…
   • Do a svn checkout in a temporary directory (/export/<projectname>) and then use rsync to do a fast compare and copy changes only without deleting the existing, excluding the .svn folders
   • Do a svn export in a temporary directory (/tmp/<projectname>) and then use the same rsync than above but this time you don’t have to exclude the .svn

   The fastest is the second one (svn checkout -> /export/<projectname> + rsync – .svn folders)

Option 2

There is another alternative if you have space and sufficient right on your svn repository: the svn export/svn checkout is done locally and you use rsync to deploy the site on the ITT server.

Option 3

There is a third alternative if you have one more server (a synchro server) that will be used to store the svn export (at least the last one and maybe 2-3 version before) and that will take care of the rsync between one of its local checkout/export and the ITT server.

Conclusion

The last option has the big advantage of being a intermediate repository that can deploy any revision to any server … but that’s another paper.

I used the 3 options, and the first one (the simplest/cheapest) is very easy to maintain and to set up, so it’s a must have for team < 15 … bigger team may think about the other options but will have to put additional resources to design the whole deployment system.