实现单个脚本构建 - 非可移植依赖项

Question

构建系统最佳实践似乎是拥有一个可以构建所有源代码并打包发行版的脚本。见Joel Test #2

您如何考虑非便携式依赖项？例如，如果您编写.net 4代码，那么您需要在框中安装.net 4。标准MS版本.net 4不能部署xcopy（除非我弄错了？）。我可以看到一些途径：

1. 在某些资源文件（wiki，txt，等等）中明确说明了依赖关系。当你 调用构建脚本，如果没有安装依赖项，构建将失败。这是一个可以接受的结果。
2. 构建脚本负责设置环境。因此，如果你需要.net 4并且它不在盒子上，那么它会为你安装它。
3. ＃2的味道 - 该脚本不是安装依赖项，而是生成一个预先打包的映像（虚拟机，Amazon EC2 AMI），该映像设置了所有依赖项
4. ???

Answer 1

要实现构建脚本，您必须问自己，您希望/可以花费多少工作。这导致了您需要多长时间设置构建环境的问题。我可以看到＃2将是完美的解决方案，但我需要做很多工作，因为通常你有多个非便携式依赖。

所以我们使用＃1。而且效果很好。最重要的是，构建脚本是从某种自我测试开始的。它查找构建整个软件所需的一切，如果找不到某些内容则会出错。它给出了一个明确的错误信息，以便任何新人知道如何使其运行。当然，与许多软件一样，它几乎从未完成并且可以根据需求进行扩展。当整个构建过程需要超过几分钟时，此测试可能需要几秒钟的缺点是微不足道的。

使用安装解决方案的wiki（甚至是某些其他）对我们来说不是一个好的解决方案，因为三个月之后没有人知道这是什么，但每天都在使用构建脚本。

构建脚本本身是一组很多不同的东西，根据需要选择。它从一个批处理（我们使用Windows）开始，它调用了很多其他东西。其他批次，MSBuild，自家种植的工具。它自己的每一步都是检查它自己的依赖关系，让问题在本地，你可以看到三行，为什么需要这个特殊的东西。

Answer 2

第2号声明“你能一步完成构建吗？”如上所述，这意味着要使开发团队有效，构建过程必须尽可能简单，以减少构建过程中的错误并确保一致性。随着团队变得更大，这一点尤其重要。你想确保每个人都在构建同样的东西。 （用这个软件包做的也应该很简单，但它并不像恕我直言那么重要。）Msbuild很擅长这个;它们提供了设置构建服务器的工具，可以独立访问源代码控制系统，因此开发人员的操作不会破坏构建环境。我强烈建议使用TFS设置构建服务器 - 许多构建问题将消失，您将拥有Joel描述的一键构建。

至于你关于该软件包用于部署的内容的要点 - 你有很多选择MS，但更多的“一键”你可以做得更好。我相信这与Joel的＃2略有不同。在他的例子中，他描述了改变他将用于安装的软件，而不是因为一个人用较少的步骤执行，而是因为一个可以合并到一步构建中。