SVN Deployment and a New Site
I recently got an email from a BarCamp friend, Mark Sailes, telling me about his new site http://www.svn-checkout.co.uk. I am a big fan of subversion and always looking for more tips and tricks for using it better so I popped over to have a look. Its a nice site with some very useful short articles on various subjects related to subverison. In particular the article on releasing new versions of sites caught my eye. Mark suggests use of a checked out version of code rather than an exported one, and using the switch command to upgrade to the next tagged version as needed. He completes the setup with an apache configuration trick to avoid any of the subversion information being served to the outside world. I’ve usually just exported new versions as needed but this trick is a definite alternative and the article itself guides the reader through each step of the way. Nice one Mark :)
Thank you very much for your generous review, I really enjoy working with Subversion. It has really happened the company I work for to control what we deliver to our customers.
I’m trying to write articles which cover the basic usage as well as more advanced subjects. So there should be something for everyone.
Thanks again,
Mark Sailes
The other advantage of checking out the live site is that sooner or later, your boss comes along and makes a change directly on the live site…
Regards,
Rob…
Mark: you’re most welcome, I’ll be following your future posts.
Rob: Is that the voice of experience I hear? I think we’ve all been in the position of having overwritten live changes when others don’t follow deployment process correctly (sometimes for good reason), you make a very valid point!
Yeah thats the great thing about doing releases straight out of svn, if changes are done outside the standard process they will simply get overwritten on the next release. And that developer will have to explain what happened to their work.
Even better if you have the site as a working copy and not an export, you can use the tortoise client icon overlay to spot nasty red files.
Awesome
Obviously we don’t want to be losing valuable work people have done. So I’d recommend taking a backup before doing a switch.
Maybe just a diff against the repository would suffice, this could then be reviewed to see if there was any code floating around needs to be put into the source repository.
Arguably blame such data loss could also be attributed to the person who came up with the procedure, rather than the person who didn’t follow it.
LornaJane,
How did you guess ?! :)
Regards,
Rob…
Mark – thanks for the site.
Lorna – thanks for pointing to it!
I wouldn’t be without SVN now. I’ve been using a working copy as the live dev version of a site we’re developing. Committing changes to the server and just leaving a hook to update the working copy is really useful. For the public site I still do an export though. It seems you never know when your changes to the Apache configuration are going to get wiped! A great philosopher once wrote, “Defence in depth is the key to a happier existence.”
Good point
GeoffSwift: I disagree with your point about whose “fault” such data loss is. Subverting procedure is not acceptable, and anyone who does it frankly deserves to get their stuff lost! There isn’t room in a professional environment for people to do their own thing.
Rob…: let’s call that a hunch :)
dotjay: I know I evangelised about SVN for ages but I’m really glad to hear how well it is working for you now. Thanks also for the philosophical quote!
“Subverting procedure is not acceptable, and anyone who does it frankly deserves to get their stuff lost!”
Whilst I agree in practice, when it’s the boss, it’s generally easier to ensure that the system can handle the way the boss does it.
Rob…
Maybe there should be a rsync type thing tied to the svn export command so it only handles changed files.
That way there is a double advantage to export in that it won’t have to export things that haven’t changed and you can preserve manually changed files.
So long as the boss accepts the blame for when their own work goes missing and doesn’t rip into subordinates who do the same. Leadership by example is a good maxim.
Or maybe train your boss better? I think I’ve been mostly fairly lucky with bosses so far, they have been fairly easy to knock into shape …
I don’t think they dare resist :)
I agree !
Rob…
I’m a big fan of a more tightly controlled live version of a site – not having anything go live unless it’s gone through SVN and probably some time on a staging server having others in the company bang on it for a while. Of course, there will always be emergencies, or tiny little edits like adding new users to to a .htpasswd file where pushing a new revision just isn’t worth it, but the next thing I do is add it to my local development copy of the site and get it checked in.
The last year has only really been me, but now I’ve got a couple other developers helping me, having strong procedures is even more important.
I’ve got my boss quite well trained on that score now – well, at least since I was out for the day and he had a temp developer editing live on the server to add a ‘simple button’ to a globally included template. I found out about that one when I got the txt alert – ‘site is down’. Oops.
I’m planning to write up on my Livejournal how I use SVN exports and symlinks to go from one version to another – and back, if required.
OTOH, Maybe I’m just a control freak :)
>I’ve got my boss quite well trained on that score now – well,
>at least since I was out for the day and he had a temp
>developer editing live on the server to add a ‘simple button’
>to a globally included template. I found out about that one
>when I got the txt alert – ‘site is down’. Oops.
That’s exactly why I have a “proper” checkout of the code on the live site. I’m’ glad that these sort of things don’t just happen to me!
Regards,
Rob…
The trouble was he didn’t plan it, or test it – just tried to put it live. If it had been tested and put in svn for the next push – it would have been a non-event. Taking shortcuts is a bad move 99% of the time.
btw – I posted my write-up of exporting and symlinking – at the homepage URL.