.NET的构建和发布方式，是否再次迎来革新？

原文 | Matt Mitchell 翻译 | 郑子铭 在我写完上一篇关于 .NET 如何构建和发布的文章后，我谨慎地乐观地认为，我不需要再写一篇了。或者至少不需要再写一篇关于我们如何构建和发布的文章。这个问题已经彻底解决了。.NET 做到了！我们在分布式代码库开发和快速构建产品发布的能力之间找到了平衡。恭喜大家，现在基础设施团队可以专注于其他事情了。安全、跨公司标准化、支持构建新产品功能等等。所有这些好东西。 一年半后…… 我们正在询问每月发布 3-4 个主要版本（每个版本包含十几个 .NET SDK 版本）需要多少成本，还要保持他们的工程系统更新。另外，我们想在下周的版本中加入一个紧急修复，所以我今天可以提交代码，让团队今晚验证吗？应该不难吧？还有，我想对一个新的跨栈功能进行一些原型设计……我该如何实现呢？ 答案大多令人沮丧： “这会花费很多钱，而且随着时间的推移情况会越来越糟。 ” “我觉得我们没有足够的时间来修复这个问题，我只能估计构建需要多长时间，但至少需要36个小时才能交给验证部门。也许更久？ ” “我相信我们能够维持如此庞大的基础设施运转，但我们会慢慢被不断更新换代的成本压垮。 ” “拥有完整的技术栈对你来说有多重要？搭建起来需要一些时间。 ” 这些并非我们想要给出的答案。因此，我们不得不重新审视问题，寻找解决方案。 这篇博文主要介绍统一构建项目：.NET 通过将产品构建迁移到“虚拟单体”代码库，并将构建过程整合为一系列“垂直构建”，同时仍然允许贡献者在单体代码库之外工作，从而解决诸多问题。我将简要回顾 .NET 生命周期中产品构建的历程。我会重点介绍我们在将分布式产品构建模型应用于单个产品时所吸取的经验教训，特别是其在开销和复杂性方面的不足。最后，我将深入探讨统一构建及其基础技术——Linux 发行版源代码构建。我们将审视这种新的产品构建方法以及我们所取得的成果。 我们怎么会走到这一步？这可不是我精心打造的基础设施。 .NET 诞生于 2015-2016 年，源于 .NET Framework 和 Silverlight 的闭源基础架构。随着我们逐步完善其组件以供外部使用，.NET 也逐步开源。当时，我们按照惯例将其拆分为多个代码库。CoreCLR 代表基础运行时，CoreFX 代表库，Core-Setup 代表打包和安装。随后，ASP.NET Core 和 EntityFramework Core 以及带有 CLI 的 SDK 也相继问世。在接下来的几个版本中，产品进行了重大改进，引入了共享框架，WindowsDesktop 也加入了其中。代码库更多，复杂性也随之增加。 需要理解的是，.NET 是一个在相互依赖的独立代码库中开发的产品，但需要在相对较短的时间内将它们组合起来才能发布。从理论上讲，该产品的“依赖关系图”与任何开源生态系统都非常相似。一个代码库生成一些软件组件，将其发布到公共注册表中，下游用户依赖于这个新组件，并发布他们自己的更新。这是一个生产者-消费者模型，其中变更通过一系列拉取->构建->发布操作在“全局”依赖关系图中传播。这种模型高度分布式且高效，但在时间效率方面未必出色。它使软件供应商和代码库所有者能够对其流程和进度安排拥有相当大的自主权。然而，尝试将这种方法应用于像 .NET 这样使用独立但相互依赖的代码库来表示其组件的产品，存在重大缺陷。 我们不妨称之为“分布式产品构建方法”。为了了解为什么这种方法使用起来比较困难，让我们来看看安全版本发布的过程。 例如：安全服务 考虑发布安全补丁。假设在 .NET 运行时库的某个地方发现了一个安全漏洞。由于 .NET 源自 .NET Framework，假设该安全漏洞也存在于 .NET Framework 4.7.2 中。那么，.NET 的安全更新必须与 .NET Framework 的更新同步发布，否则两者之间就会发生零日漏洞冲突，这一点至关重要。.NET 拥有众多由微软管理的发布渠道，例如 Microsoft Update、我们的 CDN、Linux 和容器包注册表、nuget.org、Visual Studio、Azure Marketplace 等等。这给发布时间带来了一定的限制。我们需要确保发布时间的可预测性。 .NET 的开发结构与典型的开源生态系统非常相似。.NET 运行时、.NET SDK、ASP.NET Core 和 Windows Desktop 共享框架由不同的团队开发，但彼此之间有着大量的协作。有时，它们的开发方式就像是独立的产品。.NET 运行时是产品的基础。ASP.NET Core 和 Windows Desktop 都构建于其之上。