Alot of our clients tend to ask how we would manage sites across multiple servers or how we would maintain the code on the live site to make sure it is identical to the development environment. For our purposes, svn has served us very well and that is our general practice here for all our projects. Personally I find the interfaces (both gui and command line) to be quite intuitive. It is an invaluable tool in our development process and makes the job much easier, especially when clients request multiple deployments of the same site over different servers. The trick is maintaining the Drupal database but that in itself is a whole other post.
Installing svn on DEB based servers (ubuntu, Debian) uses this command
apt-get install subversion
while redhat servers use
yum install subversion
and the command to create the repository is simply
svnadmin create repository_name
you will find a list of commands by typing in svn help if you are using command line or you can download an svn client(windows users) if you are more comfortable with a User Interface approach. Tortoise is a popular client and one that we use here. All that is left at this point is enabling the user privileges which is largely dependent on the amount of security you have on your server. You will have to allow certain users to checkout of the repository as well as check in, both of which are generally done over ssh, which is the most secure protocol available.
As a general practice, we include the entire drupal installation minus the "files" folder and "settings.php" file which both have to be maintained/moved/created manually
I do not have experience with cvs so if it out performs svn an any way, I would be interested to know how.
Comments
For handling database changes I have found its best to have a custom module. I keep one on every larger site I manage and put the changes into hook_update_n. If the changes are rather large then I'll end up using batchapi for it. A great tool to help detect differences is mysqldiff. If there are enough changes I'll save them to a text file and have my custom module install the changes through batch_api from the text file.
On the file system I'll keep any items I need in svn and ignore the rest. Keeping a good directory structure is key to this. Another alternative is to use rsync to manage the file system.
On one large site I manage that has a couple of webservers I actually keep the svn checkout in a folder outside of the document root. I then have a shell script that will rsync the changes from the folder over to each webserver, while maintaining the proper file permissions. I've been doing this practice for a couple of years now and it works extremely well.
Hi, it's a nice article. SVN is a sure thing to do this. But what's bothering me lately is how to keep development environment up-to-date with live site, especially database and what to do with stuff that need to be set-up directly on production instance, like SEO. Any tips ? David
Couple of issues I wish would be addressed with SVN. Is the ability to completely remove an item (say a large database dump) completely from all subversion history. And, the ability to exclude a directory from the initial 'svn add', rather than doing an 'svn ignore' after doing the initial checkout.
Other than that, I think SVN is great. Nice writeup. Might be worth mentioning the 3 other common commands. 'svn add, svn commit -m, svn diff'
I use SVN too in my daily Drupal work. It's an invaluable tool: saves time and makes maintaining different Drupal installation such a joy.
Indeed, maintaining the database is a problem albeit one which can be solved.
The files folder is a different issue as it contains all the client/user uploaded data. It's a space in your installation which doesn't really fit in svn: it's not code or something you control. So this needs a different backup/maintenance approach. I'm thinking along the lines of a cron based module that stores a backup of the data to a safe location, perhaps somewhere in the cloud (EC2?).
Thanks for the tips Jamie :-).
I second Jamie's suggestion of coupling svn with rsync. I used to run a web site for a group that was very sensitive to the threat of web site defacement. I built the site to rsync all static files from a known-good source into the web root every 10 minutes. Even if someone was able to find a vulnerability in our regularly patched and updated system, your average site defacement wouldn't last very long.
I agree that user files and database information (don't forget schema changes either!) are all things that revision control systems weren't really built to handle. With enough storage, you could put both in svn or git though. And with git's idea of distributed version control (I admittedly haven't used git), you could do a very nice backup and restore that way.
I urge you to look at git - all these problems are handled very easily.
Thanks for all the great feedback guys, I think rsync shows plenty of promise and we will definitely look into that.
Drupal platform am using now,but I don't have much idea about it,thanks for sharing the above information.
Post new comment