New Subversion development environment

The development team that I am working with originally started out as two developers. We had about 4 applications between us and rarely were we working on the same application, much less the same piece of code. We simply mapped our development IDEs to a mapped drive on the development server and worked on what we needed to. When a piece of code was ready it would be moved to a staging server to be tested, then moved to production. If for some reason we were working in the same area, we would just shout over the wall and warn the other. Sound familiar? If you are on a small team, I am betting it does.
As our development team has grown we have definitely found a number of weaknesses with this approach, including:

• Accidentally overwriting another developer’s work, or worse… having *yours* overwritten!
• Lack of a clear trail of historical changes. Yes, of course we are all supposed to sufficiently comment all changes, but in reality we all know that this occasionally fails to happen.
• Lack of trail of ownership. (see “commenting” above)
• By pushing up one file at a time both to staging and then to production, we found that over time we had some variances between what was on the production server as opposed to what was in staging, and often a vast difference from what was in development.
• No easy way to roll back to a previous state of the application.

This has been one of those growing problems where we knew we needed to implement source control, but in the heat of development, when on earth would we ever find spare time to do this? We finally decided it was time to make time.

The following is the approach that we took, and has worked really well for us so far. For the purposes of this document, we will be calling the applications app1.domain.com, app2.domain.com, app3.domain.com, and app4.domain.com.

We first altered our web server so that each developer has their own development environment, including their own instance of ColdFusion, a directory structure completely separated from the others, and their own databases mirroring the production databases (eg. app1database is named dave-app1database). So, now our development directory on the server looks like this:

-aaron/CustomTags/ (each developer has their own copy of the global custom tags directory)
-aaron/app1.domain.com/
-aaron/app2.domain.com/
-aaron/app3.domain.com/
-aaron/app4.domain.com/
-dave/CustomTags/ (each developer has their own copy of the global custom tags directory)
-dave/app1.domain.com/
-dave/app2.domain.com/
-dave/app3.domain.com/
-dave/app4.domain.com/
[repeat with other developers]

Given this model, when I am testing the code I am writing for app1.domain.com, I can access it in the browser by going to http://dave.app1.domain.com

Next we installed Subversion on the development server and imported the current production code as individual projects (CustomTags, app1.domain.com, app2.domain.com, app3.domain.com, app4.domain.com).

The Development Process:
Now that we have the model in place, anytime that a developer is assigned to work on a project they simply check out the code for that application. When they are ready to submit back to the repository, they first need to synchronize with the repository to see if anyone else has modified any code in the project. If so, they need to update their development instance with those changes and retest to make sure that their changes play nice with any other changes. Assuming all tests are fine, they can then commit to subversion and notify the project manager. In the event of a conflict where another developer has committed changes to a file that they are working with since checkout time, Subversion makes it easy to compare the changes and merge the two versions gracefully.

The Deployment Process:
Once changes have been committed the project manager archives current staging code, and replaces it with a Subversion export from the repository. By taking the approach of moving code the application as a whole unit,rather than the piecemeal approach of moving whatever files we have changed, we are eliminating the potential for accidentally forgetting to move any changed files, thereby keeping the application in tact. Once the staging environment has been completely tested, the same approach is then taken to move the code to production.

We are now about 2 weeks into this environment and all is going well… except the following scenario. What if you aren’t ready to move *all* the changes yet? Stay tuned for another entry soon on branching projects.