多应用程序 Coldfusion 7 服务器和 CFC 路径

Question

我们有一个 Coldfusion 服务器，它托管多个应用程序，所有应用程序都在它们自己的子文件夹中。比如：

• /webrootfolder/applicationA
• /webrootfolder/applicationB

此外，在开发服务器上，我们为每个开发人员提供一个给定应用程序的副本，每个都是 Subversion 工作副本：

• /webrootfolder/applicationA_dev1
• /webrootfolder/applicationA_dev2
• /webrootfolder/applicationA_dev3

由于我们正在运行 Coldfusion 7（对升级有很大的阻力），我发现自己陷入了困境，因为我想在软件包中使用 CFC。以下是各种问题、尝试的解决方案以及这些问题：

• 仅当存在单个包时才使用相对组件名称，这会使单个文件夹中的组件变得混乱。
• 只要您从不引用父包中的组件，就可以使用子包，这在扩展、实例化或将组件用作 cfargument 类型时似乎很容易发生。
• 使用从根目录开始的完整 CFC 路径不适用于我们每个开发人员的多个副本。 ** 使用带变量的动态路径是我现在的解决方案......直到我意识到它不适用于扩展或 cfargument 类型...... ** 使用服务器映射在开发中不起作用，因为每个开发人员副本都有一个别名。我希望代码与文件夹无关。 ** 使用特定于应用程序的映射（在 Application.cfc 中定义）不起作用，因为 CF7 而不是 CF8+。
• 创建所需 CFC 的本地虚拟副本并包含实际 CFC 的内容（使用相对路径“../../”）是我以前的解决方案。它可以工作，但是到处都是这些克隆真是太麻烦了。 ** 最近，我发现这个解决方案并不总是有效。 Coldfusion 对显然包含在各种 CFC 中的同名函数感到困惑。
• 在每个开发人员的机器上使用开发 Coldfusion 服务器，允许应用程序路径始终为 /webrootfolder/applicationA（由 Mark A Kruger 建议）。 ** 这里的主要问题是说服计算机团队让我们安装它。这可能需要很长时间，我担心我没有。 ** 网络配置可能还有其他问题（我不确定，也许可以访问数据库），如果允许的话，也需要经过网络团队并需要一段时间。

每个应用程序/文件夹一个网站 - 更改根目录

我花时间探索了网站/应用程序在 IIS 6 中的配置方式。经过一些研究，我发现可以像我在 Unix/Apache 下习惯的那样创建绑定。目前，所有应用程序都位于 Web 根目录下它们自己的子文件夹中。别名已配置，例如，使“domain.com/appA”指向“/webrootfolder/applicationA”文件夹。但它仍然是一个包含大量子路径的单一 IIS 网站。因此，Coldfusion 根目录（用于 CFC 和包含）基于该网站的根目录 (/webrootfolder)。

我做了一个快速测试，并设法在服务器上建立了第二个 IIS 网站，绑定到端口 8080（而不是默认的 80）。我将这一点直接指向 /webrootfolder/applicationA/cfm （这实际上是应用程序的根目录）。这样，Coldfusion 将该文件夹识别为根目录，并实例化“对象”CFC 将其查找为 /webrootfolder/applicationA/cfm/Object.cfc。

这正是我们在以前的工作中所做的，而且效果非常好。也就是说，这是一家小公司，我担心这个解决方案可能会有问题。主要是：我如何将人们指向这个网站？使用端口绑定对用户不是很友好（我们的用户不是技术人员）。每个应用程序都有一个特定的域听起来不错，但可能代价高昂，尤其是在涉及 HTTPS 的情况下（或者我听说过）。子域可能是另一种解决方案，但似乎也有类似的问题。

所以...

我错过了什么吗？我是否坚持使用其中一种“混乱”的解决方案？

我可以访问 Coldfusion 管理面板，可能还有 IIS 配置，但如果解决方案影响服务器上其他应用程序的路径或 URL，我很可能会受到限制。

Answer 1

我曾经向伊利诺伊州南部的一位老农询问到钓鱼湖的路线。他挠了挠头，然后对我说：“儿子，你不能从这里到那里。” :) 我想你可能和 Leo 一样。

问题不在于打包，问题在于您的 SDLC 违背了最佳实践。任何类型的“开发”服务器都应该反映生产——你已经用你的方法打乱了一些东西。此外，您的开发人员似乎在开发服务器上都有一个他们自己的代码的副本。这让我回想起 12 年前，我和我的朋友刚刚开始我们的小型开发商店，在开发服务器上托管代码并直接针对它进行开发 - 但这种方法不容易维持，而且你的团队越大，你的情况就越糟糕找到了。

您应该做的是将您的开发服务器作为生产的镜像运行。然后让您的开发人员在他们自己的工作站上运行代码——我们称之为本地开发。然后您使用源代码管理来处理差异、合并分支等。在这种情况下，您的每个开发人员都可以按照您的意愿使用打包，而这些问题就被搁置了。

我意识到我给你的解决方案可以说是“快刀斩乱麻”——但它是正确的。我想你在当前的配置上浪费了一些精力和时间，我怀疑生产部署甚至为 QA 组装代码目前对你来说是一个巨大的挑战。