Using Sub Version For Your Release Management

In this post I will outline the basic workflow for anyone who intends to use subversion in order to manage the different releases of their site. Now this post is not intended only for wordpress audience, but actually it is intended as a general purpose work flow for anyone who want to keep different releases separate. There are a few tid-bits that will be helpful for bloggers though.

First off all subversion is an excellent version control system. Most people use it in a team environment to keep separate working copies for each team member so that each member can work on their own copy and periodically commit the changes to a central code repository. However one of the great advantage for version control in general and subversion in particular is that you can very easily retract to a certain point in your code, even if you dont have a team environment and work as a solo player. This will be helpful when you want see how your application was performing at a certain point. The purpose could be to find some issue, to replicate some bug or to get to the most stable release of your application.

Creating Subversion Repository

Before we begin we need to be able to set up a repository for subversion. I can do this using the following command line.

svnadmin create /opt/www/myrepositories.com/repos/mywordpressblog

Since we intend to use apache to access our svn repositories, we need apache to be able to read and write to this repo

This can be done by issuing.

chown -R apache:apache /opt/www/myrepositories.com/repos/mywordpressblog

This creates a number of different directories that subversion will use internally to hold your managed code. In order to put your code in that repository for the first time, you will need to import the code. Before we do that we would want to set up a directory structure that will be helpful for our release management process.

Directory Structure

I would set up my directories the following way.

myproject
|— trunk <--- this will contain my existing code
|--- branches
|--- tags

Once I have created the above directories, I will copy my current code to the folder named trunk. trunk is traditionally the main branch of code that contains anything you are really working on. Though you can keep your working code in any other directory, but trunk is traditionally the place to be.

Keeping Application Code Separate From Content

Before I import all the above to my svn repository, it is important to take a moment and think about what should really be kept inside your repository. Ideally you should design your application in such a way that you only keep the code inside the repository. Any other contents that is uploaded by the user should be kept outside.

Database Connection Parameter

Also the application should keep the database connection parameters outside the code repository by including a file from a path that is beyond svn control. In reference to WordPress, you can edit wp-config.php to include a file say /etc/myproject/my-dbparam.php. In this case my-dbparam will define DB_USER , DB_PASSWORD and DB_HOST as well as any other constant that varies for different configuration. The file does not have to be in /etc/ , it can be anywhere outside the document root, to keep it secure, and readable by web server.

The real benefit of this will show up when you have some QA personnel who would use a different database. The whole application will be released to them and they can independently test the application without changing anything in the application. Same goes for the time of release. Your release engineer will just need to export the code from svn and ready to go. We will touch how to release your application a little later.

Uploaded Files

So Uploaded files are also a major chunk of your WordPress Application, but if these are part of your svn repository it will be a mess to release an application. Reason is that these uploaded files will be released every time you export your code, which is not what you would want. One way to work around is to use svn:ignore property at directory level . However, that will still be a little messy when you want to switch versions and release new code. Here is a more elegant solution.

Move your uploads directory above trunk level. and create a symbolic link to it from its original location. You can do this after running the following command so that uploads directory is not imported with rest of the code.

cd myproject
svn import . https://myrepositories.com/repos/mywordpressblog -m ‘Initial import’

Once the code is imported, you should create uploads directory just above trunk and create a symbolic link to it from where it will actually be used.

mkdir uploads
ln -s ./uploads trunk/wp-content/uploads

Creating Tags

Now your application has everything setup except that Apache needs to know where it is. I would suggest that your application should have a production directory structure like the following under /var/www/myproject

|— uploads
|— current <--- this should be a symbolic link pointing to release_1.0.0
|--- release_1.0.0

Your apache config should point to /var/www/myproject/current as the DocumentRoot. This will allow using a different version just by changing a symlink without restarting apache.

Once the development environment code is stable, you can mark that code as stable [or prod or qa]. The way to do it is the following.

svn copy https://myrepositories.com/repos/mywordpressblog/trunk https://myrepositories.com/repos/mywordpressblog/tags/release-1.0.1 -m "1.0.0 is now stable."

Releasing the Stable Code

Having this setup, releasing the stable code to production is very simple.

cd /var/www/myproject
svn export https://myrepositories.com/repos/mywordpressblog/tags/release-1.0.1 release-1.0.1
unlink current
ln -s release-1.0.3 current

Thats it. Since the uplaod and database connections are already separated, the code will work like a charm. Plus you can switch back to any other release by pointing ‘current’ to that release .

Just in case you are wondering about how to work through subversion , I have a svn command reference for you or you might want to download a pdf .

Browse more posts marked in:release mangement subversion svn