Sumo Consulting^2.0

On the heels of my last Subversion post, ColdFusion Version Control with Subversion, here's another...

I recently setup a new Subversion development environment for ColdFusion and thought I would share the two models I considered, what the differences were, and why I ultimately chose the one I did. I actually set both of these models up completely and had them both working, so I went through the entire (slightly painful) process twice.

My development environment consists of the following:

• Subversion (SVN server)
• SVN Book (RTFM)
• CFMX7 Developer Edition (CFMX Server)
• CFEclipse (IDE)
• Subclipse (Eclipse Plugin)
• JavaSVN (Eclipse Plugin for SVN+SSH)

In this post, I am also making the assumption that each developer will want to check code out to a different location and that they will require their own ColdFusion instance to work within. This is required in my specific case for several reasons, the primary being that we use several mapped ColdFusion paths in our application. For the mapping /myapp/model > myapp.model, we would run into a problem with a single server configuration because there can only be one physical location of /myapp/model.

Local Development, Remote Integration

I this environment there is one central SVN server and every developer has their own local development server(s) installed on their desktop or laptop. This usually means downloading and installing CFMX7 Developer Edition and sometimes means downloading and installing a database server locally as well.

Note: Installing a database server locally is not always required. If you have a constant connection to a development database server you can configure CFMX to remotely access that server from your local machine, eliminating a local administration task.

In this setup you will checkout the entire codebase from SVN and work on it locally on your own machine. You might work on it for an hour or for a week before checking the code back into SVN, but you edit code and test it out locally on your own machine, running it through the local CFMX Developer Edition that resides on your machine.

Once you're finished editing code and are ready to check the batch of changes back into the SVN repository, you first do an "svn update". This update will download and merge any new changes anyone else has made in the repository since your initial code checkout. If anyone made changes, test your merged code again locally, make changes if needed, and then do an "svn checkin" to upload your new code back into the repository.

At this point your code is back in the repository along with everyone else's changes but isn't in a place you can browse with a web browser. After checkin, you may want to look at your code it in some central location, perhaps for testing/QA, or maybe just to make sure it really works on the server. Testing centrally also helps if you are doing development locally on Windows, but using Linux on the server (as I am doing).

Fortunately, automatically exporting your code to a web accessible location is easy to do with SVN Hooks. With a SVN Hook, you are essentially writing a short script that is triggered every time anyone does a commit on the repository. To use such a hook, you will want to read these detailed instructions on how to create an SVN Export Script.

Pros

• Since developers are each developing locally, they are essentially each in their own sandbox and won't step on each other's toes during development.
• Developers are free to carry their work away from the office. If you checkout code to a laptop with it's own complete local development environment, you can do development anywhere you want, disconnected from the office.
• Local development forces developers to consider Design Patterns that will work across multiple servers and platforms, making code more transportable in the long run.

Cons

• There is some amount of overhead for each developer to install and maintain a local development environment. However, I would suggest that a developer not able to maintain their own development environment may need to be looking for another line of work.
• Integrating database changes to a central database can be difficult if there is not a well established plan/system to deal with datamodel changes.
• Depending on the nature of your code, some changes may need to be made to existing applications to allow them to run on any domain/ip/directory structure. (many codebases contain lines such as cfif CGI.HTTP_HOST eq 'my.server.com')
• From a security standpoint you are allowing and encouraging people to bring code home with them. This may or may not present a security risk for your organization.

Remote Development, Remote Integration (AKA shared development server)

In my experience, most web shops use a configuration where all the developers connect to one central CFMX server for development work and work on a single codebase that resides in a single location on that server. While easy to maintain from a administration standpoint, this configuration does present some problems. The primary problem is that any failure on the server effects all developers at once. This means if someone's editing application.cfm or any other critical point in the application and goofs something up, everyone's stuck till that developer fixes the problem. A similar problem with a shared database or any other server component can also cause downtime for everyone.

So how do you get around this? CFMX with multiple instances to the rescue! It may require some serious one time configuration changes, but you can fairly easily configure your development server with multiple instances and give each developer their own CFMX sandbox to play in, complete with their own CFAdmin, mappings, and database settings.

First, install and configure CFMX for Multiple Instances. This may require you to re-install CFMX entirely. If you need help with this, you may want to check out Brandon Purcell's ColdFusion MX 6.1 Step-by-Step Creating and Configuring Multiple Instances.

Second, you are going to want to give each developer their own development space on the filesystem. Both Linux and Windows have mechanisms for giving each user account a home directory, and I would suggest basing your model off that for ease of administration.

Third, depending on what webserver you are using, your configuration requirements may differ, but you are going to want to give each developer a different development location/address of their own and map it to their personal space on the server. If you have alot of IPs available, you may want to simply give each developer their own IP, or you may want to even give each developer their own subdomain similar to cameronc.dev.myserver.com. You can even segment the instances by port if you'd like so that everyone has the same IP or domain, but uses a different port to develop against.

Last, you're going to need to give each developer remote access to the server, and you may even want to configure permissions so that no-one can get into another user's filespace.

So now everyone has their own personal space to work in. The rest is the same as a local development environment with the exception that when you checkout code, it's going back onto a fileshare instead of to your local machine. It should be noted however, that nothing about this configuration is preventing you from checking code out to your local machine. If you want to checkout code to your laptop and take it home, you still can.

The last bit of this puzzle is a common integration instance. I'd suggest creating one addition instance to be used for testing and use an export script (as outlined above) to automate export to a common integration/testing location.

For the record, I considered this setup and ultimately decided against it for our organization. The primary reason is that we frequently do development from remote locations, using a VPN tunnel to connect to the SVN repository. Using this model means that when you check code out you are essentially pulling it down off the SVN server and sending it back to a different location on a remote server, usually via NFS, SAMBA, CIFS, whatever. All this file activity is severely impacted by the latency of a VPN connection, or any WAN connection for that matter. You can read File Sharing on the WAN: A Matter of Latency to see why this is a problem. Feel free to email me if you have a WORKING solution to that problem not a "what if" theory, because trust me I tried everything under the sun to make it work.

Pros

• Everyone gets their own sandbox to play in, no-one steps on each others toes.
• No-one has to maintain their own personal environment, though the central server does have to be maintained, and each instance does have setting which have to be maintained.
• Security - code never leaves the facility in this model so it's slightly more secure.

Cons

• Overhead of setting up and managing many instances.
• You can't effectively use this development model over a wan, though you can checkout code locally (not via WAN) and take it home with you.

That's it! A longer post than I had planned when I started it. Hopefully it will be helpful to developers new to version control or who are setting up new version control environments.

• Comments (2)