4

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

Chris Brandt
  • 948
  • 3
  • 11
  • 22
  • Are you using any type of version control or just FTP? – Sean Walsh Mar 24 '12 at 00:55
  • 1
    I posted an answer that points you toward what you do NOT want to do ... but added a few items that might push you over the tipping point. It's pretty hard to do team development without putting source control in the middle - and eclipse makes working with network files very difficult - and setting up a "project" in a network location is unfortunately practically a non starter. But you can ease into this in a way that keeps that central constantly updated staging or common server in the middle - which may be what you are trying to accomplish. – Mark A Kruger Mar 24 '12 at 02:16
  • We have a large number of databases on multiple db servers supporting a wide variety of small web apps. Having to get each developer set up with proper access to all of the proper dbs has (so far) been the blocker to going with individual developer CF installs. From the 2 'answers' so far, and the additional comments, we really need to get over this hump (and go full-on source control), as it appears that CF Builder wasn't really designed to work the way I (we) intended. Thanks all! – Chris Brandt Mar 26 '12 at 22:56
  • 1
    you can set up a CF install that includes all the DB settings in the admin. They are (after all) just XML files - look for "neo-datasource.xml" in the /lib directory. Create a pristine dev install with all the datasources you want and then make this XML file part of the repository. What we do is have a clear "wiki entry" for the dev setup for each client with the goal of getting a dev install running in less than 2 hours. We have MANY customers with complexity like this (multiple DBs, permissions, views, jar files etc). Usually solving this problem is about documentation and steps. :) – Mark A Kruger Mar 27 '12 at 01:45

2 Answers2

8

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.

Mark A Kruger
  • 7,183
  • 20
  • 21
  • 2
    +1 There is no reason not to run ColdFusion on each developers workstation. Then, they have full control in a sanitary environment. – Aaron Greenlee Mar 24 '12 at 17:58
  • I wanted to add that we do not necessarily run separate DB's for each "local" developer. We typically use DB servers and run a dev copy of the database. Developers connect their local isntall to this dev db copy. the reason is simple - sometimes the DB might be many many gigabytes or might contain data that we need to control and cleanse. But generally this comprimise works well. – Mark A Kruger Mar 27 '12 at 01:41
  • If you have access to the CFAdmin, you can always create a CAR file and give that file to the various developers to deploy locally - that archive will have all the mappings, dsn etc information you need for setting up the site. – Larry C. Lyons Jan 07 '13 at 19:41
0

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.

Snipe656
  • 845
  • 7
  • 15