什么是持续交付?

已完成

在此,你将跟随 Tailspin 团队讨论如何使用持续交付 (CD) 管道为即将进行的发布提供帮助。

Tailspin 团队在其生成过程方面开始渐入佳境。 他们有一个在 Azure Pipelines 上运行的自动化进程,这意味着生成环境是稳定的。 Amita 会立即知道何时需要测试生成工件。 她发现的 bug 较少,因为 Andy 和 Mara 已经开始添加单元测试和代码质量测试。 一切看起来不错。 让我们与团队讨论一下。

晨间会议

团队在会议室里等着产品经理 Irwin,他想和他们谈谈。 他们期待着告诉他他们的进展。 但当 Irwin 走进去时,他看起来并不高兴。 他立即开始讲话。

Irwin:今早我和管理团队开了个会。 他们想知道为什么我们花了这么长时间才能发布游戏和网站。 我们最有力的竞争对手推出新功能和新游戏的速度比我们快得多。 我们需要加快速度。 我不只是在提醒你们, 而是在提醒整个团队。 我们可以采取什么措施来帮助你的团队更快地进行部署?

Andy:这有点突然,但我们比你早了一步。 我们一直在使用自动化的网站生成方式。 也许现在是时候将我们的自动化扩展到发布过程了。

Irwin:你会怎么做?

Mara:我们使用 Azure Pipelines 创建了自动生成管道。 它会生成 Amita 可以测试的生成工件。 我们还可以生成一个持续交付 (CD) 管道。

Irwin:什么是 CD 管道?

Mara 开始讲解,但被 Irwin 的手机发出的嘟嘟声打断了。 Irwin 看了一条短信,低声嘟囔了几句。

Irwin:对不起,但这很紧急。 我得走了。 不如你们把这个 CD 业务搞清楚,然后尽快给我答复,好吗?

Andy 看了看他的团队。

Andy:咖啡?

Andy 和团队的其他成员前往咖啡店制定计划。

什么是持续交付?

团队正在喝着咖啡开会,探讨如何设置持续交付工作流。

Andy:Mara,你能跟我们讲讲你对持续交付的了解吗?

Mara:对我而言,CD 和 DevOps 是不可分割的。 请记住,我们将 DevOps 定义为人员、过程和产品的集合体,它让我们可以向最终用户持续交付价值。

CD 本身是一组过程、工具和方法,可实现快速、可靠和持续的软件交付。 因此,CD 不仅仅与设置管道有关,尽管这部分很重要。 CD 是关于设置工作环境,其中:

  • 我们有一个可靠且可重复的进程,用于发布和部署软件。
  • 我们尽可能地实现自动化。
  • 我们不会推迟完成困难或痛苦的事情;相反,我们会更频繁地这样做,以便找出使它成为例行公事的方法。
  • 我们对所有内容进行源代码管理。
  • 我们都同意,完成意味着已发布。
  • 我们会在过程中考虑质量。 质量绝不会是事后才考虑的事。
  • 我们都会对发布过程负责。 不再在孤岛上工作。
  • 我们一直在努力改进。

我们已经将许多这些想法付诸实践,我们都认为它们改进了我们的工作方式。 CD 是我们已经开始的内容的扩展。

为什么需要持续交付?

CD 可帮助软件团队快节奏地向其客户提供可靠的软件更新。 CD 还有助于确保客户和利益干系人都能快速获取最新的功能和修补程序。

让我们继续倾听团队对此内容的讨论。

Andy:谢谢你,Mara。 我们需要 CD,因为我们都知道,世界已发生了改变。 新功能的发布速度更快。 更新和 bug 修补程序都需要立即可用。 不仅仅是我们的管理层希望加快发布速度。 管理层只是对客户的需求做出反应。 如果客户无法从我们这里得到他们想要的东西,他们就会去别的地方。

Tim:我同意! 我已经等不及想开始了。

Andy:谢谢大家。 我要提议 Mara 和我整理一个简单的概念证明 (POC)。 我认为,如果可以看到 CD 管道的实际运行,一切都会更容易理解。

Amita:祝你们俩好运。

团队让 Andy 和 Mara 来解决细节问题。

持续交付与右键单击发布相比如何?

许多开发工具提供了将应用程序直接发布到某些目标环境(例如 Microsoft Internet Information Services (IIS) 或 Azure)的方法。 例如,可以使用 Visual Studio 将 ASP.NET Core 应用发布到 Azure。 此过程有时称为“右键单击发布”。

右键单击发布是快速生成原型的好方法。 例如,可以右键单击将应用程序发布到 Azure,以便可以与团队共享新的想法。 但是这种方法有局限性。

连续交付为你和你的团队提供了一种一致的方式,在每次签入代码时持续测试、部署和监视应用程序。 右键单击发布应用程序时,不能保证代码经过了正确测试或在实际使用情况下会按预期方式运行。

在这个简短的视频中,Microsoft 的云大使的 Abel Wang 会进行详细说明。

持续交付与持续部署相比如何?

在 DevOps 社区中,你可能会听到术语“持续交付”和“持续部署”。 这些术语的含义相同吗? 在这个简短的视频中,Abel 解释了两者的区别。

我可以使用哪些持续交付工具?

会议结束后,Andy 和 Mara 计划接下来的步骤。 他们使用 Azure Pipelines 来生成软件。 他们想要考虑可以使用哪些工具(包括 Azure Pipelines)来帮助他们进行发布过程。

Mara:你想从哪里开始?

Andy:首先,我们需要就发布管理工具达成一致。 确保我们选择的工具:

  • 支持我们的版本控制系统。
  • 可以部署到多个环境,以便测试和验证我们的工作。
  • 可以轻松定义部署任务。
  • 易于扩展。

Mara:Azure DevOps 与其他几个持续集成 (CI) 和 CD 解决方案进行集成。 有许多解决方案,但我们没有对其中任何一个进行投资。 如果进行了投资,那么使用那个解决方案就很有意义。 热门的 CI 和 CD 系统包括 Jenkins、Circle CI、GitLab、Travis CI 和 Azure Pipelines。

这些工具有相似之处,但也有其各自特殊的优势。 这些工具中有些是开源的,有些是免费的,有些则需要付费。 它们还提供了与其他软件工具的内置集成。

例如,Jenkins 是开源的。 它有许多插件,许多公司都在使用它。 你可以在云中或本地运行 Circle CI。 我认为需要对其进行自定义。 GitLab 是整个软件开发生命周期中的单个应用程序。 它可能比我们现在需要的更大。 我们可以继续使用 Azure Pipelines。

在下面的简短视频中,Abel 介绍了使用 DevOps 将代码部署到 Azure 的最佳做法。

Mara:我赞成继续使用 Azure Pipelines。

Andy:我同意。 到目前为止,Azure Pipelines 对我们来说非常好,我们不必再学习其他新技术。

Mara:太好了。 我们开始了解管道的详细信息吧。

Andy 和 Mara 前往会议室来计划 CD 管道。