If you are using version control, what is your setup like, and why did you choose to do it that way?
In Java development, I've got a repository, and I checkout the code to my desktop, check it back in, etc. So, there is no version control on the production server, though. Of course, there is no point (that I see) to have it on the production server, since you don't need many of your source files, but only the compiled classes (I'm assuming web development here).
But in CF, you'll be using all your source files as the actual files to be run, so you might very well set up source control on the production server, and have that be your main code base (say, checking it out to your development server and editing it from there, or to your desktop). Or, do you simply run the version control on your development server, and FTP any changes to production?
There are other ways, to be sure, so if you're using version control on your ColdFusion projects, I'd like to know the different ways you have it set up, and why you chose to do it that way. Any help is appreciated!
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
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 - 5 hrs
Posted by David Fekke
on Feb 07, 2007 at 12:12 PM UTC - 5 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 - 5 hrs
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 - 5 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 - 5 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 - 5 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 - 5 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 - 5 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 - 5 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 - 5 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 - 5 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 - 5 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.
Posted by Douglas Knudsen
on Feb 08, 2007 at 01:45 PM UTC - 5 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 - 5 hrs
Leave a comment
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 - 5 hrs