问题标签 [build-pipeline]

我正在阅读有关 azure 中的并发管道的信息。

并发管道您可以在 Azure Pipelines 中运行并发管道（也称为并行作业）。Azure Pipeline 中的一个并行作业允许你在任何给定时间运行单个生成或发布作业。无论您在 Microsoft 托管或自托管代理上运行作业，此规则都是正确的。并行作业是在组织级别购买的，并且由组织中的所有项目共享。

我的理解是 - 天蓝色的构建管道被组织成作业（代理/无代理作业）。每个作业都包含任务。在自动/手动触发构建管道运行时，我认为可以并行运行的管道数量（假设每个管道只有 1 个工作）取决于构建代理的可用性（机器 - 天蓝色或托管）。

那么并发管道的概念究竟是什么？“Azure Pipeline 中的一个并行作业允许您在任何给定时间运行单个构建或发布作业。”是什么意思？简单来说，购买一个并行作业应该允许我们 a) 运行 2 个构建管道（假设每个管道仅包含 1 个作业）或 b) 1 个管道同时并行有 2 个作业。但这取决于构建代理的可用性，因为每个管道（具有 1 个作业）或具有 2 个作业的 1 个管道将需要 2 台机器并行运行。这是否也意味着默认情况下（免费）一次只能运行一个构建管道？并行作业和并行管道之间似乎存在混淆，因为一个管道可以有并行作业。

关于管道/作业/并行管道/并行作业/构建代理计数/并行作业计数，我需要澄清这个主题。

如果需要更多信息，请在评论中告诉我。

Azure DevOps 很容易支持自动化测试，方法是向管道添加一个或多个任务，这可以在推送新提交并自动构建软件后触发。对于 Visual Studio，这通常采用 DevOps 的形式构建您的 Visual Studio 解决方案，然后运行一个或多个测试项目，这些项目很可能是该解决方案的一部分。

我的问题是：似乎没有一个如何实际执行此操作的单一示例。 当我尝试时，我收到此错误：

此任务仅在 Windows 代理上受支持，不能在其他平台上使用。

这是在添加 Visual Studio 测试任务之后。使用最小管道时，解决方案能够很好地构建，并且管道运行正常。当添加一个非常非常基本的任务来运行单元测试时，会返回上面的错误消息。

我尝试四处寻找有关如何设置的明确说明或示例，并且尝试搜索该特定错误。得出的结果根本不是很丰富。

因为其他地方不存在明确的说明，所以我会问：设置 Azure DevOps 管道所需的基本但明确的步骤是什么，该管道将构建使用 .NET Core 的 Visual Studio 解决方案，然后运行测试项目（ s) 在里面？

我正在考虑将我的旧 CI/CD 管道迁移到一个多阶段、基于环境的 YAML 文件中，这些管道混合了用于构建的新 YAML 管道和“经典”基于 UI 的发布管道，但我正在苦苦挣扎找到我们目前正在做的事情的文档/示例。

通常有三种环境Test：UAT和Production。

它们都是基于 AKS 的，目前创建 docker 容器的构建将作为其输出的一部分，存储DeployService.yml发布管道用于更新每个环境的文件（通过修改图像标签和一些环境变量）在运行之前kubectl apply -f DeployService.yml。

目前我有几个遵循这种模式的项目：

我想使用单个文件将它们全部移动到更新的多阶段 YAML 构建和发布管道。

就目前而言，我使用新的管道模板创建了一个新的 yaml 文件，然后复制并粘贴了现有 CD 构建的位。

目前，新版本可以：

• 执行创建和推送 docker 容器的构建。
• 触发推送到Test环境中的发布。

作为其中的一部分，模板manifests在 repo 中创建了一个文件夹，其中包含 adeployment.yml和 a service.yml。它还创造了一个连接到我们的环境TestAKS 集群的环境。

所以我的问题是：

1. 鉴于deployment.yml需要包含特定于环境的变量（想想ASPNETCORE_ENVIRONMENT），我如何在每个发布环境中提供这些额外的特定于环境的变量？
2. 我可以重新创建与使用经典 UI 版本相同的促销风格的发布管道吗？
3. CI 构建是否完全适合这个过程？还是我应该把它放在一个单独的文件中？
4. 鉴于有很多项目遵循这种模式，并且在大多数情况下，它们都做同样的事情，只是构建项目特定的容器，repos 之间是否有任何可重用性？

如果我的开发团队可以看到我们构建管道的当前状态，我想设置一个监视器。当构建管道失败时，我想触发声音。我不知道在 Azure DevOps 中是否有可能，但这就是我在这里问它的原因。另外，如果有人对配置此监控“仪表板”有一些好的建议，请告诉我！

亲切的问候，

沃特

我正在重构管道以使用阶段作为模板，因此我的测试发布构建管道和发布构建管道中没有重复的代码。但我得到了我在以下几.yml行中评论的错误。

微软提供的例子：

我检查了文档，但看不出有什么问题。你能指出我的错误以及我应该改变什么吗？

我有两个构建我的客户端和 API 的构建管道，但是当我创建一个新的 git 标签时，两个构建都会被触发，即使标签可能只与基于我的客户端代码的更改有关。

前端构建-ci.yml

api-build-ci-yml

定期提交按预期工作（即客户端代码触发客户端构建），我尝试了多种排除路径的变体无济于事。

标签过滤应该忽略路径，还是应该以与分支相同的方式工作？

一种解决方法是使用更多描述性标签（即20200326_prodrelease_api），但如果 api 和客户端都准备好进行生产，我会尽量避免需要两个标签。

我有一个托管在 dev.azure.com(AzureDevops) 上的 GIT 存储库，以及一个托管在私有服务器上的本地 TFVC 存储库（我无法访问机器，我只能访问其 Web 门户）。两者都有相同的代码。

我在 AzureDevops 中为我的 GIT 存储库创建了一个构建和发布管道，运行良好。但是现在，我想从 GIT 存储库更新我的 TFVC 存储库，作为每次在 AzureDevops 中执行管道时的构建/发布管道任务。

没有任何可能发生冲突，因为没有其他人会将更改签入到我的 TFVC 存储库。

有什么办法可以做到这一点？

我正在使用 Azure devOps 构建和部署我的应用程序，在该应用程序中，我有一个项目正在被其他相关应用程序使用（我们称之为项目 N）。因此，我决定将此项目部署为 NuGet 包，并在构建期间使用它。

项目 N 可能会经常更改，因此我在定义可靠设置时遇到了一些麻烦：

1. 仅当项目 N 及其依赖项发生更改时才创建 NuGet 包
2. 保证，如果要创建 NuGet 包，按照 1)，管道会在其他任何事情之前执行此操作

到目前为止，我设置的方式是有两个不同的管道，一个创建 NuGet 包并部署它（NuGet 管道），另一个使用该 NuGet 包，然后构建和部署应用程序（主管道）。

问题是，当与项目 N 相关的文件以及解决方案的一些剩余文件中发生更改时，我不知道如何制定一条规则，上面写着“在主管道之前运行 NuGet 管道”，所以对于我必须相信运气会发生这种情况，如果没有，我将不得不在两个构建完成后手动触发主管道。因为我想确保项目 N 中引入的新更改不会破坏解决方案。

有没有一种优雅的方式来做到这一点？我可以设置一个触发器，只要 Pipeline NuGet 完成，它就会触发主管道，但是通过这样做，每当对项目 N 和解决方案的其余部分进行更改时，我都会触发主管道两次。

我使用以下 Yaml 设置了一个 azure 构建管道

这个项目是一个简单的 hello world 控制台应用程序，用 c# .net core 3.1 编写

当我在本地构建或发布这个项目时，我得到以下输出：

• 第146章
• 第186章
• 第416章
• 4.608 TestYaml.dll
• 171.520 TestYaml.exe
• 第656章
• 第154章

但是，通过构建管道发布的工件给了我这些文件：

• 140 应用程序设置.deploy.json
• 第179章
• 第394章
• 4.608 TestYaml.dll
• 86.424 测试Yaml
• 第632章
• 第146章

所以在这里，文件大小更小，更重要的是缺少 TestYaml.exe 并被 TestYaml 文件替换。

这应该相当简单，但我看不出缺少什么。

在此先感谢您的帮助！

在我的解决方案中，我有针对 .netstandard 2.0 的项目，因为我们不能有针对同一平台的测试用例项目，所以我正在使用 .netcore 3.1 单元测试项目，即使在我将构建管道更新为使用 .net 3.1 之后，我也面临以下问题在构建管道中恢复 nuget 步骤时出现问题。

注意：https ://www.hanselman.com/blog/AzureDevOpsContinuousBuildDeployTestWithASPNETCore22PreviewInOneHour.aspx 是我用来解决此问题但仍面临相同错误的链接。