How do you use Coldfusion Builder 2 in a team environment using a common development server?

Question

Our CF 9 development environment is on a common development server (DEVWEB). We're looking at moving from Dreamweaver to Coldfusion Builder as our IDE and I'm concerned about the way CF Builder drops a .settings directory and .project file in the root of the project.

How do development teams deal with this? If a team member make changes to their settings, don't their changes to the project preferences / settings overwrite mine? Or are the types of settings that are included in those bundles the types of things that SHOULD be propagated among team members?

We would prefer NOT to work on local installations of CF for development.

Thanks for any help / suggestions with this!

Chris

Answer 1

Chris, when you say common server I assume you mean that everyone has file share access to the code and makes changes. We used to do it that way but we solved our problem with the following:

• subversion source countrol. All code goes into a repository. GIT is also a good solution.
• Local workstation development. Each developer has a copy of the code and CF/Web server running on their local Win7 or MAC. They make changes and "commit" the code to the repository.
• Hudson continuous integration server. This product allows us to create a deployment script that updates our common development server FROM our SVN.
• Post commit hooks/triggers. With a little scripting our SVN commits can "trigger" hudson to run a build onto our common server.

The result is something very similar to the whole team developing on a single server because each source control commit results in that code being pushed to the common server (which we call a "staging" server).

since SVN or GIT have great integrated eclipse tools the source control part of this (which sometimes seems like the hardest) is actually the easiest to get used to.

The hardest part is usually that developers have to run a web server/CF server on their local workstation which may or may not be up to it - and many devs (way too many :) don't know anything about the underlying web/cf technology so they have a few things to learn... like how to set up a datasource, add something to a class path or create a virtual directory in apache or IIS. But these lessons generally enhance the debugging skills of your staff - so it's a win.

When you are done you have several things that you did not have before - source control, continuous integration, new skills etc. All of which will benefit your staff overall. That's my take - feel free to contact me off line if you want more details.