原文：Matt Mitchell

翻譯：Edi Wang

隨著 .NET Core 3.0 Preview 6 的推出，我們認(rèn)為簡(jiǎn)要了解一下我們基礎(chǔ)設(shè)施系統(tǒng)的歷史以及過(guò)去一年左右所做的重大改進(jìn)會(huì)很有用。

如果您對(duì)構(gòu)建基礎(chǔ)結(jié)構(gòu)感興趣，或者想要了解我們?nèi)绾螛?gòu)建與 .NET Core 一樣大的產(chǎn)品，那么此帖子將很有趣。它不描述應(yīng)在下一個(gè)應(yīng)用程序中使用的新功能或示例代碼。如果您喜歡這些類型的帖子，請(qǐng)告訴我們。我們有幾個(gè)類似計(jì)劃，但希望知道此類信息是否對(duì)你有幫助。

一點(diǎn)歷史

.NET Core 項(xiàng)目始于 3 多年前，與傳統(tǒng)的微軟項(xiàng)目相比，這是一個(gè)重大轉(zhuǎn)變。

• 在 GitHub 上公開(kāi)開(kāi)發(fā)

• 多個(gè)集成在一起的獨(dú)立 Git 倉(cāng)庫(kù)，而不是一個(gè)單獨(dú)的龐大倉(cāng)庫(kù)

• 面向多個(gè)平臺(tái)

• 其組件可能以多個(gè)"車輛"的形式發(fā)布(例如，Roslyn 作為 Visual Studio 和 SDK 的組件發(fā)布)

我們?cè)缙诘幕A(chǔ)設(shè)施決策是圍繞必要性和權(quán)宜之計(jì)做出的。我們使用 Jenkins 進(jìn)行 GitHub PR 和 CI 驗(yàn)證，因?yàn)樗С挚缙脚_(tái) OSS 開(kāi)發(fā)。我們的官方版本位于 Azure DevOps(當(dāng)時(shí)稱為 VSTS)和 TeamCity(由ASP.NET核心使用)，其中存在簽名和其他關(guān)鍵運(yùn)輸基礎(chǔ)結(jié)構(gòu)。

我們使用手動(dòng)更新包依賴項(xiàng)版本和有點(diǎn)自動(dòng)化的 GitHub PRs 的組合將存儲(chǔ)庫(kù)集成在一起。團(tuán)隊(duì)獨(dú)立構(gòu)建了包裝、布局、本地化和所有其他工具所需的工具，這些在大型開(kāi)發(fā)項(xiàng)目中出現(xiàn)的任務(wù)。

雖然并不理想，但從某種意義上說(shuō)，這在早期就足夠有效了。隨著項(xiàng)目從 .NET Core 1.0 和 1.1 發(fā)展到 2.0 及之后，我們希望投資一個(gè)更加集成的開(kāi)發(fā)棧、更快的發(fā)布節(jié)奏和更簡(jiǎn)單的服務(wù)。我們希望生成一個(gè)新的帶有最新運(yùn)行時(shí)的 SDK，每天發(fā)布多次。我們希望在不降低獨(dú)立存?zhèn)}庫(kù)的開(kāi)發(fā)速度的情況下進(jìn)行所有這些工作。

.NET Core 面臨的許多基礎(chǔ)結(jié)構(gòu)挑戰(zhàn)源于倉(cāng)庫(kù)結(jié)構(gòu)的隔離、分布式性質(zhì)。雖然多年來(lái)它變化很大，但該產(chǎn)品由 20-30 個(gè)獨(dú)立 Git 倉(cāng)庫(kù)(ASP.NET Core 直到最近還擁有更多)組成。一方面，有許多獨(dú)立的開(kāi)發(fā)孤島往往使這些孤島的開(kāi)發(fā)非常高效：開(kāi)發(fā)人員可以在庫(kù)中快速迭代，而不必?fù)?dān)心技術(shù)棧的其余部分。另一方面，它使整個(gè)項(xiàng)目的創(chuàng)新和集成效率降低得多。一些示例：

• 如果我們需要推出新的簽名或打包功能，那么在使用不同工具的眾多獨(dú)立存儲(chǔ)庫(kù)中執(zhí)行此操作的成本非常高。

• 跨棧移動(dòng)更改速度很慢且成本高昂。對(duì)于"低"位置棧中的修復(fù)和功能(例如 corefx 庫(kù))可能在幾天內(nèi)在 SDK(棧的"頂部")中看不到。如果我們?cè)?dotnet/corefx 中進(jìn)行修復(fù)，則必須構(gòu)建該更改，并將新版本流入引用它的任何上棧組件(例如 dotnet/core 設(shè)置和ASP.NET Core)，在那里將測(cè)試、提交和構(gòu)建該更改。然后，這些新組件將需要將這些新輸出進(jìn)一步向上流，依此類推，直到達(dá)到頭。

譯者注：[棧] 的原文為 Stack，不是指棧數(shù)據(jù)結(jié)構(gòu)，而是描述組成整個(gè).NET Core的各種組件，它們一起，是一個(gè)棧。

在所有這些情況下，在許多層面上都有失敗的機(jī)會(huì)，進(jìn)一步減緩了這一進(jìn)程。隨著 .NET Core 3.0 規(guī)劃的認(rèn)真開(kāi)始，很明顯，如果不對(duì)我們的基礎(chǔ)結(jié)構(gòu)進(jìn)行重大更改，我們就無(wú)法創(chuàng)建我們想要的范圍的產(chǎn)品發(fā)布。

三管齊下的方法

我們開(kāi)發(fā)了一個(gè)三管齊下的方法來(lái)減輕我們的痛苦:

• 共享工具(又名Arcade) – 在我們的存儲(chǔ)庫(kù)中投資共享工具。

• 系統(tǒng)整合 (Azure DevOps) - 拋棄 Jenkins 并擁抱集成 GitHub CI 的 Azure DevOps。將我們的官方版本從經(jīng)典 VSTS 時(shí)代的流程移動(dòng)到現(xiàn)代配置即代碼。

• 自動(dòng)依賴項(xiàng)流和發(fā)現(xiàn) (Maestro) – 顯式跟蹤依賴項(xiàng)，并快速更新它們。

Arcade

在 .NET Core 3.0 之前，有 3-5 種不同的工具實(shí)現(xiàn)分散在不同的倉(cāng)庫(kù)中，具體取決于您計(jì)數(shù)的方式。

• 核心運(yùn)行時(shí)倉(cāng)庫(kù) (dotnet/coreclr, dotnet/corefx 以及dotnet/core-setup) 包含 dotnet/buildtools 工具。

• ASP.NET核心的倉(cāng)庫(kù)?有 aspnet/KoreBuild

• 使用 ?Repo Toolset 的各種倉(cāng)庫(kù)，如dotnet/symreader

• 其他幾個(gè)孤立的倉(cāng)庫(kù)具有獨(dú)立的實(shí)現(xiàn)。

雖然在這個(gè)世界上，每個(gè)團(tuán)隊(duì)可以自定義他們的工具，并只構(gòu)建他們需要的，但它確實(shí)有一些顯著的缺點(diǎn)：

開(kāi)發(fā)人員在倉(cāng)庫(kù)之間奔波的效率較低

示例:當(dāng)開(kāi)發(fā)人員從 dotnet/corefx 跑到 dotnet/core-sdk 時(shí)，存儲(chǔ)庫(kù)的"語(yǔ)言"是不同的。她鍵入什么來(lái)編譯和測(cè)試?日志放在何處?如果她需要向回購(gòu)中添加新項(xiàng)目，這是如何做到的?

每個(gè)必需的功能都被開(kāi)發(fā) N 次

示例：.NET Core 產(chǎn)生成噸的 NuGet 包。雖然有一些變化(例如，使用 dotnet/core-setup 生成的 Microsoft.NETCore.App 共享運(yùn)行時(shí)包，與 Microsoft.AspNet.WebApi.Client 等"普通"軟件包的構(gòu)建方式不同)，但生成它們的步驟相當(dāng)類似。

遺憾的是，由于倉(cāng)庫(kù)的布局、項(xiàng)目結(jié)構(gòu)等存在分歧，因此這些打包任務(wù)需要實(shí)現(xiàn)的方式不同。存儲(chǔ)庫(kù)如何定義應(yīng)生成哪些包、這些包中的內(nèi)容、其元數(shù)據(jù)等。如果沒(méi)有共享工具，團(tuán)隊(duì)通常更容易實(shí)現(xiàn)另一個(gè)打包任務(wù)，而不是重用另一個(gè)打包任務(wù)。這當(dāng)然對(duì)資源造成壓力。

通過(guò) Arcade，我們努力將所有倉(cāng)庫(kù)放在一個(gè)通用布局、倉(cāng)庫(kù)"語(yǔ)言"和任務(wù)集(如果可能的話)。這并非沒(méi)有陷阱。任何類型的共享工具最終都解決了一些"金發(fā)（Goldilocks）"問(wèn)題。如果共享工具過(guò)于規(guī)范，則任何重大規(guī)模的項(xiàng)目所需的自定義類型將變得困難，并且更新該工具變得非常困難。

使用新更新很容易破壞倉(cāng)庫(kù)。BuildTools 因此遭受損失。使用它的倉(cāng)庫(kù)與它緊密耦合，以至于它不僅不能用于其他倉(cāng)庫(kù)，而且在 BuildTools 中的任何更改通常以意想不到的方式使使用者崩潰。如果共享工具的規(guī)范性不夠，則存儲(chǔ)庫(kù)在工具的使用上往往會(huì)出現(xiàn)偏差，而推出更新通常需要在每個(gè)單獨(dú)的存儲(chǔ)庫(kù)中進(jìn)行大量工作。在這一點(diǎn)上，為什么我們還需要共享工具？

Arcade 實(shí)際上嘗試同時(shí)使用這兩種方法。它將通用倉(cāng)庫(kù)"語(yǔ)言"定義為一組腳本(請(qǐng)參閱 eng/common)、通用倉(cāng)庫(kù)布局以及作為 MSBuild SDK 推出的通用生成目標(biāo)集。選擇完全采用 Arcade 的倉(cāng)庫(kù)具有可預(yù)測(cè)的行為，這使得更改易于跨倉(cāng)庫(kù)推出。不希望這樣做的倉(cāng)庫(kù)可以從各種提供基本功能(如簽名和打包)的 MSBuild 任務(wù)包中進(jìn)行選擇，這些功能在所有存?zhèn)}庫(kù)看起來(lái)都相同。當(dāng)我們對(duì)這些任務(wù)進(jìn)行更改時(shí)，我們會(huì)盡力避免重大更改。

讓我們來(lái)看看 Arcade 提供的主要功能，以及它們?nèi)绾渭傻轿覀兏蟮幕A(chǔ)架構(gòu)中。

常規(guī)編譯任務(wù)包

這些是 MSBuild 任務(wù)的基本層，可以獨(dú)立使用，也可以作為 Arcade SDK 的一部分使用。他們是"付費(fèi)才能玩"("Arcade"因此得名)。它們提供了大多數(shù) .NET Core 倉(cāng)庫(kù)中所需的一組通用功能：

簽名：

Microsoft.DotNet.SignTool

發(fā)布編譯產(chǎn)物(跨倉(cāng)庫(kù)訂閱源)：

Microsoft.DotNet.Build.Tasks.Feed

打包：

Microsoft.DotNet.Build.Tasks.Packaging

常見(jiàn)的倉(cāng)庫(kù)目標(biāo)和行為

這些是作為稱為"Arcade SDK"的 MSBuild SDK 的一部分提供的。通過(guò)利用它，倉(cāng)庫(kù)選擇加入默認(rèn)的 Arcade 編譯行為、項(xiàng)目和項(xiàng)目布局等。

通用倉(cāng)庫(kù)"語(yǔ)言"

一組使用依賴項(xiàng)流在所有 Arcade 存儲(chǔ)庫(kù)之間同步的通用腳本文件(稍后將介紹更多)。這些腳本文件引入了采用 Arcade 的倉(cāng)庫(kù)的通用"語(yǔ)言"。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，在這些存儲(chǔ)庫(kù)之間移動(dòng)變得更加無(wú)縫。此外，由于這些腳本在存儲(chǔ)庫(kù)之間同步，因此對(duì) Arcade 存儲(chǔ)庫(kù)中的原始副本進(jìn)行新更改可以快速將新功能或行為引入完全采用共享工具的存儲(chǔ)庫(kù)。

共享 Azure DevOps 作業(yè)和步驟模板

雖然定義公共存儲(chǔ)庫(kù)"語(yǔ)言"的腳本主要針對(duì)與人交互，但 Arcade 還有一組 Azure DevOps 作業(yè)和步驟模板，允許 Arcade 存儲(chǔ)庫(kù)與 Azure DevOps CI 系統(tǒng)進(jìn)行接口。與常規(guī)編譯任務(wù)包一樣，步驟模板構(gòu)成了一個(gè)基礎(chǔ)層，幾乎每個(gè)倉(cāng)庫(kù)都可以使用(例如，發(fā)送生成遙測(cè))。作業(yè)模板形成更完整的單元，使存儲(chǔ)庫(kù)能夠減少對(duì) CI 流程細(xì)節(jié)的擔(dān)心。

遷移到 Azure DevOps

如上所述，更大的團(tuán)隊(duì)在 2.2 版本中使用了 CI 系統(tǒng)的組合：

• AppVeyor 和?Travis 用于 ASP.NET Core 的 GitHub PR

• TeamCity 用于官方 ASP.NET 編譯

• Jenkins 用于其他 .NET Core 的 GitHub PR 和滾動(dòng)驗(yàn)證。

• 經(jīng)典(非 YAML)Azure DevOps 工作流用于官方的非ASP.NET Core項(xiàng)目
  

許多區(qū)別只是為了必要性。Azure DevOps 不支持公共 GitHub PR/CI 驗(yàn)證，因此ASP.NET Core 轉(zhuǎn)向 AppVeyor 和 Travis 來(lái)填補(bǔ)空白，而 .NET Core 則投資 Jenkins。經(jīng)典 Azure DevOps 對(duì)構(gòu)建業(yè)務(wù)流程沒(méi)有很多支持，因此ASP.NET Core 團(tuán)隊(duì)轉(zhuǎn)向 TeamCity，而 .NET Core 團(tuán)隊(duì)在 Azure DevOps 上構(gòu)建了名為 PipeBuild 的工具來(lái)提供幫助。所有這些分歧都非常昂貴，即使在一些不明顯的方式：

• 雖然 Jenkins 是靈活的，但維護(hù)大量任務(wù)(6000-8000)是一項(xiàng)嚴(yán)肅的工作。

• 在經(jīng)典 Azure DevOps 之上構(gòu)建我們自己的業(yè)務(wù)流程需要很多折衷。已檢查的管道作業(yè)描述并非真正是人類可讀的(它們剛剛導(dǎo)出了手動(dòng)創(chuàng)建的生成定義的 json 描述)，密鑰管理很丑陋，在我們嘗試處理生成要求的廣泛差異。

• 當(dāng)正式編譯與夜間（nightly）驗(yàn)證與 PR 驗(yàn)證過(guò)程在不同的系統(tǒng)中定義時(shí)，共享邏輯就變得困難。開(kāi)發(fā)人員在進(jìn)行流程更改時(shí)必須額外小心，因?yàn)楹苋菀妆Ｎ覀冊(cè)谝粋€(gè)特殊的腳本文件中定義了 Jenkins PR 作業(yè)，TeamCity 有許多手動(dòng)配置的作業(yè)，AppVeyor 和 Travis 使用自己的 yaml 格式，Azure DevOps 具有我們?cè)谒蠘?gòu)建的模糊自定義系統(tǒng)。很容易在 PR 中更改生成邏輯并中斷官方的 CI 構(gòu)建。為了緩解這種情況，我們確實(shí)努力在正式 CI 和 PR 構(gòu)建中通用的腳本中保留盡可能多的邏輯，但差異總是隨著時(shí)間的推移而逐漸減少。某些差異(如在構(gòu)建環(huán)境中)基本上不可能完全消除。

• 更改工作流的做法差別很大，而且往往難以理解。開(kāi)發(fā)人員了解了 Jenkins 用于更新 PR 邏輯的 netci.groovy 文件，但并未轉(zhuǎn)換為用于正式 CI 構(gòu)建的 PipeBuild json 文件。因此，對(duì)系統(tǒng)的知識(shí)通常被隔離到少數(shù)團(tuán)隊(duì)成員中，這在大型組織中并不理想。

當(dāng) Azure DevOps 開(kāi)始推出基于 YAML 的構(gòu)建管道，并在 .NET Core 3.0 開(kāi)始啟動(dòng)時(shí)對(duì)公共 GitHub 項(xiàng)目的支持，我們認(rèn)識(shí)到我們具有獨(dú)特的機(jī)會(huì)。有了這種新的支持，我們可以將所有現(xiàn)有的工作流從單獨(dú)的系統(tǒng)移動(dòng)到現(xiàn)代 Azure DevOps 中，還可以對(duì)如何處理正式的 CI 和 PR 工作流進(jìn)行一些更改。我們從以下工作大致概要出發(fā)：

• 將所有邏輯保存在代碼中，在 GitHub 中。隨時(shí)隨地使用 YAML 管道。

• 有一個(gè)公開(kāi)和私有項(xiàng)目。

  • 公開(kāi)項(xiàng)目將通過(guò) GitHub 存儲(chǔ)庫(kù)和 PR 運(yùn)行所有公共 CI，正如我們始終擁有的

  • 私有項(xiàng)目將運(yùn)行官方 CI 是我們需要進(jìn)行的任何私人更改的場(chǎng)所，在存儲(chǔ)庫(kù)中匹配公共 GitHub 倉(cāng)庫(kù)

  • 只有私有項(xiàng)目才能訪問(wèn)受限制的資源。

• 在官方 CI 和 PR 生成之間共享相同的 YAML。使用模板表達(dá)式來(lái)區(qū)分公共項(xiàng)目和私有項(xiàng)目，其中行為必須分，或者僅訪問(wèn)私有項(xiàng)目中可用的資源。雖然這通常使整個(gè) YAML 定義更混亂一些，但這意味著：

  • 進(jìn)行流程更改時(shí)，爆掉的可能性較低。

  • 開(kāi)發(fā)人員只需更改一組位置來(lái)更改官方 CI 和 PR 流程。

• 為常見(jiàn)任務(wù)構(gòu)建 Azure DevOps 模板，以將樣板 YAML 的重復(fù)降至最低，并啟用使用依賴項(xiàng)流輕松推出更新(例如遙測(cè))。
  

到目前為止，所有主 .NET Core 3.0 倉(cāng)庫(kù)都在 Azure DevOps 上，用于其公共 PR 和官方 CI。一個(gè)很好的例子管道是 dotnet/arcade 自己本身的官方編譯/PR管道。

譯者注：Arcade 自己的編譯管道 https://github.com/dotnet/arcade/blob/master/azure-pipelines.yml

（文章翻譯未完待續(xù)）

總結(jié)

以上是生活随笔為你收集整理的译 | .NET Core 基础架构进化之路（一）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。