一文回顾.NET Core 基础设施演进之路

Posted 2023-03-20

参考技术A

作者丨Matt Mitchell

译者丨平川

随着.NET Core 3.0 预览版 6 的推出，我们认为有必要简要回顾一下基础设施系统的 历史 ，以及在过去一年左右时间里所做的重大改进。如果你对构建基础设施感兴趣，或者希望了解如何构建像.NET Core 这样大的产品，那么这篇文章将非常有趣。

从 3 年前开始，.NET Core 项目就与传统的微软项目有很大的不同。

我们早期的基础设施决策是围绕必要性和便利性做出的。我们使用 Jenkins 进行 GitHub PR 和 CI 验证，因为它支持跨平台的 OSS 开发。我们的官方构建版本位于 Azure DevOps（当时称为 VSTS）和 TeamCity（由 ASP 使用）中，其中有签名和其他关键的交付基础设施。我们搭配使用手动更新包依赖项版本和自动化 GitHub PR 的方法将存储库集成在一起。团队独立地构建了他们需要的工具来进行打包、布局、本地化，以及在大型开发项目中出现的所有其他常见任务。虽然不是很理想，但在某种程度上，这在早期已经运行得足够好了。随着项目从.NET Core 1.0 和 1.1 发展到 2.0 以及更高版本，我们希望投资于进一步整合的技术栈、更快的交付周期和更简单的服务。我们希望每天多次使用最新的运行时来生成一个新的 SDK。我们希望所有这些都不降低独立存储库的开发速度。

.NET Core 面临的许多基础设施方面的挑战都源于存储库结构的隔离和分布式特性。尽管多年来它变化很大，但该产品是由 20 到 30 个独立的 Git 存储库组成（ASP.NET Core 直到最近还比它多得多）。一方面，拥有许多独立的开发竖井会使这些竖井中的开发非常高效；开发人员可以在库中快速迭代，而不用担心栈的其他部分。另一方面，它使得整个项目的创新和集成效率大大降低。下面是一些例子：

在所有这些情况下，都有可能在许多层面上出现失败，从而进一步减缓进程。随着.NET Core 3.0 计划的正式启动，很明显，如果不对基础设施进行重大更改，我们就无法创建所需范围的版本。

为了减轻痛苦，我们三管齐下：

Arcade

在.NET Core 3.0 之前，有 3 到 5 种不同的工具实现分散在不同的存储库中，这和你如何计算有关。

虽然在这个世界上，每个团队都可以定制他们的工具，只构建他们需要的东西，但这确实有一些显著的缺点：

开发人员在存储库之间切换时效率更低

例如：当开发人员从 dotnet/corefx 切换到 dotnet/core-sdk 时，存储库的“语言”是不同的。她输入什么来构建和测试？日志放在哪里？如果她需要在存储库中添加一个新项目，该如何做？

需要的每个特性都要构建 N 次

例如：.NET Core 生成了大量的 NuGet 包。虽然有一些变化（例如，共享运行时包如出自 dotnet/core-setup 的 Microsoft.NETCore.App 就与 Microsoft.AspNet.WebApi.Client 等“普通”包的构建方式不同），但生成它们的步骤非常相似。遗憾的是，由于存储库在布局、项目结构等方面的差异，如何实现这些打包任务方面也产生了差异。存储库如何定义应该生成什么包、这些包中包含什么、它们的元数据等等。如果没有共享工具，团队通常更容易实现另一个打包任务，而不是重用另一个。这当然会导致资源压力。

借助 Arcade，我们努力使所有的存储库采用公共的布局、存储库“语言”和任务集（可能的话）。这并非没有陷阱。任何一种共享工具最终都会解决一些“刚刚好”问题。如果共享工具过于规范，那么在任何规模的项目中进行所需的定制都将变得非常困难，并且更新该工具也将变得非常困难。使用新的更新很容易破坏存储库。构建工具遭受了这种痛苦。使用它的存储库与它紧密耦合，以至于它不仅不能用于其他存储库，而且对构建工具进行任何更改常常会以意想不到的方式伤害用户。如果共享工具不够规范，那么存储库在使用工具时往往会出现差异，并且推出更新通常需要在每个单独的存储库中做大量的工作。那么，为什么要共享工具呢?

实际上，Arcade 尝试同时使用了这两种方法。它将公共存储库“语言”定义为脚本集（请参阅 eng/common）、公共存储库布局和作为 MSBuild SDK 推出的公共构建目标集。选择完全采用 Arcade 的存储库具有可预测的行为，使得更改很容易在存储库之间传播。不希望这样做的存储库可以从提供基本功能（如签名和打包）的各种 MSBuild 任务包中进行选择，这些任务包在所有存储库中看起来都是一样的。当我们对这些任务进行更改时，我们会尽力避免破坏性更改。

让我们来看看 Arcade 提供的主要特性，以及它们如何集成到我们更大的基础设施中。

Azure DevOps

如上所述，较大的团队通过 2.2 版本使用了一个 CI 系统的组合：

许多差异仅仅是出于必要性。Azure DevOps 不支持公共 GitHub PR/CI 验证，所以 ASP.NET Core 转向 AppVeyor 和 Travis 来填补这个空白，而.NET Core 则投资于 Jenkins。经典 Azure DevOps 对构建编排没有太多的支持，所以 ASP.NET Core 团队求助于 TeamCity，而.NET Core 团队则在 Azure DevOps 之上构建了一个名为 PipeBuild 的工具来帮助克服困难。所有这些差异都是非常昂贵的，即使是以一些不明显的方式：

当 Azure DevOps 开始推出基于 YAML 的构建管道和对公共 GitHub 项目的支持时，随着.NET Core 3.0 的启动，我们意识到，我们拥有一个独特的机会。有了这种新的支持，我们可以将现在所有的工作流从单独的系统转移到现代的 Azure DevOps 中，并对我们处理正式 CI 和 PR 工作流的方式进行一些更改。我们的工作大致如下：

到目前为止，所有主要的.NET Core 3.0 存储库都在 Azure DevOps 上进行公共 PR 和正式 CI。一个很好的例子是 dotnet/arcade 本身的正式构建 /PR 管道。

Maestro 和依赖流

.NET Core 3.0 基础架构的最后一块拼图就是我们所说的依赖流。这并不是.NET Core 独有的概念。除非它们是完全自包含的，否则大多数软件项目都包含对其他软件的某种版本化引用。在.NET Core 中，这些包通常表现为 NuGet 包。当我们需要库提供的新特性或修复时，我们通过更新项目中引用的版本号来获取这些新更新。当然，这些包也可能有对其他包的版本化引用，那些其他包可能有更多的引用，等等。这就形成了一张图。当每个存储库拉取其输入依赖项的新版本时，更改将在图中流动。

一个复杂的图

大多数软件项目的主要开发生命周期（开发人员经常从事的工作）通常涉及少量相互关联的存储库。输入依赖关系通常是稳定的，更新很少。当他们确实需要更改的时候，通常是手工操作。开发人员评估输入包的可用版本，选择合适的版本，然后提交更新。但在.NET Core 中并非如此。组件需要独立，以不同的节奏交付，并具有高效的内循环开发体验，这导致了大量具有大量相互依赖关系的存储库。相互依赖关系也形成了一个相当深的图：

Dotnet/core-sdk 存储库作为所有子组件的聚合点。我们提供了一个特定的 dotnet/core-sdk 构建，它描述了所有其他引用的组件。

我们还希望新的输出能够快速通过这个图，以便尽可能多地验证最终产品。例如，我们期望 ASP.NET Core 或.NET Core 运行时的最新片段尽可能多地在 SDK 中表现自己。本质上，这意味着定期快节奏地更新每个存储库中的依赖项。在一个足够大的图中，就像.NET Core 一样，这很快就变成了一个不可能手工完成的任务。这种规模的软件项目可能会通过以下几种方法来解决这个问题：

.NET Core 已经尝试了所有 3 种方法。我们在 1.x 的早期漂移版本。在 2.0 中实现了一定程度的自动化依赖流，并为 2.1 和 2.2 构建了一个复合构建。在 3.0 中，我们决定大量投资于自动化依赖流，放弃其他方法。我们想在一些重要的方面改进我们以前的 2.0 基础设施：

这些概念的设计使得存储库所有者不需要栈或其他团队流程的全局知识就可以参与依赖流。他们只需要知道三件事：

.NET Core 3 开发通道的流图，包括.NET Core 3 Dev 流的其他通道（例如，Arcade 的“.NET Tools Latest”）。

一致和不一致

非一致性会导致哪些问题？ 不一致性表示可能的错误状态。举个例子，让我们看看 Microsoft.NETCore.App。这个包表示特定的 API 表面。虽然存储库依赖关系图中可能会引用 Microsoft.NETCore.App 的多个版本，但 SDK 只提供一个。这个运行时必须满足可在该运行时上执行的间接引用组件（例如 WinForms 和 WPF）的所有需求。如果运行时不满足这些需求（例如破坏性 API 变更），可能就会发生故障。在不一致的图中，因为所有存储库都没有使用相同版本的 Microsoft.NETCore.App，有可能错过了一个破坏性的变更。

这是否意味着不一致始终是一种错误状态？ 不。例如，我们假设图中 Microsoft.NETCore.App 的不一致只代表一个非破坏性 JIT Bug 修复 coreclr 中的一个变更。从技术上讲，微软没有必要在图中的每一点上获取新的 Microsoft.NETCore.App。只需针对新的运行时交付相同的组件就足够了。

如果不一致只是偶尔的问题，那么我们为什么还要努力才能推出一致的产品呢？ 因为很难确定什么时候不一致无关紧要。简单地将一致性作为所需状态进行交付，要比试图理解不一致的组件之间的任何语义差异对最终产品所产生的影响更容易。这是可以做到的，但是从构建频率来说，它是时间密集型的，并且容易出错。强制将一致性作为默认状态更安全。

依赖流的好处

随着存储库图越来越大，所有这些自动化和跟踪都有许多明显的优势。它为我们解决日常生活中的实际问题提供了很多可能性。虽然我们刚刚开始 探索 这个领域，但系统已经可以开始回答一些有趣的问题，并处理以下场景：

随着.NET Core 3.0 逐步结束，我们正在寻找新的领域来改进。虽然计划仍处于（非常）初期的阶段，但我们预计在以下几个关键领域进行投资：

多年来，我们已经对基础设施进行了相当大的改进。从 Jenkins 到 Azure DevOps，从手工依赖流到 Maestro++，从许多工具实现到一个工具实现，我们对.Net Core 3.0 所做的改变是一个巨大的进步。我们已经为开发和交付比以往任何时候都更可靠、更令人兴奋的产品做好了准备。

原文链接：

https://devblogs.microsoft.com/dotnet/the-evolving-infrastructure-of-net-core/