How to release new versions of Websites
Just to make it clear, this post is mainly focused at script based websites such as php/asp/perl. Not complied code like Java .ear files.
Ok, so you have your latest and greatest website committed to your repository. You’ve developed it with love and attention, and you want to make it Live for the world to see. This post is about a structured process about how to release new versions of your code to the world, once they’ve been checked in your development environment.
Version Numbers
A whole blog post could be made about version numbers, but I’ll leave that for another day.
For most websites a simple X.Y.Z is fine. Denoting Major Version, Minor Version and Bug Fix.
Creating a Tag
So you with have your code in a path such as this
/test-website/trunk
We now want to create a snapshot of this code at this specific point in time. Subversion calls this Tagging, using TortoiseSVN you would right click the trunk and select “Copy to…”
We want to save this, our first version as 1.0.0 and we want to save it to the tags folder.
Or using the cmd line SVN client
svn copy https://numbers:8443/svn/test/test-website/trunk https://numbers:8443/svn/test/test-website/tags/1.0.0 -m "Tag for version 1.0.0"
/test-website/tags/1.0.0

This creates us an absolute reference of the code at this point in time (no edits should be made to code under the tags folder, and be made read-only if possible).
Releasing the Code
Once we have the tag, we now want to publish it to our Live/Production environment. Whether this is a shared hosting server or a large cluster the process is the same.
We now do an svn checkout from our tag to our website folder.
svn checkout <repo_url> <path_to_working_copy> svn checkout https://numbers:8443/svn/test/test-website/trunk site A D:\Test\site/index.html
We specifically do a svn checkout and not an export because we want a working copy on our server. The reason behind this becomes clear as we release new version to the server.
We now have a working copy of version 1.0.0 checked out to our web server. If we were to find a bug in the website and have to make an update to the site, we would make the changes to the code. Commit them to the repository, tag the code again using 1.0.1.
svn copy https://numbers:8443/svn/test/test-website/trunk https://numbers:8443/svn/test/test-website/tags/1.0.1 -m "Bug fix version 1.0.1"
Now we want to release tag 1.0.1, we do this by doing a svn switch. This updates our current working directory to the url pass it, which in this case will be the new 1.0.1 bug fix tag.
svn switch https://numbers:8443/svn/test/test-website/tags/1.0.1 site U site/index.html
We cannot do a svn switch if we only do an export of our code to the server. By using svn switch instead we vastly reduce the time it takes to do the release, as subversion only updates the files which have changed. Using an export we would have delete the current version and export the new version.
Remember to block access to the .svn folders on your web server
<Directory ~ "\.svn"> Order allow,deny Deny from all </Directory>
or
RedirectMatch 404 /\.svn(/|$)
About this entry
You’re currently reading “How to release new versions of Websites,” an entry on Svn-Checkout.co.uk
- Published:
- 19.01.08 / 5pm
- Category:
- release management, subversion
4 Comments
Jump to comment form | comments rss [?] | trackback uri [?]