At webgains we’re finally making the move from CVS to Subversion now and it seems to have a whole lot of benefits with it – cheap (time and space) branching is by far the biggest improvement – suddenly merging branches doesn’t seem like such a daunting task anymore. This move comes at a time when we’re preparing the system for internationalisation, so having a smoother version control (and with it, better deployment management) is going to be a big help.
There are a number of things you can do with your version control to make sure that your teams development and deployment goes as smoothly as possible:
Keep a stable release branch, and work on an unstable trunk
If your developers can commit to the trunk, without fear of messing up the live system, then they will be able to commit more often. If they can commit more often thier work is backed up to the repository, and the team will have to deal with less conflicts. If you have a stable build of the site/software on a branch, then you can merge the selected changes to it in order to do a release, rather than upload the bleeding edge trunk straight to the live system.
Have a staging ‘test’ area to test a release before it is put on the stable branch.
This means keeping a copy of your software or site somewhere that people dont make changes to – its not a sandbox development area, its a test environment as close as you can get to the live system where you can test and benchmark your stuff before the code goes live.
Review code before it is commited to the testing branch
Once the code is in a testing or live environment, its too late to refactor or rewrite code, so a code review isn’t all that useful here. Review _before_ it is merged to the live or testing branch, because this is the best opportunity you have before its sitting on a live website being tested for real. Dont look at code reviews as a huge formal organisational administrative thing that you’d love to have the time in your team to do – it doesn’t need to be more than another developer looking through the code, making some notes and informally talking through it with the coder.
Have a release number
It can seem strange to have release numbers for an in house website or other similar projects, where there is no distributed application, and it can be difficult to apply some of the principles of software engineering to a project like that – it tends to grow organically and features and bugs are introduced on an ad hoc basis. This isn’t always a bad thing, but the bigger your project becomes, and the more developers you have working on it – the harder it will be to manage well. Having a release or version number makes a website build/maintanance seem a bit more like a software development – and makes it easier to see how to apply software engineering principles (like version control, code reviews, unit testing and software modelling) to your project.
Obviously these all take a bit of dicipline and hard work, but thats what being a good developer is all about.
[...] My final PHP tool is written in Python. Trac is just about the best issue tracking/wiki/project management/repository browsing tool availiable. If you havent moved to Subversion yet – then Horde’s Chora project is an acceptable repository browser, but doesn’t have half the neat stuff trac has. [...]