在 Azure DevOps 中为 ASP.NET Core API 配置构建管道

Joao Grassi — 一位 .NET 开发者、前端爱好者以及 Sentry 的朋友 — 非常喜欢 .NET，最近他试图带一位朋友进入 .NET 开发的“黑暗面”。为了赢得一点好感，他决定创建一个使用 Azure DevOps 的小型示例项目。

在他开始时，他发现文档中很难找到有用的信息（例如如何控制构件名称）。项目完成后，他想：如果有一个地方可以保存这些信息，以免每次都为搜索而烦恼，那该多好啊？

毫无疑问，云开发正变得越来越流行，并且对于许多人来说，它是构建、部署和托管 Web 应用程序的默认方式。但由于与本文无关的原因，我们中的许多人仍然在没有云的环境中进行日常工作。

在避免云开发并利用其所有优点方面，真的没有借口。一个特别的好处是能够配置一个构建管道，该管道可以构建项目、确保一切编译正常，并检查测试是否通过。构建管道还会生成构件（Artifacts），即包含应用程序代码的 .zip 文件，这些文件允许您将应用程序发布到 Azure 或其他云服务。

我们将做什么

在这篇文章中，我想向您展示如何

1. 在 Azure 上创建 Linux 上的 App Service。
2. 在 Azure DevOps（以前称为 VSTS）上设置构建管道。
3. 将 Azure DevOps 与 Sentry 集成。

一些要求

为了避免这篇文章过长，我将假设您已经设置好了以下内容：

• 在 Azure DevOps 中拥有一个组织账户：请按照此处的步骤操作。
• 在 Azure DevOps 中为您的项目创建一个 git 仓库：此处和此处。
• 实际代码 — 一个正在运行的 ASP.NET Core API（最简单的初始模板（ValuesController），可以通过 VS 或命令行创建）。

完成后，您应该已经配置好本地和 Azure DevOps 中的 git 仓库，以便能够推送/拉取内容。“Repos”菜单在 Azure DevOps 中的外观如下

在 Azure 中创建 App Service

我也不打算详细介绍如何在 Azure 中创建 App Service，因为这已经之前讲得更清楚了，但我还是想通过 Azure 门户简要地向您展示一下。那么，我们开始吧。

1. 登录您的 Azure 门户（创建免费账户后）。
2. 转到：App Services → Add (+) → Web App → Create

1. 填写所有字段，如下图所示

1. 点击 Create！

在 Azure DevOps 中创建构建

现在您已经创建了 git 仓库和 App Service，是时候在 Azure DevOps 中配置构建管道了。这非常容易，并且与 ASP.NET Core 集成良好，因此我们将使用大部分预定义的值。

1. 导航到：Pipelines → + New → New build pipeline。
2. 在下一页，您需要选择构建的源，在本例中是 Azure Repos Git。但正如您所见，您可以连接到其他 Git 提供商，如 GitHub。选择您的项目和仓库（它可能已经预选好了），然后点击 Continue。

1. 在“Select a template”页面，选择 ASP.NET Core，然后点击 Apply（您也可以搜索它）。
2. 下一页是我们将配置构建步骤的地方。由于我们选择了 ASP.NET Core 模板，Azure DevOps 已经为我们提供了一组预定义的步骤。我对这些步骤进行了一些实验，并进行了一些更改。我将逐一解释这些步骤。

管道 - 构建管道

最上面的“框”是：Pipeline。在那里，您可以设置构建管道的名称、它运行在哪个代理上以及要构建/还原的项目。填写 Build name 和 Agent“Hosted VS2017”。其余的保持不变，我们稍后会更改它们。

Restore

自从 .NET Core 2.0 之后，我们不需要执行还原，但在 CI 构建中，将其分开是个好主意，因为我们可以衡量每个步骤花费了多少时间。

确保选择 .NET Core 版本为 2.*。我们唯一要在此处更改的是 Path to project(s)。默认情况下，它会尝试还原所有项目。在我们的简单 API 中，我们只需要还原 Api 项目。

1. 在 Path to project(s) 字段中，点击旁边的链接图标，然后点击Unlink。这将使我们能够更改该字段。
2. 将其更改为您的主 API .csproj 文件的路径。在我的例子中是：**/StarWars.Api.csproj

现在它会为 API 项目执行还原，如果 API 依赖于解决方案中的其他项目，它也会为那些项目进行还原。

构建

在 Build 步骤中，我们将更改 3 项：Path to project(s)、Arguments 和 Working Directory。

1. 再次点击 Path to project(s) 旁边的链接图标，并像在 restore 步骤中一样，将其指向您的 API 的 .csproj 文件。
2. 在 Arguments 步骤中添加一个 --no-restore 标志，以避免 dotnet build 再次执行还原：--configuration $(BuildConfiguration) --no-restore
3. 展开 Advanced 菜单，并将您的 API 项目的文件夹添加到 Working Directory。在我的例子中，是：src/StarWars.Api

我一直使用这种格式来组织我的项目（我相信大多数项目也是如此）。

您不必拥有此结构，但我认为它运行良好且组织有序。例如，我喜欢将所有测试项目放在 src 文件夹的同一层级下的 test 文件夹中。

测试

在 Test 步骤中，我指定要测试的项目。一个大型解决方案通常有多个项目，您可能也会为每个项目单独构建。在这种情况下，指定要运行的每个测试项目更有意义。

Publish (发布)

Publish 步骤是我第一次尝试设置构建管道时遇到的难题。您可以大致使用默认设置，它也能正常工作。问题是：它发布的构件名称非常奇怪。例如

使用默认选项，我无法找到更好的构件名称。构件名称应该有意义，并包含构建编号等信息。我最终使用了以下步骤来更改构件名称。

1. 取消选中 Publish Web Projects 复选框，然后再次添加 API 项目的路径：**/StarWars.Api.csproj
2. 在 Arguments 中粘贴此内容：-c $(BuildConfiguration) -o $(Build.StagingDirectory)/ci-build --no-build

-c 命令会告诉 Azure DevOps 使用 BuildConfiguration 变量。默认情况下，该变量设置为 release，但您可以在此页面的 Variables 选项卡中进行更改。

-o 参数指定发布输出的位置。在我的示例中，我指定将其发布到 Azure DevOps 中预定义的 Build.StagingDirectory 并且发布到 ci-build 文件夹。如果您不指定 ci-build 文件夹，它会创建一个文件夹。

当然，既然我们已经构建了项目，就无需再次构建。所以，跳过 --no-build。

1. 我还取消选中了 Zip Published Projects 和 Add project name to publish path。我们将在下一步创建自己的 zip 文件。
2. 再次展开 Advanced 菜单，并将 Working folder 设置为与 Build 步骤中相同的值。

这些步骤应该会产生类似这样的结果

归档发布输出

现在我们已经有了 dotnet publish 命令的输出，我们需要将其归档。

1. 点击 Phase 1 旁边的+ 按钮。
2. 选择 Archive Files 选项。如果未显示，您可以搜索它。
3. 为步骤选择一个名称，例如：Archive Publish Output。
4. 在 Root folder 或 file to archive 中添加之前配置的 publish 输出文件的路径：$(Build.StagingDirectory)/ci-build
5. 我不想在 zip 文件中预置根文件夹名称，因为我希望我的文件位于根目录。所以我取消选中了 Prepend root folder name to archive paths 复选框。
6. 在 Archive file to create 中，我们配置 zip 构件的名称。我将其更改为：$(Build.ArtifactStagingDirectory)/starwars-api.$(Build.BuildNumber).zip。如果需要，请务必勾选Replace existing archive。

此步骤会获取 publish 步骤在 $(Build.StagingDirectory)/ci-build 中生成的文件的 zip 文件，并使用 starwars-api.buildnumber.zip 格式的名称进行打包。我使用了 Azure DevOps 暴露的 Build.BuildNumber 变量来构造此名称。请注意，我还硬编码了 starwars-api 部分，但您也可以为其设置一个变量，或者使用 众多预定义变量之一，例如构建名称。

归档步骤应如下所示

Publish Artifact

在此步骤中，我们只是拾取 .zip 文件，并将其移动到 Azure DevOps 中的相应文件夹。由于我们更改了默认值，因此我们也需要更改一些字段以匹配我们新的构件名称/路径。

1. 将 Path to publish 更改为：$(Build.ArtifactStagingDirectory)/starwars-api.$(Build.BuildNumber).zip。这将把我们的 zip 文件发布到该位置。
2. 在 Artifact name 字段中，再次添加我们创建的构件名称：starwars-api.$(Build.BuildNumber)
3. 其余保持默认值。

构建部分就完成了！现在您可以转到 Pipelines → Builds → Queue，等待构建完成，您应该会得到一个漂亮的构件。

如果您单击它，就可以将其下载到您的机器上

集成 Sentry 和 Azure DevOps

现在您的构建管道已在 Azure DevOps 中设置好，您可以集成 Sentry，解锁增强的发布跟踪、信息丰富的部署电子邮件以及新错误的分配者建议。

1. 在 Sentry 中，导航到 Organization Settings → Integrations。（注意：只有拥有 Owner 和 Manager 权限的用户才能访问此页面。）

1. 如果您已安装旧版 VSTS 集成，您将在 Azure DevOps 旁边看到一个名为 Upgrade 的按钮。如果您未安装旧版 VSTS 集成，您将看到一个名为 Install 的按钮。点击此按钮。
2. 在出现的模态框中，点击 Add Installation。
3. 一个 Azure DevOps 安装窗口应该会出现。选择您要链接到 Sentry 的 Azure DevOps 账户，然后按 Submit。

在此处阅读有关此集成功能的更多信息，并在此处了解如何配置这些功能。

您还可以查看 Joao 的原始帖子，在他的博客上与他联系提问，并阅读他在 .NET 方面的其他冒险经历。