持续交付与持续部署

利用这两种自动化做法,可更快地向客户提供高质量代码。

什么是持续交付和持续部署?

持续集成与持续交付和持续部署都是自动化软件交付阶段的做法。 这些做法可让开发团队更快、更准确、更高效地向客户发布新功能、改进功能和修补程序。

持续交付和持续部署有很多共同点。要了解这些做法的不同之处,并确定要实施哪一种做法,我们需要确定可自动化的软件交付阶段。

软件交付过程的自动化

使用者要求增加产品的个性化和安全性。为了满足这些需求并更快、更可靠地交付软件,开发团队可以采用 DevOps 文化。

DevOps 文化化解了相互独立的专业,并统一了人员、流程和技术,以改善协作和协调。这样一来,代码更改就可以尽快进入生产环境,并为客户带来新的价值。

尽管开发、IT 运营、质量工程和安全团队在 DevOps 下紧密合作,但软件交付过程仍非常复杂。DevOps 将软件交付分成五个阶段:计划、开发、交付、部署和操作。

在 DevOps 中交付软件

如果没有自动化,开发团队必须手动生成、测试和部署软件,其中包括:

  • 签入、测试和验证代码。
  • 将代码更改合并到主分支。
  • 准备发布代码。
  • 创建可部署的工件。
  • 将代码推送到生产环境。

可自动化的阶段

持续集成、持续交付和持续部署都是使开发和交付阶段各方面自动化的做法。从持续集成开始,每种做法都使自动化更进一步。

持续交付与持续部署的不同之处

持续集成

为了描述持续交付和持续部署,我们先从持续集成开始。在持续集成下,开发阶段(生成并测试代码)是完全自动化的。每次提交代码时,都会对更改进行验证并将其合并到主分支,然后将代码打包成生成工件。

持续交付

持续交付会自动完成下一个阶段:交付。在持续交付下,只要有新的生成工件可用,该工件就会自动置于所需的环境中并进行部署。

持续集成和持续交付 (CI/CD)

当团队同时实施持续集成和持续交付 (CI/CD) 时,开发和交付阶段将实现自动化。代码随时可用于生产。所有团队要做的就是手动触发从开发到部署的过渡,以使自动化的生成工件可用于进行自动部署,这就像按下按钮一样简单。

连续部署

通过持续部署,可自动完成从代码提交到生产的全过程。开发与交付阶段之间的触发器是自动的,因此,在代码更改获得验证并通过所有测试后,就会立即发布。这意味着在改进功能可用后客户便可立即获得这些功能。

持续交付与持续部署:应该选择哪一种?

无论是采用持续交付还是持续开发,都可以找到支持你的工具。

在考虑实施哪种做法之前,请先确定你的组织是否具有可支持它们的 DevOps 文化。接下来,由于 DevOps 团队致力于实现整个软件交付过程的自动化,你要问的不是“哪一种做法更好?” 而是应该问:“持续集成与持续交付之间需要手动触发器吗?”

当你寻找答案时,请通过以下问题获取指导:

  • 你是否可以在未经利益干系人批准的情况下进行部署?
  • 你的系统和门控要求是否允许端到端自动化?
  • 你能否让客户一次接触一点生产变更?
  • 你的组织是否会快速响应生产中的错误?

如果全都回答“是”,你可能希望考虑实施持续部署,并实现整个软件交付过程(从代码提交到生产)的全自动化。

如果有任何一个问题回答“否”,你可能需要从持续集成和持续交付 (CI/CD) 开始。 你将实现生产就绪代码的自动创建,这种代码本身在部署中就只需要一个手动批准步骤。之后,你可以逐渐转向持续部署并实现软件交付过程的全自动化。

无论实施哪种做法,你都可以获得共同的优点:

  • 自动生成、验证和测试更改。
  • 代码始终是可部署的,消除了发布日焦虑。
  • 发布会更快地获得利益干系人和客户的反馈。
  • 由于手动任务和管理任务的减少,开发人员的工作效率得到提高。
  • 由于更改很小且频繁,因此很少失败,并且不稳定程度最低。

用于实现持续集成、持续交付和持续部署的工具

DevOps 团队依靠工具链(一系列互联的软件开发程序)来实现软件交付的自动化。你使用的工具取决于你选择的自动化做法以及该做法可以自动化哪些阶段。下面是一些示例。

开始使用 Azure 进行 DevOps

发现持续交付和持续开发工具,以及在云中促进其他 DevOps 做法的工具。