我们的 CF 9 开发环境位于通用开发服务器 (DEVWEB) 上。我们正在考虑从 Dreamweaver 迁移到 Coldfusion Builder 作为我们的 IDE，我担心 CF Builder 在项目根目录中放置 .settings 目录和 .project 文件的方式。
开发团队如何处理这个问题？如果团队成员更改了他们的设置，他们对项目首选项/设置的更改不会覆盖我的吗？或者这些捆绑包中包含的设置类型是否应该在团队成员之间传播？
我们不希望在本地安装 CF 来进行开发。
感谢您对此的任何帮助/建议！
Chris
克里斯，当你说公共服务器时，我假设你的意思是每个人都可以对代码进行文件共享访问并进行更改。我们曾经这样做过，但我们通过以下方法解决了我们的问题：
- 颠覆源代码控制。所有代码都进入存储库。 GIT也是一个很好的解决方案。
- 本地工作站开发。每个开发人员都有一份代码副本和在其本地 Win7 或 MAC 上运行的 CF/Web 服务器。他们进行更改并将代码“提交”到存储库。
- Hudson 持续集成服务器。该产品允许我们创建一个部署脚本，从 SVN 更新我们的公共开发服务器。
- 提交后挂钩/触发器。通过一些脚本，我们的 SVN 提交可以“触发”hudson 在我们的公共服务器上运行构建。
结果与整个团队在单个服务器上开发非常相似，因为每个源代码控制提交都会导致该代码被推送到公共服务器（我们称之为“登台”服务器）。
由于 SVN 或 GIT 有很好的集成 Eclipse 工具，因此源代码控制部分（有时看起来是最难的）实际上是最容易习惯的。
最困难的部分通常是开发人员必须在本地工作站上运行 Web 服务器/CF 服务器，这可能会也可能不会 - 而且许多开发人员（太多了:)对底层的 Web/CF 一无所知技术，因此他们有一些东西需要学习...例如如何设置数据源、向类路径添加某些内容或在 apache 或 IIS 中创建虚拟目录。但这些课程通常会提高员工的调试技能 - 所以这是一个胜利。
完成后，您将拥有一些以前没有的东西 - 源代码控制、持续集成、新技能等。所有这些都将使您的员工整体受益。这就是我的看法 - 如果您想了解更多详细信息，请随时离线联系我。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
