似乎构建系统的最佳实践是拥有一个可以构建所有源代码并打包发布的脚本。参见乔尔测试 #2
你如何解释不可移植的依赖关系？例如，如果您为 .net 4 编码，那么您需要在盒子上安装 .net 4。标准 MS 版本 .net 4 不是 xcopy 可部署的（除非我弄错了？）。我可以看到一些途径：
为了实现构建脚本，您必须问自己，您想要/可以在上面花费多少工作。这导致了您必须多久设置一次构建环境的问题。我可以看到＃2 将是完美的解决方案，但我需要做很多工作，因为通常你有不止一个不可移植的依赖项。
所以我们使用#1 。而且效果很好。最重要的是，构建脚本从某种自检开始。它会查找构建整个软件所需的所有内容，如果找不到，则会给出错误。它给出了一个明确的错误信息，所以任何新人都知道如何让它运行。当然，与许多软件一样，它几乎永远不会完成并且会根据需要进行扩展。当整个构建过程需要几分钟以上时，此测试可能需要几秒钟的缺点是微不足道的。
带有设置解决方案的 wiki（甚至其他）对我们来说不是一个好的解决方案，因为三个月后没有人知道它在哪里，但是每天都使用构建脚本。
构建脚本本身是一组许多不同的东西，根据需要选择。它从调用许多其他东西的批处理开始（我们使用的是 Windows）。其他批次，MSBuild，本土工具。每一步都在检查自己的依赖关系，以解决本地问题，您可以在后面三行看到为什么需要这个特殊的东西。
第二个状态是“你能一步完成构建吗？” 如上所述，这意味着开发团队要有效，构建过程必须尽可能简单，以减少构建过程中的错误并确保一致性。当团队变大时，这一点尤其重要。您要确保每个人都在构建相同的东西。（使用该软件包完成的工作也应该很简单，但恕我直言，这并不重要。）Msbuild 擅长于此；它们提供了设置构建服务器的工具，该服务器可以独立访问源代码控制系统，因此开发人员的操作不会破坏构建环境。我强烈建议使用 TFS 设置构建服务器——许多构建问题将消失，您将拥有 Joel 所描述的一键式构建。
至于您关于该软件包对部署的作用的观点-您对MS有很多选择，但是“单击”越多，您就可以做得越好。我相信这与 Joel 的 #2 略有不同。在他的示例中，他描述了更改他将用于安装的软件不是因为一个执行步骤更少，而是因为一个可以合并到一步构建中。