As Jedi

• phpunit and code coverage
• phing deployment
• svn and continuous integration

As Padawan

• Working agile
• Scrum

Now let’s decide a timeline

first of all you need the best script ever made to backup subversion: the one provided with!

Get it here: http://svn.apache.org/repos/asf/subversion/trunk/tools/backup/hot-backup.py.in

This script needs to be modified

replace:


# Path to svnlook utility
svnlook = r"@SVN_BINDIR@/svnlook"
# Path to svnadmin utility
svnadmin = r"@SVN_BINDIR@/svnadmin"


with:


# Path to svnlook utility
svnlook = r"/usr/bin/svnlook"
# Path to svnadmin utility
svnadmin = r"/usr/bin/svnadmin"


or your appropriate svnlook and svnadmin path

Then you need to check that your user can modify files

once it’s verified let’s create a repository to store backup ‘/backup’ for instance and create your directory structure there

Test it

test the whole stuff

./hot-backup.py --archive-type=bz2 --num-backups=45 /svn/TEST_REPO/ /backup/subversion/test_repo/


you should get something like TEST_REPO-2.tar.bz2 (here minus 2 means revision n°2)

Schedule it

If you want to run it daily, put it in a cron such as a daily job

As I have multiple repositories here is my script


#!/bin/bash
NUMBACKUP=15
for i in `ls /svn/`
do
mkdir -p /backup/svn/$i
./hot-backup.py --archive-type=bz2 --num-backups=$NUMBACKUP /svn/$i /backup/svn/$i
done


Restore it

Ok that’s nice, you got a backup, but unless you can restore it, it’s useless!

So here is how to restore it:

1. tar -xjvf /backup/svn/TEST/test-2.tar.bz2
2. cp -R /backup/svn/TEST/TEST-2/ /svn/TEST/

and… that’s it

of course at the end of your backup script I recommend to move everything to another computer, because you will probably need it when disk crashes ;-)

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.