Azure DevOps中的构建管道和发布管道之间有什么区别？

Question

我已经Azure DevOps通过使用.yaml文件建立了几个多阶段的构建管道。我已经读过有关可用的“发布管道”的信息，我想知道这些管道有什么好处？

他们似乎在做同样的事情，甚至不提供YAML的支持。那么，这里的主要区别是什么？通过使用发布管道而不是通常的构建管道可以做什么？

Answer 1

在Azure DevOps中，在存在多阶段yaml管道（现称为“ 管道 ”）之前，通常使用构建管道来构建 / 创建软件二进制文件（例如dotnet publish或ng build --prod），并将这些工件存储在Azure DevOps放置位置。

然后，您通常会有一个Releasee管道，该管道会被这些构建工件（软件二进制文件）触发，并将它们部署到一个或多个阶段。

这两个管道（构建和发布）分开的原因是要建立自己的软件的特定版本只一次，然后用相同的 每个目标环境中的二进制文件（如开发/测试/生产）。

使用新的管道，通常使用第一个阶段来构建工件，然后使用下一个阶段来部署它-与以前相似，但在一个模块中。

如果以前使用过构建和发布管道，则将在新的Pipeline模块中看到旧的构建定义，并在旧的发布模块中看到旧的发布定义。但是，他们从未将YAML引入发布管道，因为他们知道无论如何它们都将被多阶段管道所取代。

结论：如果您使用新的多阶段“ 管道 ”模块，则不应再使用经典的发布管道。

感谢您的澄清！现在这对我来说更有意义。然而，奇怪的是，微软的一些官方文档仍然指向这个“发布”管道，而且我在网上找到的很多提示/教程都使用不同版本的不同 UI。 (3认同)

Answer 2

Yaml 还在开发中，发布管道中的一些特性无法完全替代，例如：

同样，构建管道中的一些功能也没有被完全替换，例如

所以，随着yaml的发展，它的功能会越来越全面，但是现在发布管道的一些特性还不能完全替代，发布管道还是有价值的。

Answer 3

这个问题已经有几年了，而且在发布版本时，功能之间仍然存在很大的差距。

我个人对现代管道方法（用于发布）与“旧”发布管道有两点不喜欢：

对于我们最近的场景，发布管道仍然是更好的选择。用户界面和配置的可访问性让我们为我们的版本选择发布管道，并且我们保留了构建管道和单独的发布管道的方法。

如果您不想每次都部署到每个环境并且您有一个也不应该每次都执行的批准流程，那么您应该考虑旧的发布管道。你可以在 yaml 中实现这些东西，但你不能简单地配置它。您必须自己在 yaml 中完全配置新管道。可达性不太好。

您可以更轻松地查看部署了哪个版本。如果您有时想要部署旧版本，那么发布管道将清楚地向您显示哪个版本部署在哪个阶段：

现代管道的情况并非如此。这就是您在概述中看到的方式：

现代管道的整个用户界面并不是纯粹为了发布而设计的。尽管您可以在管道的详细信息视图中很好地了解各个阶段......

...这个视图甚至低于构建的编译器警告！

发布管道是为该过程而设计的，您可以在用户界面中看到这一点。这是单个版本的详细信息视图，它始终位于页面顶部：