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