This post has stemmed from an e-mail by Simon Hamp whom has just started working for a PHP development team and has been given the task of assessing their current systems. Simon writes:
I wanted a professional opinion on a proposal I have made to move from file-based version control (i.e. manual folder management) to full-blown source code management.
Is it worth making the change from an existing system and move to something like Subversion for a team of our size, considering that this would change the processes for those who have been here the longest quite considerably?
Version control is one of those things that you already know you should be using, and if you’re like me, have promised yourself for a while that you’ll get round to learning and integrating into your own workflow. Chances are that one day, disaster will strike and you’ll realise why it’s so important.
I’m going to be honest with you here, I can’t profess to be an expert in version control. I’ve been playing around with it, and the team I work with are very close to making it a mandatory part of our design and development workflow, but I hope i can provide some form of assistance in your decision to adopt a version control system, and maybe convince myself in the process.
That being said, I don’t think there even is a decision to be made. You – need – version control. There’s no real question about it. The biggest challenge we face is integrating this into our existing workflows.
Let me take a step back, and explain what version control is for anyone unfamiliar with the concept.
Version Control Systems (VCS) (also known as Revision Control, Source Control or Code Management) is a way of managing multiple versions of the same information, which is most likely – in this case – the source code of your website.
In the simplest terms, VCS allows you to keep track of the development of your source code, keeping track of the changes you make as you go along with all the changes being stored in a repository. You may already use a crude method of version control yourself, naming files such as index1, index2 etc. VCS systems keep track of all these changes, and let you revert to any previous version if the need arises.
The real benefit of VCS comes when you have more than one person working on the same file. Instead of you overwriting each other’s changes, or attempting to manually merge the changes from one developer with the changes of another, the VCS can take care of all this for you, creating branches for each developer to work on which allows multiple developers to work on the same file simultaneously, then merging the changes into a single version, highlighting any conflicts or problems that may arise.
There’s plenty of more detailed descriptions of VCS systems online if you’d like to learn more (Wikipedia might be a good place to start), so I’ll save diving too deep into the rabbit hole for now, I’m sure that if you’d really like to learn more, Paul can work it into future shows. For now, I’ll return to our case in point; “Is it worth making the change from an existing system and move to something like Subversion for a team of our size”.
I work in a team of 11, with 2 other designers and 3 other developers, and we ran into issues recently with a site that needed some last minute changes made. I was asked to do some markup modifications and CSS changes which required me to modify multiple files. This project wasn’t in a VCS system, so I was given a copy of the files on a flash drive. I made my changes, re-saved the files to the flash drive and handed back to the designer. In the mean-time, the designer had made other changes to the files, and needed to merge my changes with her own manually by copying and pasting from my copies of the files. To further complicate matters, the developer then needed to take these files and integrate the markup and CSS into their .NET templates.
I don’t need to tell you that this was an absolute nightmare, at one point we were managing 5 local copies as well as 2 remote copies (one on the dev server, and one on the live server) To be fair I’m not sure if the team has ever hit a problem such as this before, with multiple people working simultaneously on a project and unfortunately we don’t have VCS as a mandatory part of our workflow as yet, but after this experience, I’m sure it won’t take long.
If we did have VCS, I could have checked out the necessary files, made my changes, and checked them in, the other designer could have checked out the same files and made her changes simultaneously, and also checked them in when she’d finished. Then we could have simply merged these together into one, any conflicts would have been highlighted for us to easily rectify. The developer, when ready, could easily deploy these from the dev server to the live one with a couple of commands.
There will be issues with integrating this into your own processes, especially with people who have their own tried and tested systems, but personally I think you really have to put your foot down here. VCS should be a mandatory part of your workflow, especially as your team grows and there are more people involved with projects.
If possible, I’d recommend arranging training sessions on whichever VCS you choose to adopt, you should only need a day, or even a half day to go through the basics of using a VCS for your dev team, I’d even wager (or should that be “hope”) that those who have been professional developers for some time will already have experience of one form of VCS or another and shouldn’t be resistant to using one.
My last point would be to explore the various VCS systems on offer. The main 3 that come to mind when writing this article are Subversion, GIT and Mercurial.
Subversion (SVN) is the system that most listeners will have probably heard of. SVN is a centralised VCS system which centers around a single repository. Subversion is a well known, and generally well supported tool with a wide range of user interface tools available such as such as IDE extensions for most popular IDE’s and Windows Explorer shell extensions like TortoiseSVN. There’s also native Windows and Mac GUI tools available to make the normal command line interface a bit easier to digest.
GIT and Mercurial are slightly different in that they’re Distributed Version Control Systems (or DVCS for short). While Subversion manages a single repository, a DVCS system like GIT has multiple repositories. The best way I can explain is that imagine if my team was working on a project, and we had a repository on our dev server, I can then clone that whole repository to my laptop, and take it away to work on at home, on the train, or at the top of a mountain if I so wished. With a centralised VCS like subversion, you really need access to that central repository to commit your changes, with a distributed system, al
l your developers can mainta
in their own local copies of the repository, commiting changes to the master repository when needed.
GIT is actually the system I’m getting to grips with at the moment, the branching, tagging and merge tools are more stable than the ones within Subversion. Please note that I’m not trying to bait anyone here, and I don’t want to get into a flame war about which VCS is better than the other. GIT’s distributed nature makes more sense to me personally, and allows me to manage my branch without network access if needs be, and in the event that our development web server with the master repository blows up, each developer has a copy of the repo in some form, and there is a good chance that the whole codebase can be rebuilt easily.
So I hope this persuades you into adopting some form of version control, but if you really ask yourself, you already know that you need to use it, and to return to Simon’s original question, I bet your developers already know they should be using it, they just need a little encouragement to integrate version control into their processes, the benefits far, far outweigh the disadvantages.
By Paul Stanton