推荐的构建目标答案

【问题标题】：Recommended build targets推荐的构建目标
【发布时间】：2010-12-02 14:36:27
【问题描述】：

我是一名独立开发人员，正在研究 MSBuild/NAnt 等工具来改进我的构建过程。我的项目文件开始因构建后事件而变得混乱，并且有一些分析工具我想运行一些时间而不是其他工具。我想恢复秩序并将所有内容定义到构建 XML 文件中。

我对构建目标的想法是：

调试构建：专为快速编译和部署而设计。未执行代码分析或检查。
分析构建：执行调试构建、代码分析并生成文档。
部署构建：使用适当的编译器标志编译发布。还执行与分析构建相同的步骤。

我在正确的轨道上吗？对于 .NET 开发，我应该使用哪些构建目标？

【问题讨论】：

标签： .net msbuild build-process nant

【解决方案1】：

我们目前仅使用 CI（持续集成或调试构建）和 Release。调试构建只包括编译，没有代码分析、测试等。

发布是所有魔法发生的地方（就像他们在 MTV Cribs 中经常说的那样）：版本控制、代码签名、打包、压缩、混淆、文档等。

我可以想象另一个“发布”或“部署”构建目标，它执行发布并发布到测试服务器，在那里我决定发布版本何时准备好推送到我们的测试服务器。

【讨论】：

顺便说一句，刚刚发现并没有真正需要发布构建目标。有一个名为“TFSDeployer”的工具可以做到这一点，当构建的 BuildQuality 发生变化时，它将启动一个可定制的脚本。可以在 Codeplex 上找到工具“TfsDeployer”。

【解决方案2】：

以下某些内容更适用于团队发展。

我同意限制配置的数量——每个配置都会增加维护开销。因此 Debug 被剥离，而 Release 具有代码分析等。但是我在 Release 构建上运行 CI，因此我不必单独进行 CI 和 Release 构建。这也意味着任何发布构建问题都将被签入触发的 CI 构建捕获，因此如果开发人员破坏了（潜在的）发布，他们会立即获得反馈。我做的另一件事是发布配置，我更改项目设置以将警告视为错误，因为我希望代码没有警告；任何警告都会导致 CI 构建失败。由于代码分析会产生警告，这意味着任何违反 CA 规则的行为也会导致 CI 构建失败，这意味着开发人员可以更快地修复它，从而帮助从一开始就确保代码质量更好。

【讨论】：