在 .Net 中为每个项目创建自动构建系统的优缺点是什么？

Question

刚刚花了令人沮丧的时间使用 psake 配置自动构建，我突然想到为什么不使用我最了解的语言来创建构建器？

psake 是一个用于创建自动化构建的优秀框架。我一直遇到的麻烦是学习 powershell 来运行更复杂的任务。我敢肯定 NAnt、msbuild 等也可以这样说。

我解决这个问题的想法是在 .Net 中为给定的解决方案创建构建系统。该过程的基本结构是这样的：

build.bat

rem // Set the environment for msbuild.
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"

rem // Build the solution's builder.
msbuild.exe buildsolution.csproj

rem // Run the solution's builder.
BuildSolution.exe <task>

项目的 BuildSolution

一个微型控制台应用程序：

• 引用 BuildSolution 框架。
• 包括每个任务的方法。例如：
  • 干净
  • 构建
  • 测试
  • 提交
• 注册任务及其依赖项，它可以运行。例如：
  • Builder.RegisterTask(x => x.Clean)
  • Builder.RegisterTask( x => x.Build ).DependsOn( x => x.Clean )
  • Builder.RegisterTask( x => x.Test ).DependsOn( x => x.Build )
  • Builder.RegisterTask( x => x.Commit ).DependsOn( x => x.Test )
• 运行构建器。例如 Builder.Execute()

测试任务

最终测试任务将调用 nunit、mstest、xunit 等，但首先构建所需的命令行。这是一个使用 .Net 而不是 PowerShell 对我来说是赢家的例子。

当我开发我的应用程序时，我遵循 ProjectName 和 ProjectName.Tests 的简单命名约定。构建系统搜索 *.Tests.dll 并将它们包含在 mstest 命令行中。

使用 .Net 应用程序构建此任务的优点是：

• 无需学习脚本语言即可找到测试 dll。
• 使用我熟悉且功能丰富的 IDE 进行开发。
• 使用我熟悉且功能丰富的 IDE 调试任务。

总结

除了测试任务中列出的优点之外，BuildSolution 理念的优点是项目的新开发人员可以说很容易理解和编辑构建系统。

您认为 BuildSolution 的想法有什么缺点？

Answer 1

据我所知，您说的是推出自己的解决方案。我会将其与使用其他人的现有解决方案进行比较。

优点：

• 很小
• 简单易学
• 调试简单
• 很容易引入错误修复
• 您无需提出要求即可获得新功能

缺点：

• 您重新发明了轮子（这总是会增加成本。成本是否一样多取决于您自己评估）
• 您不能雇用已经了解您的构建系统的人
• 您必须实施自己的错误修复（是的，您会遇到错误），并且不能让公司以外的人在不付钱的情况下处理它
• 您无法在网上搜索您的错误，因为没有人知道您有这些错误
• 如果它在任意数量的团队之间共享，那么您必须将其变成一个真正的项目，包括里程碑、积压、错误数据库等。
• 如果您决定不将其纳入中心项目，则会复制代码。错误修复不会跨代码的不同副本转移。
• 您缺少现有构建系统的大量功能（例如，集成到您的 IDE 或其他软件、监控、内置报告、内置健康通知、实验室管理等）
• 如果有人知道如何将产品 X 集成到您的解决方案中，您就无法使用谷歌搜索，而无需为您做额外的工作（即编写新功能）

最终，您应该尝试添加您能想到的任何自己的优点和缺点。尤其要考虑商业观点。两种解决方案的成本都以小时/美元计。从长远来看，使用成本更低的方法，或使用混合方法（一种在短期内，另一种在长期内，并制定迁移计划和时间表）。

话虽如此，我已经在不止一个团队中推出了自己的解决方案，解决了不止一种类型的问题。我也从滚动自己的产品迁移到使用别人的产品。我发现它很有价值，并且我认为它在某些情况下可能是正确的解决方案，尤其是如果您将其用作某种短期的引导程序。