摘要：许多公司都争先恐后地实施持续集成和持续交付(CI/CD)管道，以简化他们的软件开发工作流程。很少有人采取额外的步骤来自动化持续部署，这是一种使用CI/CD管道将更改持续推送到生产中的做法。可以理解的。

   从持续交付到持续部署的飞跃需要正确的技能、实践和工具。使用此五点清单为发布做准备。
　　
　　许多公司都争先恐后地实施持续集成和持续交付(CI/CD)管道，以简化他们的软件开发工作流程。很少有人采取额外的步骤来自动化持续部署，这是一种使用CI/CD管道将更改持续推送到生产中的做法。可以理解的。
　　
　　每天或每小时频繁地将代码推送到生产环境的想法让我不寒而栗。事实上，几年前，我写过一篇关于持续部署的缺点的文章。另一篇文章“负责任的devops团队何时应该增加部署频率”挑战了部署越频繁越好的假设。
　　
　　然而，过去几年发生了很大变化，越来越多的devops团队正在采用技能、实践和工具来自动化高质量和可靠的部署。本文解释了持续交付和持续部署之间的区别，然后提出了devops团队在CI/CD管道中自动化持续部署之前应该做的五件事。
　　
　　持续交付与持续部署
　　
　　Capgemini的敏捷和开发运营负责人KulbirRaina分享了一个有助于我们区分持续交付和持续部署的定义。他说：“持续交付是软件发布到生产的端到端自动化流程，而持续部署是通过预先测试的流程将流程中的软件包推送到生产后持续集成的自动化流程。”
　　
　　自动化生产部署具有更多风险，因为结果会影响业务、客户和最终用户。如果devops团队决定自动化部署，则部署过程必须包括持续测试和强大的错误处理。否则，部署可能会在生产中产生性能问题、不可靠的系统、安全漏洞和缺陷。
　　
　　SPR软件工程总监MikeSaccotelli补充说：“运行持续交付模型与持续部署模型的组织之间的主要区别在于其构建和部署过程的成熟度和复杂程度。”
　　
　　Devops团队可以使用以下清单来准备升级CI/CD管道以进行持续部署。
　　
　　1.评估商业利益
　　
　　作为一项原则，持续部署可以应用于许多应用程序，甚至可以应用于最受监管的行业。Buildkite的联合创始人兼联合首席执行官TimLucas说：“每个项目都可以采用持续部署，最好的组织设定目标，将尽可能多的项目转移到这种模式。即使在金融和受监管的行业，大多数项目都可以采用这种模式。我们甚至看到自动驾驶汽车公司进行持续部署。”
　　
　　虽然devops团队可以在许多项目中实施持续部署，但问题是，它在哪里提供了强大的业务案例和显着的技术优势？频繁部署功能和修复的项目，以及现代化架构简化自动化的项目，更有希望过渡到持续部署。
　　
　　2.准备开发团队
　　
　　Lucas分享了在迁移到持续部署模型之前应该成为软件开发过程一部分的一些先决条件。他说：“持续部署是真正的敏捷性，是从代码更改到生产的最快方式。它需要始终将主分支保持在可交付状态、自动化测试以及您可以信任和有信心的高质量工具。”
　　
　　希望自动化持续部署的开发人员的一些开发职责和规则包括：
　　
　　•使用足够的代码覆盖率进行持续测试，以确保更改不会产生新的缺陷。
　　
　　•用于测试安全性、性能和其他代码质量问题的静态和动态代码分析工具。
　　
　　•对左移安全实践的承诺，包括围绕API安全的最佳实践。
　　
　　•围绕应用程序和微服务的可观察性标准。
　　
　　•功能标记，以便可以打开和关闭新功能，或控制给部分用户。
　　
　　Saccotelli补充说：“持续部署的前提是开发团队对质量代码有更成熟的理解，这样这个过程才能成功。如果代码很差或未经测试，那将创建一个不可靠的系统，并迅速将错误和漏洞推向生产环境。”
　　
　　3.准备运营团队
　　
　　因此CI/CD管道运行并将新代码部署到生产环境。这是否意味着devops团队很清楚，他们的工作已经完成，每个人都可以进入下一个版本？
　　
　　没那么快。尽管开发人员为确保构建不会中断、自动化代码测试以及控制在生产中启用哪些代码所做的所有工作，但仍然存在一些部署可能导致生产问题的风险。监控业务服务、应用程序和系统是devops中的一项运营职责，他们支持持续部署的能力早在启用部署自动化之前就开始了。最佳实践包括以下内容：
　　
　　•使用基础架构即代码和容器来确保开发、测试、生产和其他环境之间的基础架构配置一致。
　　
　　•使用应用程序和系统级别的监控工具，这些工具还可以加载和分析由应用程序和微服务创建的可观察性数据。
　　
　　•选择一个AIOps平台，该平台在从应用程序到微服务和数据存储的整个堆栈中集成监控、警报和可观察性数据，并将事件关联到可管理的事件中。
　　
　　•设置金丝雀版本以控制新部署的切换和流量，并降低更难的切换策略的风险。
　　
　　•拥有一套强大的安全工具，包括API网关、Web应用程序防火墙、容器安全、威胁监控和敏感数据监控，以降低高度动态应用环境中的风险。
　　
　　4.跨团队和工具集成ITSM和工作流
　　
　　即使已经建立了所有开发和运营能力，我们还没有完成。假设devops团队提交代码，持续部署将更改转移到生产中，并且应用程序性能监控工具正在运行。正确的devops团队成员多久会收到警报，以便他们可以对事件进行分类、调查根本原因并快速解决任何问题？
　　
　　Lucas分享说，在转向持续部署时，“不稳定的测试是第一大风险”。他列举了不可靠的CI/CD工具、糟糕的生产监控和随叫随到的做法，以及工程和IT之间缺乏真正的合作伙伴关系作为进一步的风险。
　　
　　如果没有监控、AIOps、IT服务管理(ITSM)、敏捷和通信工具之间的工作流和集成，devops团队响应和解决问题的时间可能会落后于其部署速度。这种差距可能会造成压力，并削弱开发和运营之间的伙伴关系。最佳实践是确保集成IT工具和工作流程，以便开发运维团队能够跟上持续部署产生的任何问题。
　　
　　5.定义基于风险的决策门和KPI
　　
　　Copado产品营销总监KristinBaskett提供了持续部署所需的一个关键要素。她说：“虽然鲁莽的自动化可能会阻碍系统，但正确的自动化可以帮助组织实现真正从devops中受益所需的灵活性和一致性。当开发人员可以自动集成代码时，协作就会得到改善。通过投资于测试自动化和质量门控，组织可以更快地进行创新，同时降低风险。”
　　
　　除了测试自动化之外，Baskett还提到了实施应该扩展到其他风险评估的质量门。当构建触发持续部署时，质量门会实施业务规则，以确定哪些部署可以投入生产，哪些可能需要合规审查或管理签字。
　　
　　支持持续部署的其他最佳管理实践包括开发devops关键绩效指标(KPI)、形式化反馈循环和制定沟通策略。
　　
　　持续部署可以产生许多业务和技术优势，但纪律严明的DevOps团队和IT组织应确保在使用自动化提高部署频率之前拥有最佳实践和工具。
　　
　　编辑：Harris