Help me manage changes to a website
August 7, 2009 10:33 AM Subscribe
Whats the best way to set up version control for a website?
I work for a small building supply company, and we have a custom online store which was developed by an outside consultant. He used to provide a 'development' site where we could make changes, which we would submit through subversion, and which would be reflected when we browsed to the development site.
He is no longer providing this service. I've set up a separate hosting account with dreamhost, since they provide subversion repositories as part of their package. I can upload our code to this hosting account and it works, and I can set up a subversion repository, but I can't get subversion on a 'live' site.
Can anyone provide pointers on how to get what I'm trying to do working, or suggest an alternative approach?
I work for a small building supply company, and we have a custom online store which was developed by an outside consultant. He used to provide a 'development' site where we could make changes, which we would submit through subversion, and which would be reflected when we browsed to the development site.
He is no longer providing this service. I've set up a separate hosting account with dreamhost, since they provide subversion repositories as part of their package. I can upload our code to this hosting account and it works, and I can set up a subversion repository, but I can't get subversion on a 'live' site.
Can anyone provide pointers on how to get what I'm trying to do working, or suggest an alternative approach?
If you can manage, I would switch to git as soon as possible. It is much more reliable (and faster).
I would also suggest investigating git, but not for reliability reasons -- I use Subversion regularly in a production environment and I have never had any data loss or corruption since they moved away from BerkeleyDB storage many years ago.
The best reason for moving to git -- or any of a number of other version control systems with a distributed model (bzr, mercurial) -- is that they allow you to commit changes to a *local* repository, while only updating your production website when you're comfortable that all the changes are working and stable. So you get a complete revision history and the ability to revert changes at a very granular level while at the same time you can be sure that your website is always functional.
You may be able to achieve the same sort of thing with Subversion and branches, but it's by no means as simple or effective.
posted by larsks at 11:41 AM on August 7, 2009
I would also suggest investigating git, but not for reliability reasons -- I use Subversion regularly in a production environment and I have never had any data loss or corruption since they moved away from BerkeleyDB storage many years ago.
The best reason for moving to git -- or any of a number of other version control systems with a distributed model (bzr, mercurial) -- is that they allow you to commit changes to a *local* repository, while only updating your production website when you're comfortable that all the changes are working and stable. So you get a complete revision history and the ability to revert changes at a very granular level while at the same time you can be sure that your website is always functional.
You may be able to achieve the same sort of thing with Subversion and branches, but it's by no means as simple or effective.
posted by larsks at 11:41 AM on August 7, 2009
I agree with jrockway, that Subversion can end up being a pain. I prefer Mercurial over Git but, of course, that's a personal preference thing. Just throwing out another option.
You can either use the copy/move/linked/updated method as described by him or find some kind of "continuous integration" method (Apache Continuum?) ... although that does seem overkill unless you're doing actual builds (e.g. with something like Maven)
I also agree developing locally is a little better for this kind of thing. It's either that or some kind of content management system that has plugins for an online store (and thus all the tedious work that goes along with it.)
Good luck with whatever you end up doing.
posted by jlstitt at 11:47 AM on August 7, 2009
You can either use the copy/move/linked/updated method as described by him or find some kind of "continuous integration" method (Apache Continuum?) ... although that does seem overkill unless you're doing actual builds (e.g. with something like Maven)
I also agree developing locally is a little better for this kind of thing. It's either that or some kind of content management system that has plugins for an online store (and thus all the tedious work that goes along with it.)
Good luck with whatever you end up doing.
posted by jlstitt at 11:47 AM on August 7, 2009
I would recommend using something like Capistrano (or Vlad the Deployer). When you type a command such as 'cap deploy' they'll automatically check out the latest code from Subversion and deploy it to the live site. If anything goes wrong mid-deploy they'll put back the original site, or you can type 'cap rollback' and the previous site is restored. Capistrano is focused on deploying Ruby applications but can be used for plain HTML or PHP sites too.
They'll take a bit of time to set up but the end result is worth it.
posted by BinaryApe at 6:59 AM on August 9, 2009
They'll take a bit of time to set up but the end result is worth it.
posted by BinaryApe at 6:59 AM on August 9, 2009
This thread is closed to new comments.
* * * * * sh -c 'cd /var/www/your-site; svn update' 2>&1 >/tmp/svn-up-log
We do this for a few sites, and it works. But is a horrible idea. Developing locally and committing when your changes actually work is the best strategy. This is really easy to do in most cases; be it Perl, PHP, J2EE, whatever.
Also, svn likes to break in horribly strange ways. If you can manage, I would switch to git as soon as possible. It is much more reliable (and faster).
posted by jrockway at 10:38 AM on August 7, 2009