I’ve been developing web sites for many years now. As my aspirations grow, so do the sizes of the projects. And along with that comes more people. For the past few years, I’ve been working side-by-side with my business partner Damien. Sometimes we’re working on our own projects, but many times we’re collaborating on the same project.
When two people are working on the same website, you immediately run into the age-old (computer age, anyway) problem of people stepping on other people’s work.
And now we’re introducing a third developer to the process. Three developers working in three locations means that we need a better solution. Fortunately, there have been thousands of people who have had this problem before us who have created version control tools like CVS and Subversion.
I’ve tried getting Subversion going previously, but never had the time to get my head around how it works and how we’d have to change our development process.
Here’s our current process …it is quite loose and probably seems pretty familiar to many of you.
We have development and production versions of a website, both of which live on a server somewhere. We directly edit the files on the development server and we generally don’t keep our own local versions. It is just easier to have a central database and web front-end to test on.
Until now, we’ve relied on caution, diligence, and word of mouth to make sure we’re not working on the same files. Our work-flow goes something like this:
1. I need to edit a file on the server, foo.php
2. I think for a second if there’s a chance that Damien is working on the same site.
3. If so, I’ll jump on IM and verbally claim the file, “Yo, I’m going to edit foo.php, k?”
Sometimes, though thankfully rarely, we edit the same file and one of us clobbers the other’s work. That totally sucks, but we’ve done ok. We talk a lot, so we tend to know what the other is doing.
We work like that, making all our edits on the dev server. After testing we’ll either move all files over to production or just one or two depending on the size of the change.
This process has served us pretty well. But adding a third person into the mix, it’s time to grow up.
Here’s what a new process will look like
We’re installing Subversion on the server and on all of our work systems.
I’ll create a Subversion repository on the server for each of our web projects. We’ll start with one or two to flesh out the process. Understanding how this will work was the key for me to embrace the process and move forward. (Writing this document is helping as well!)
The Subversion repository contains all of the code for a website. Since we’re adding version control to an existing site, it’s a snapshot in time of an existing project. The code for the website is imported into a repository which sets the mark at Version 1 for each and every file.
This repository is not the code used by the web server for either the production or development environments. Just like our own working copies, the web servers contain snapshots of code that live in their own directories. When we want to test the development server, we get the latest code out of the repository (via a “checkout” or “export” operation). When we want to move the code into production, we move the code there as well.
We’re NEVER editing the files directly in the web server directories. This is a big change.
When we do want to edit code, the process looks like this:
1. checkout the server code. This creates a copy of the code for editing.
2. make edits and test on our own personal copy of the web server
3. check code back in
If in step 3, we’ve changed a file that someone else has changed, Subversion will alert us and we must resolve those differences. How easy that will be remains to be seen.
A key difference is that we’ll each have our own personal version of the website running for development. Having a copy of a website running is quite simple and something I’ve done many times before. It’s easy to install an apache server on just about any computer.
It can get trickier, however, to have a useful working local copy of the database. Our databases tend to be quite large, hundreds of megabytes, even approaching a gigabyte in a few cases. That’s a lot of data to be moving around, even over broadband connections. So I think we’ll set up one or two copies of the database on the remote server and we’ll all test using the same remote database and our own local web servers.
Challenges
There are a few things that I need to work out, in my head, and then in practice.
1. Images and cache files: There are many files that live in the application structure that should not be under version control. These are typically cache files and graphics (user thumbnails, product images) that get updated by the server, not by a developer. We’ll all need these files on our own development systems, but we don’t want them to get checked out and in to version control. There are literally tens of thousands of these files and we cannot be checking them in and out.
2. Environment Files: These are things like configuration files that are unique to the specific web server environment. They should be under version control, but will differ depending on the server. Not sure how to handle these. Maybe by definition, they cannot be kept under version control.
This is the beginning of my journey into version control for website development. I’ll continue to document my experiences and processes as things progress.
