New Subversion development environment
ColdFusionAs 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.
Developer environment. What we would like to do is allow testing to go on our testing server. Perhaps multiple developer directories is the way to go ... however we do like to model the test server's code exactly like the development server, so when we have physical paths (c:\whatever\), we don't have to change them. Most of our new code keeps those paths in the DB but legacy code sucks. Suggestions?
Subversion environment. Is there an easier way to push the files to our production server or should we just develop some sort of release schedule and deal with it. It would be nice that once the code was "committed" to subverion, it would automatically show up on production. (Or is that wishful thinking?) Suggestions?
Let me know what you think would be a good environment for us. We have the thing setup, but we need to start using it now!
As for auto deployment, we tend to do the releases manually so as to provide tight controls, but there are auto solutions available. You might want to look into writing ANT scripts that do what you are asking on commit.
For us, it works like this:
When a developer completes an item and it is tested within their environment, they commit it into Subversion. At that time, the release coordinator (lead deverloper or whoever) does an export from Subversion to a staging instance which completely mirrors production. When that is tested sufficiently that code will replace the current production code.
I am sure there are other sound approaches out there, but that system works pretty dang well for us.
~d
For the InstantSpot stuff, we just have the SVN repo on a dumb server for checking in/out and run the application locally on our laptops. I can't imagine another product matching it/beating it when it comes to graceful source control and managing merging of conflicts, etc. I am a firm believer. Do yourself the favor and take the time to set it up. If you are a windows guy they make it embarrassingly easy with the svn-1-click install. For us Linux peeps it is a bit more work, but certainly worth it.
Loading....