I use svn (subversion code version control) in a very simple way, but it has become an essential tool for how I build, deploy and manage websites. If you aren’t using some sort of source control, you should be. If you are, but you are using it only as a source code backup, you might be interested to see one of the ways it can be used as an integral part of the workflow for building, deploying and managing website updates. I’m not going to go into svn commands, this is more of an overview of the process.
This is my typical workflow, based on a php/mysql website build, but the process is relevant to most technologies:-
Create a new project in your svn repo
This basically consists of making a new directory in the root of the repo. At this stage, an experienced svn user might suggest you create sub-directories for “trunk” and “branches”, but I don’t bother (yet). I have my svn repo hosted on a web server so it can be accessed over https, by any machine with web access and an svn client installed.
Check it out to your local machine
I always develop on my local machine, I will jump through hoops to make sure I have a portable, standalone development environment for what i’m working on. It’s ok to develop on a remote server, as long as you have your own “sandbox” to work in, where you won’t be treading on anyone’s toes or vice versa. I always set up local hostnames and virtual hosts on my machine, e.g. myproject.macbook.local to allow me to easily work on multiple sites on the same port no. on my laptop. Check the project out and set the working copy folder as the root of your local website. When i’ve subcontracted work in the past, I have insisted that freelancers set up a local development environment and work with svn, even if we aren’t collaborating – there’s no way that i’m going to accept the work as a zip file over email! Working this way means that I can periodically check out the project to my machine to see how they are getting on, rather than having to ask them.
Build your site
As you add files to the site, add and commit them to svn. If you need to rename or delete a file, use svn to do it, to stop it getting out of sync. If you are collaborating with someone else, do an svn update and commit frequently (in that order). This way if you get any conflicts you can resolve them more easily than if you leave it till the end of the day. I find in that scenario it often becomes a “race” to commit stuff frequently, so that the other person is more likely to have to resolve conflicts if any turn up!
Contextual config file
I want to be able to deploy an identical code base to the live (and test) server environment, so I use some “if” statements that look at the host name to selectively load variables such as database config and anything else site/server specific, depending on which environment the site is running on.
Checkout the project on the live/ test server
Firstly, this scenario will only work for you if you have terminal/ ssh/ remote desktop access to your server. If you only have ftp or sftp available, this technique won’t work for you. If that is the case then you may have to resort to uploading the files individually or in bulk – which is a massive pain compared to being able to run an svn checkout/ export/ update on the live server.
There is also some debate about whether deploying or managing the live codebase as an svn working copy is a good idea. I think it is for the following reasons:-
- Occasionally you may need to debug something on the live/ test server. e.g. if something behaves differently to your local environment, or some other edge case. In this scenario if you fix the bug on the live server you can commit it back to the repo and do an update on your local copy.
- If you are managing user contributed uploads and want to keep them in svn. You can then log in to the server occasionally and add/ commit these back to the repo.
- Keeping an eye on things. A while back I spotted that an old wordpress site I was hosting had been hacked. Simply by doing an svn stat on the root of the site, I could see that some files had been modified – that’s an edge case, but it’s a useful tool for getting quick feedback if anything has changed on the live server that you weren’t expecting.
One thing you will want to do if you manage the live site as a working copy is make sure your web server is configured not to serve up the .svn folders, or any other folders not part of the live site.
I always keep a mysql dump in the svn repo. This may or may not include data, depending on the size of the database, or the need to keep config data in the database. Once again this should be in a directory that is not served up by your webserver. For a first deployment, I will use a checkout of the mysql on the live server to create and populate the database. Thereafter, I use numbered migration scripts to manage any (structural) changes to the database, such as adding or altering tables. These are added/ commited to svn, then checked out on the live server to run and apply the changes to the live site.
Getting started with svn
If you are reading this and thinking “sounds good, but i’ve never used svn”. A good place to start would be to sign up for a free hosted svn repo with someone like beanstalk, and then try one of the many GUI svn clients. Rapid SVN is a good free one for most platforms, but there are tons out there. It will help to learn the basic commands, and be essential if you only have ssh access on your server. I said I wouldn’t go into commands here, but to put things in perspective, I get by with very few: svn co (checkout a project), svn add (add file(s) to project), svn commit (commit changes to file(s)), svn update (update the working copy with latest changes), svn resolved (mark a conflict as resolved), svn mv (rename a file and tell svn to sync on next commit), svn rm (delete a file and tell svn to sync on next commit) and finally svn revert (go back to the last revision, or a specified revision).
There’s more (but I don’t know it)
I’m fully aware that there are more sophisticated ways to use svn to manage and deploy projects, involving branches, merging, switching, externals and a whole load of other clever stuff that I have yet to become familiar with. However a simple project with checkouts/ commits and updates on local and live server works well for me, and is a good starting point to get stuck in and start to feel comfortable with it. Also, apparently all the cool kids have abandoned svn for git, which works in a similar, but different way, so that might be worth a look too, if you aren’t already familiar with svn.
You’ll never go back
I’ve been working this way for a few years now, but occasionally i’ll do some work for a company that don’t or won’t work use version control, or don’t use it as an integral part of the workflow (i.e. they just use it as a backup). Without version control as an integral part of the workflow, I have often had to resort to pen and paper to remember what files have changed, so I know what to upload, i’ve accidentally overwritten new code with old versions and mysteriously lost days of work when someone else does an update from their non-versioned working copy. The learning curve is worth it, and so is getting your head round how to resolve conflicts (usually the first thing that scares people away from svn).