I'm in the process of setting up a new Subversion environment and will be posting the end result on my blog. However, here's the basic run-down.

We have two dev servers. One is a SQL Server that hosts our databases in a development environment. This server also holds our Subversion repositories. Our developers do all localhost development pointing their CFEclipse projects to the Subversion repo on this first dev server. Our second dev server is for staging. It runs a protected copy of our entire codebase that most developers do not have access to. No individual files are deployed to staging. Developers work locally, and test their changes on their local Web server. When things are working properly they commit their changes to Subversion and we run a deploy process (ANT) to deploy from Subversion to our staging server. The developer will then test their code again on staging (others will test as well).

Once everything is good on staging, we deploy regular builds to production using other automated processes. While FTP access to production is available it is not to be used for individual file uploads. All production code must first go through staging and the build-deploy process.

I cannot see a reason why you would put version-control software or repositories on a production server. That pretty much goes against the idea of Source Control Management altogether.

Posted by Aaron West on Feb 07, 2007 at 11:55 AM UTC - 6 hrs

Perforce

Posted by David Fekke on Feb 07, 2007 at 12:12 PM UTC - 6 hrs

Thanks Aaron, I'll keep a lookout on your blog. And if you remember once you've written the post, feel free to post the link here for future reference (I'll eventually get around to hyperlinking URLs.

You also mentioned, you "cannot see a reason why you would put version-control software or repositories on a production server. That pretty much goes against the idea of Source Control Management altogether."

I haven't read much of the literature on source control, so I have to admit my ignorance there. I've been (very) slowly easing into it the past 8 months or so. =) Even without having read much, I think I'd have to agree with you. It sounded funny to me, which is one reason I asked. In fact, I can't think of a project in any other language I'd even consider doing such a thing for, but any of the languages I'm thinking of aren't run the same way as CF does.

Well, I take that back. Ruby with Rails would, and I haven't seen it done that way, nor have I done it that way.

Thanks for the insight. Anyone else?

Posted by Sam on Feb 07, 2007 at 12:20 PM UTC - 6 hrs

David,

I hadn't heard of Perforce before. Is this (http://www.perforce.com/) what you're talking about?

How has using it helped you / what sort of options are there / is it like a replacement for CVS/SVN/SourceSafe, or does it work with them?

Posted by Sam on Feb 07, 2007 at 12:22 PM UTC - 6 hrs

Here's one good reason why it's a bad, bad, bad idea to have version control on production server: what if there's a catastrophic hardware failure? Not only does your clients' websites get hosted, but also you've lost access to version control.

Always keep version control software on your development server that is accessible only by your team for interanal use. And of course, not a bad idea to back up on a regular basis.

Posted by Lola LB on Feb 07, 2007 at 12:58 PM UTC - 6 hrs

Hi there, we work for many clients and our using subversion for our in-house version control. However, I have two additional clients that have their own version control set-up.

Client 1 - 3 Severs

Alpha - This is the equivalent of a development playground. Developers are allowed to do anything they want here. Sometimes, developers my screw each other up depending on what module they are working on.

Beta - Once a developer is done on Alpha and considers a fix or new feature to be ready. They push the individual files onto the Beat server. Sometimes, they may push the whole site depending on what has changed via FTP or some other script). Once the new files are on the Beta server then the client is free to test.

Live - Once the client has agreed that the fix is working on the Beta server, then our designated Source Control admin will push the final version to the live server.

We have a separate source control database for both the Beta and Live servers and that lives on a development box.

My other client uses perforce and uses a "staging" server to post changes to, seek approval from the client, then sync's perforce with the live server and uses ANT to deploy.

If you can afford it, I highly recommend the Alpha/Beta/Live option as a best practice. The freedom is that your developers can still work while the client is reviewing code on your Beta server.

Posted by Tracy Smith on Feb 07, 2007 at 01:15 PM UTC - 6 hrs

I'm also exploring using ANT. The big benefit of ANT is it's automated - so I know every time I run the script what's going to get copied up to the server. No guessing! :)

Posted by Jim on Feb 07, 2007 at 02:14 PM UTC - 6 hrs

We use PVCS here at my office... For CF we have a development, uat and production environment. Developers checkout from DEV, make changes, test in dev, then promote to UAT.. We don't have access to templates beyond DEV and need manual approval before templates are moved into production from uat. Archives of our changes are stored on a seperate server with (I assume) daily backups.

We are looking to move from PVCS, so it will be interesting to see what other people are using.

Posted by JAlpino on Feb 07, 2007 at 03:12 PM UTC - 6 hrs

TortiseSVN to talk to a SVN repository (WITHOUT installing SubVersion). I'm the sole developer on a large ColdFusion FuseBox 5.1 application, and am using this to manage my updates, which are infrequent but complex. So, I created a repository and added my dev environment, then backed it up and deleted it, then checked it out on the dev server. After verifying that all changes were ready for production, I checked out the repo on the production server. I modified the Fusebox files for production environment on production (the mode parameter is different in the fusebox.xml.cfm file and I can't put logic there to switch between production and development). All subsequent changes are committed on dev, and when everything is ready for transition to production, I do an "Update" there to get the changed files without overwriting the fusebox.xml.cfm file. So far this is working pretty well for me.

Posted by Matt Newby on Feb 07, 2007 at 03:31 PM UTC - 6 hrs

I use version control of some form for every project. Usually the repository is hosted on a server that is backed up and well maintained (at Adobe we use Perforce and have a whole team dedicated to looking at the farm of Perforce servers; although the Web Team uses CVS - historical reasons).

Everyone doing CF development has a localhost setup and checks code in and out, usually into a specific Perforce/CVS tree on their local machine, and then has some sort of local build script that pushes files from our local source tree into our local server tree. That means that we can arrange the source tree as best suits the repository organization and have the build script "deploy" to a structure that matches our production setup. My team uses ant for this.

We also have a build server. It runs builds, mostly automatically, extracting source from the repository (via Perforce/CVS) and creating builds for each active branch of development. Our build script can create a "deployment artifact" - a tarball / ZIP file - that we can copy to any machine and unpack and then use an ant script to "deploy" to that machine's CF server tree.

Posted by Sean Corfield on Feb 07, 2007 at 08:36 PM UTC - 6 hrs

We use CVS, develop on localhost and use use ANT to deploy from the CVS repository (dedicated linux server) to staging and live servers as required.

A few interesting points. ANT can be used to amend source files as they are deployed - sounds a bit of a scary thing to do but I was thinking of the fusebox.xml setting that Matt Newby mentions above or other dev/live setting changes you need to make.

We have recently amended the method we use to deploy from CVS to speed the process up. Rather than deploying the entire site each time, we now have a CVS sandbox versio of the site on the target server in a temp directory so that ANT can 'UPDATE' from the repository (only the changed files) and then a 'sync' task is run between this sandbox temp dir and the real site under the web root (ignoring the CVS control files/folders). This has reduced our deploy time for a typical system from a couple of minutes to a few seconds.

I'm a CVS fan (only because its what I know really) SVN is a next generation of CVS and fixes some little niggles in the way CVS works. However I have found that the eclipse implementation of the CVS client makes CVS use very sweet!

Cheers MIke T

Posted by Michael Traher on Feb 08, 2007 at 02:34 AM UTC - 6 hrs

We use Evolution for our source control (<a href="http://www.ionforge.com">www.ionforge.com</a> and use a methodology like Aaron laid out. Developers pull code from the repository and work on their local web server, checking in or shelving code on the dev server as they go. When we're ready to release for testing an automated trigger moves a copy of the project to the staging server, where it gets pounded on. Once it passes testing another automated trigger sends the changes from the dev server to the production server.

Our dev and staging servers are locked down tight as a drum. The production server is secured, but less so for practical reasons. I can't imagine ever recommending you use your production server as a source repository.

p.s. heard through our local Java users group that the Evolution folks are releasing an integration with Eclipse soon. That will be nice!

Posted by Paul Kerner on Feb 08, 2007 at 12:01 PM UTC - 6 hrs

We use CVS also, had it setup b4 SVN became the fad boy on the corner. Been using TortoiseCVS to deploy to staging/production by a 'file promoter'. Currently working on a web based tool to keep track of builds that uses ANT to push files out. With Flex in the mix now, have to do something new, it gets compiled before runtime, eh?

I agree highly concerning the CVS plugin in Eclipse...simply rawks.

DK

Posted by Douglas Knudsen on Feb 08, 2007 at 01:45 PM UTC - 6 hrs

Three servers, dev/qa/production. Separate Subversion server, with matching branches. Then scripts to export each branch to the appropriate server.

I prefer Perforce to Subversion-- probably a relic of my exposure to it at Allaire/Macromedia-- but went with Subversion at work for budgetary reasons.

Posted by Chris Champion on Feb 21, 2007 at 01:27 PM UTC - 6 hrs

I'm seeing a lot of recommendations for Perforce. I might have to check it out one day...

Posted by Sam on Feb 21, 2007 at 01:33 PM UTC - 6 hrs

I really like how you explained that with version control I will be able to organize all of my files. Creating a source to all the files can be very time consuming and you can link them wrong as well. The other day I was manually linking all of my database into my external drive and I thought to myself that there has to be a better way. Thanks for sharing this article because I will have to try out this new software.

Posted by Breck Lewis on Dec 08, 2015 at 08:46 AM UTC - 6 hrs