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.

Answer 2

Sounds like you work in an environment similar to the one at my biggest clients location. As others have mentioned using a central source repository really is the best solution however if your environment is like what I deal with then it may not be an option to get such a thing installed. We actually just still use DW and use it's syncing tools and thus far not stepped on each others toes. But our "team environment" really is more of each team member has their own applications they support. If you could or do have an FTP or SFTP server setup on your development server then you should be able to at least use the sync tools built into CFB:

http://forums.adobe.com/thread/462797

It does though mean at least having a copy of the CF code on your local machines. It does not mean you need to run CF on your local machines although there are a lot of arguments for why you should. We typically run CF/IIS/Oracle/SQL Server on all of our development machines. We do have a number of projects though where it would be a logistical nightmare to try and emulate locally all of the DB(with real data) needs some applications have.

I have worked at some places where they still could not do an dedicate SVN server and they ran "SVN servers" on every development machine. This approach to me would seem to have the potential for some messy situations if in a true team environment.