azure devops 中的 Pipeline 和 Release Pipeline 有啥区别？

Posted 2023-02-15

【中文标题】azure devops 中的 Pipeline 和 Release Pipeline 有啥区别？

【英文标题】：What is the difference between Pipeline and Release Pipeline in azure devops?azure devops 中的 Pipeline 和 Release Pipeline 有什么区别？

【发布时间】：2020-02-22 18:43:09

【问题描述】：

选择此选项时会生成一个 yaml 文件，如下所示：

在这个 yaml 文件中，您可以定义从restore -> build -> run tests -> publish and -> deploy to azure app service web app 开始的整个部署周期。

那么，为什么会有发布选项？如果我可以通过Pipelines -> Pipelines 选项定义整个生命周期，那么Pipelines -> Releases 选项的目的是什么？

【问题讨论】：

下面的答案能帮助你实现你想要的吗？如果是，您可以接受答案，因此其他 SO 用户将能够看到该解决方案是否有效。如果您仍然遇到一些问题，请随时在此处发表评论:-)

【参考方案1】：

Pipelines 是最新的 DevOps 用户界面中用于构建的名称。在旧 UI 中是这样的：

可以说Pipeline（或Build，或Build Pipeline）代表Azure DevOps中的CI（持续集成）。 Release 代表 Azure DevOps 中的 CD（持续交付）。管道通常获取代码、构建它、测试并创建一个工件。 Release 获取工件并发布/部署它。

用法取决于您的项目。

如果您有一个小项目并且不需要发布功能（例如预部署条件和批准），那么您可以像您提到的那样拥有管道：restore -> build -> tests -> deploy 并且不需要发布。

如果您的项目很大并且有很多开发人员的贡献，那么每次开发人员推送到公共存储库时，使用 Pipeline 构建、运行单元测试、使用工件执行其他自动化和结果是很好的。因此，您可以确定一切都已解决并且集成测试已通过。流水线还可以最终发布/部署任务到开发环境/服务器，以进行内部工作、使用、测试。

在大型项目中，您不需要将每次推送都部署到公共仓库。因此，您可以确定一个负责部署到生产环境的版本。它具有为此而设计的功能，例如预先批准，因此每个人都同意它是用于生产的正确构建（或工件）。

【讨论】：

这并不完全准确，因为管道（当指定为 YAML 文件时）也支持发布方案。

@DanielMann 她没有说反话，她是在回答op的徘徊，通过解释两者的区别

【参考方案2】：

如 Microsoft 文档中所述，“发布”部分是他们的“经典编辑器”解决方案：Link

“管道”部分提供了两种创建管道的方式：

YAML 代码 经典 UI 编辑器

Classic 基本上意味着它们是创建 Azure DevOps 管道的原始方式。您可以使用 GUI 编辑器以交互方式构建管道。从 YAML 创建的管道，在助手的帮助下是更新的方式。

"Pipelines" 部分的主要内容是 "Releases" 没有的是，通过编写 YAML 代码，它可以让您将 CI/CD 策略配置为代码，其中，管道定义与您的代码并存。

他们最新的学习资源还表明使用 YAML 并在同一管道中创建构建和部署阶段Deploy applications with Azure DevOps

我推荐：

如果您更喜欢使用

Classic UI

编辑器，请使用“管道”部分进行构建，使用“发布”部分进行部署； 如果您更喜欢使用 YAML，只需使用“管道”部分进行构建和部署并创建多级管道。

Pipeline with multiple stages

编辑：2020 年 5 月 11 日更新，Pipelines YAML CD features now generally available

【讨论】：

这真的是误导他们如何命名的东西。

随着新的更新（2020 年 5 月 11 日），为 CI 部分设置一个 yaml 并为 CD 部分设置一个 yaml 是否有意义？

@JoDG 这取决于您的管道设计和一般工作流程。假设您希望部署基本的 lambda 函数。将整个构建/测试/部署过程的单个 YAML 定义作为多阶段管道是有意义的。另一方面，假设您正在部署更大的微服务，这些微服务构建方式不同，但部署方式相同。在这种情况下，有一个由许多“CI”构建/测试管道触发的单一“CD”管道是有意义的。

据我了解，Build&Release 管道都可以进行部署。因此，两者之间的选择取决于只有 Release 支持的功能。如“部署前的人工验证”、“预定发布”等。如果我错了，请纠正我。

现在我倾向于使用 YAML 进行部署，因为我认为它是支持像 docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…这样的新任务的唯一选择