Subversion Webdesign Workflow

Hi everyone,    I have been looking into subversion for quite some time and finally decided to go for it.  Im on a small webdesign team, and our setup would be something like:    - 1 Internal server for hosting repos and local websites (Windows)  - Several workstations both mac and windows  - 3 webservers (linux)    What i imagined was something like:  - Each developer/designer has a working copy for every site he/she colaborates  - After every commit, the internal server deploys that version on the internal webserver for testing  - If everything ok, some procedure will then push the local version to the corresponding webserver    I've read many many things on the web about this but i've failed to implement this on our work environment.    At this point im hoping that someone around here can point me some directions to explore solutions for this.    Thanks,  Luis

Last updated 13 years ago

1 & 2 are dead-on. For #2, see http://subversion.tigris.org/faq.html#website-auto-update    For #3, you really want this to be a process which is manually triggered by someone - an intentional action.    If you describe exactly where you're having trouble, folks might be able to help more.

Thanks Andyl, i've already seen that link and others similar. Not sure if understand it correctly but i guess i have to try.    About that step3.  I was planning to have have checkouts for both staging and live websites. In most workflows that seems to be the case. An export from the staging to live doesnt seem to be feasible because it will force to upload the entire site on every update right?    I've also found some interesting automation scripts, like webistrano or Fabric:  http://nicksergeant.com/blog/programming/developing-and-deploying-applications-fabric-and-subversion    But since im just starting all those commands are bit confusing, small steps then.    Anyway, if someone knows good tutorials on this subject please share, at this point im consuming everything i find :-)    Thanks again.

Hi Luis    If it were me, I'd have a commit force an update on the staging website, but NOT on the live website. I'd want a manual step between deploying to staging and deploying to live - something like "OK, staging is at revision 1234, and looks great. I'm satisfied that it's safe to deploy to the live server, so I'll manually do an export (using revision 1234) from Subversion to the live server". I wouldn't want every single commit to hit the live server, as I'm bound to make a commit in error, sooner or later... ;-)    Cheers  John

Thanks John,    Yep, that really sounds like the reasonable thing to do. My problem with the export is that in every sync to the live server it will be sending everything right? I mean, if i go to the live server trough FTP since the exported file are all new everything will be sent.    I was looking into Fabric or Webistrano for deployment. My goal was local updates automatic as you say, but remote updates (live server) only by specific instruction. Couldn't get around Fabric so far, as for Webistrano i havent had the time to test it.    I was hoping someone here with experience in this workflow could point out some directions.    Thanks  Luis Martins

Hi Luis    It's been a while since I last did website deploys, but yes, you're right that export will export everything. Typically I'd export the live site to a new directory, then update a symbolic link ("/var/www") to pint to the exported site - that minimises downtime for the site.    I looked at Webistrano a while ago; I can't recall if it would automate this step, but it did seem fairly feature-rich - might be worth taking a closer look.    Cheers  John

I think you need to manage your team first before implementing the computerized set-up. Collaboration on one website needs constant communication. Also, you haven't mentioned if your team are working home-base or not. Landing Page Optimization

Hi    That's right: the export approach will result in all files being FTPd. You need to balance the security this gives you against the bandwidth/time costs - and the resultant costs incurred if you were to take the other approach and miss out a few files. My view is that bandwidth is cheap; my time isn't!    Cheers  John