Monday, February 4. 2008
SVN Deployment and a New Site
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.
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."
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’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.
