ModularPipelines：用 C# 写 CI/CD，把 YAML 的痛点留给 YAML

YAML 流水线的痛点，C# 能解决什么

ModularPipelines 的出发点很直接：YAML 流水线难以本地调试，变量名拼写错误要等 CI 跑一轮才能发现，复制粘贴逻辑容易漏改，换 CI 平台等于重写。这些问题在大型项目里尤其明显。这个框架把流水线写成 C# 代码，于是你获得编译期类型检查、IDE 的智能提示和重构支持，还能在本地设置断点逐步执行。它面向的是已经用 .NET 写应用、但流水线还停留在 YAML 的团队。对于这类人，流水线不再是配置文件的附属品，而是程序的一部分。

模块、依赖属性和自动并行化

核心概念是模块。每个模块继承 Module<T> 或 Module，并实现 ExecuteAsync 方法。模块之间用 [DependsOn<OtherModule>] 声明依赖，框架根据这些属性构建执行图，自动决定哪些模块可以并行运行。文档强调这是自动并行化，不需要手动编排并行任务。模块可以返回强类型结果，后续模块通过 context 获取，避免了共享可变状态的混乱。这个设计类似构建工具里的任务依赖，但用 C# 的特性（泛型、特性、异步）来表达，比 YAML 的键值对更严谨。

从模板生成到手动配置，两种起步方式

快速开始有两种路径。第一种用模板：dotnet new install ModularPipelines.Templates，然后 dotnet new modularpipeline -n MyPipeline --solution ../MySolution.slnx --publish-project ../src/MyApp/MyApp.csproj，生成的项目自带 restore、build、test、publish 四个模块，依赖关系已经写好，直接 dotnet run 就能跑。第二种是往现有项目加包：dotnet add package ModularPipelines 和 dotnet add package ModularPipelines.DotNet，然后在 Program.cs 里写 var builder = Pipeline.CreateBuilder(args); await builder.RunAsync();。注意第二种方式需要自己配置模块注册，文档没有给出完整的注册代码，实际使用时要查文档或模板源码。

Roslyn 分析器：把错误挡在编译之前

框架内置 Roslyn 分析器，能在编译期发现四类常见错误：调用 GetModule<T>() 时缺少 [DependsOn] 特性、模块间循环依赖、忘记 await 模块结果、误用 Console.Write 而绕过日志系统。这些检查对新手尤其有价值，因为模块依赖写错通常要运行时才能发现，而分析器把反馈时间缩短到编译瞬间。不过分析器的覆盖范围有限，它只能检查框架能静态识别的问题，比如模块间引用，但无法验证模块内部逻辑的正确性。

秘密混淆和依赖注入，解决实际运维问题

文档提到两个实用特性：秘密自动混淆和完全依赖注入。秘密混淆指的是日志输出时自动隐藏 API 密钥之类的敏感值，避免构建日志泄露凭据。依赖注入则和 ASP.NET Core 的方式一致，可以注入服务、配置和秘密，还能在测试时 mock 依赖。这两个特性都是 YAML 流水线难以优雅实现的，尤其是秘密管理，很多 CI 平台只能靠手动遮蔽或外部工具。但依赖注入的代价是概念负担，新手需要理解 DI 容器和生命周期，这比写一段 YAML 复杂。

集成包的边界：它们是 CLI 的封装，不是原生 API

仓库列出了大量集成包，比如 ModularPipelines.AmazonWebServices、ModularPipelines.Docker、ModularPipelines.Azure，还有 Java 相关的 ModularPipelines.Java（Maven、Gradle）。这些包提供强类型封装，但本质上是对命令行工具的包装，比如调用 dotnet publish 或 docker build。这意味着你仍然依赖本机安装对应 CLI，而且 CLI 的版本差异可能影响行为。对于没有现成集成包的工具，你得自己写 Process 调用，这会失去一部分类型安全。另一个限制是：如果 CI 平台没有对应的 CLI 或 REST 封装，迁移到 ModularPipelines 就需要额外开发。

替代方案：GitHub Actions 与 Nuke 的差异

最常见的替代是 GitHub Actions 或 Azure Pipelines 的 YAML。它们的优势是平台原生支持，有现成的托管运行器和市场插件，YAML 的简单场景下上手极快。但 YAML 无法本地调试，类型安全为零，换平台要重写。另一个值得对比的是 Nuke（也是一个 C# 构建框架），它同样用 C# 写构建逻辑，但更侧重于构建脚本，而不是完整的 CI/CD 编排。Nuke 的依赖图也是基于特性声明，但它的集成方式更偏向生成 shell 脚本，而 ModularPipelines 强调在 CI 代理上直接运行。选择的关键在于：你是想摆脱 YAML，还是只想改进构建脚本。

维护成本与许可证，采用前需要确认的事

项目使用 MIT 许可证，可以自由使用和修改，没有商业限制。但要注意的是，框架本身还在快速迭代，最近三个月内发布了 v3.2.8、v3.1.90、v3.1.6 三个版本，API 可能变化，升级时需要留意破坏性变更。文档和模板是主要学习资源，但 README 里没有提供详细的 API 参考，深度使用可能需要阅读源码。框架的依赖包很多，每个集成包独立发布，这意味着你需要跟踪多个包的版本。如果你的团队没有 .NET 开发经验，这个框架的学习曲线会比 YAML 陡峭得多，因为它要求你理解异步编程、泛型和依赖注入。

编辑结论

如果你的团队已经熟悉 C# 和 .NET，并且受够了 YAML 流水线的排错循环，ModularPipelines 值得一试。它把流水线变成可调试、可测试的代码，依赖注入和模块间数据传递也确实能减少样板代码。但如果你主要使用 JavaScript、Python 或 Go 技术栈，或者你的 CI 平台是 Jenkins 这类以脚本为中心的体系，这个框架的收益就很有限，反而会引入一层新的抽象。在采用之前，先验证两件事：一是你的 CI 平台能否通过命令行工具或 REST API 被覆盖，因为 ModularPipelines 的集成包本质上是 CLI 的封装；二是你的团队是否愿意接受流水线代码的维护成本，毕竟它不再是声明式文件，而是需要编译和测试的应用程序代码。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes