我们为什么需要持续部署?

几周前,一位同事描述了一个维护手动测试和部署实践的软件开发团队。部署是如此复杂,以至于最初的开发人员将完成艰难的部署作为一种荣誉徽章。问题是:该团队如何转向持续部署模型?我承认,当我读到这篇文章时,我感到一阵恐惧,因为我在以前的组织中经历过这种情况。虽然从手动复杂部署场景转向自动化部署场景是一项巨大的技术挑战,但成功变革所需的文化转变更为重要。

首先我们应该涵盖一些术语:

  • 持续集成,通常称为“CI/CD”的 CI 部分:CI 是开发人员频繁地将代码合并到主分支,并在每次合并后自动化工具构建和测试代码的实践。
  • 持续交付:可以将更改部署给客户,但部署行为可能是手动步骤,通常需要批准。
  • 持续部署,传统上是 CI/CD 的 CD 部分:实践中,通过自动化测试的每个更改都被部署以供客户使用。

关于如何使用各种技术实现持续部署的文章有很多,但关于原因的文章却很少,我将在本文的其余部分进行探讨。

两本出版物脱颖而出,成为推荐读物,我将在它们的基础上继续阅读。第一个是Phoenix 项目,这是一个精彩的虚构故事,介绍了 DevOps 概念,其中包括持续部署。第二个是持续交付网站,这是一个链接到同行评审研究和进一步阅读的重要资源。

例子

我将分享我所从事的三个服务示例,每个示例都有非常不同的持续部署状态。

我们为什么需要持续部署?

我分享这些并不是为了羞辱或责备任何人,相反,每个团队都充满了聪明的人,试图利用我们当时拥有的工具和限制来做正确的事情。在过去的二十年里,我们共同学习了很多关于如何交付软件的知识,我们可以使用这些示例来探索为什么您希望为您的服务进行持续部署。

在我职业生涯的早期,我支持一个开发团队,该团队计划在一周中规定的一天进行部署,当天晚些时候不可避免地进行回滚,并在本周晚些时候部署修补程序。这听起来像是一种批评,但事实并非如此。该团队试图以每周的节奏交付商业价值——这在每季度甚至每年发布的时代几乎是闻所未闻的。这发生在 2000 年代初,自动化测试框架几乎不存在,Subversion 源代码控制工具刚刚发布。该团队没有自动构建或测试,可执行文件是手动(通常由我)复制到目标服务器的。当我写下这篇文章时,我不禁对这个系统的运作印象深刻。找出问题所在很容易,但他们做对了什么?

  1. 变更集很小,不到几个开发人员一周的变更量。
  2. 客户的反馈是即时的。
  3. 在部署之前可以进行回滚并进行测试。

我在 BlackBerry 工作的一项服务已不再使用,每季度发布一次,采用传统的开发完成代码锁定、漫长的测试阶段以及在可怕的 0200-0400 周末更改窗口中非常复杂的手动部署过程。尽管每个版本都经过了数千小时的测试,但几乎每次部署都会导致回滚或多个修补程序来解决出现的问题。这项服务面临的最大挑战是变更集的庞大规模,其中包含二十个或更多开发人员三个月的工作。没有人能够理解更改的范围,尽管有一支庞大且技术精湛的 QA 团队,但这使得每次部署都存在风险。

与我在 Arctic Wolf 的最新经历相比,我们实施了持续部署,并且几乎每小时都会根据最新更改重新部署一些服务。该系统并不完美,我们肯定有错误进入生产环境,但除了少数例外,我们发现修复错误并部署该更改几乎总是比尝试回滚部署更容易。

持续部署可以为您带来什么

我可以写一整本书来介绍实施持续部署的优势,但为了读者的利益,让我们探讨风险、质量、成本、速度、幸福感和安全性。

风险较小

几十年前的变革管理理念是,变革是稳定的敌人,这一理念在一些较老的组织中仍然普遍存在,并在 2000 年代初的 BlackBerry 中使用。为了维持服务的正常运行时间为五个九,必须限制变更并仔细控制变更。不幸的是,这与产品和开发团队发布新功能或修复错误的需求发生了直接冲突。在我的第二个例子中,冲突显而易见——运营团队在严格的 SLA 驱动下,有责任提供极其稳定的服务。产品和开发团队必须发布新功能,结果是不频繁但非常大的变化,以及两个团队之间不可避免的冲突。

通过持续部署,变更集应该很小但很频繁,并且新功能会以易于理解的小批量方式引入。当出现不可避免的问题时,团队可以很快缩小导致问题的确切变化范围。较小的变更集可以降低大规模停机的风险。

为了实现持续部署,有一个基本假设,即您的软件可以通过蓝/绿部署和零停机时间以滚动方式进行部署。这也意味着您的基础设施是使用基础设施即代码定义的,不需要手动干预即可部署。这也降低了风险,因为部署是自动化的、可重复的和可测试的。

更高品质

一套可靠的自动化测试是实施持续部署的关键要求。如果您的团队致力于使这些测试保持最新,则应该在部署之前捕获回归,从而产生更高质量的软件。我曾经无意中听到一个团队说“我们不相信我们的测试”,因此又恢复到手动测试,并每周部署一次或更短时间。由于他们是手动测试,因此他们在速度和质量方面都遇到了困难。一旦他们重新控制了测试套件,他们的速度和质量就恢复了。

更低的花费

多项研究表明,错误从开发人员转移到客户手中的时间越长,修复成本就会呈指数级增长。开发持续部署所需的自动化测试肯定会产生前期成本,但错误会在开发周期的早期被发现,从而从长远来看降低总体成本。

更快的上市时间

将我的黑莓示例与其他两个示例进行比较,客户可能需要长达六个月的时间才能看到新功能或错误修复。在另外两个示例中,团队可以更快地提供新功能,只需几周甚至几小时。

DORA 的四个指标之一(有关更多详细信息,请参阅下面的衡量成功)是“变更交付时间”,或者从提交代码到部署到生产所需的时间。假设其他指标也一致,这个数字越低越好。能够在数小时内向客户部署变更的组织比需要六个月的组织要成功得多。

更快乐的团队

我最喜欢的 Slack 反应之一是“#YOLO”图标,我的同事会用它来表明他们已经审查并批准了 GitHub 拉取请求。它部分是用来开玩笑的,因为每个人都非常关心我们正在部署的服务,但它也部分是对 CI/CD 管道和测试基础设施以及我们对其的信任的认可。我作为领导者的既定目标是,开发人员应该能够合并他们的代码更改,然后离开去吃午饭,相信 CI/CD 管道会正确构建、测试和部署更改,如果出现严重错误,要么回滚更改或通过 PagerDuty 调用它们。这是一个崇高的目标,但我认为我们还没有完全实现这一目标。事实上,我和我的同事通常会在变更推出时对其进行跟踪,但我希望我们有信心自动化会发挥作用。

我们为什么需要持续部署?

让我们现实一点——培养快乐的团队并不是你的公司存在的原因。然而,快乐的团队会比不快乐的团队更有生产力,倦怠和人员流动更少,因此作为领导者,让团队快乐符合你的最大利益。让团队能够在无需干预的情况下频繁部署意味着他们可以专注于为客户提供价值,并且在业余时间他们将创建出色的 Slack 反应。

更安全

虽然上述所有其他原因都很重要,但这个是我最喜欢的,但不常被谈论。保持软件依赖性和操作系统最新是很困难的。当针对关键错误的新补丁发布时,这可能会花费大量时间,并且可能会造成很大的破坏。持续部署可以消除很多痛苦。

Log4Shell漏洞公布时,我领导了对 Arctic Wolf 系统进行修补的响应工作。这是压力极大的一天,但我们设法在一天中对运行数十万个容器的数千个 AWS EC2 实例进行修补,同时保持服务运行,以便面向客户的安全团队可以在传入数据中查找妥协指标以保护客户。让我重申一下——那天海量数据存储上的搜索负载增加了一倍,我们在处理该负载的同时修补了数千个系统。我们实现这一目标的唯一方法是使用我们构建的持续部署管道,我无法想象其他场景。

这是一个极端的例子,但对于任何新漏洞都使用相同的模式 – 将新版本提交到正在使用的任何依赖管理系统,依靠测试来捕获任何回归,并依靠自动化来推出它。

反对意见

让我们解决一些对实施持续部署的反对意见。

不是谷歌

一个常见的反对意见是“但我们不是 Netflix、谷歌或____,我们不需要这些”。您不需要大型团队来实施 CI/CD。当我们在 2018 年从每周发布转向持续部署时,Arctic Wolf 的整个研发团队只有不到 100 名开发人员。如果我今天要开始一项新服务或新公司,我要做的第一件事就是使用 Hello 实施 CI/CD世界示例,然后从那里开始迭代。即使是由几个开发人员组成的小团队也会看到上面列出的所有好处。

职责分离

在一些受监管的环境中,审计人员经常寻求开发人员和有权访问生产系统的员工之间的职责分离。我无法谈论所有类型的认证,但我在实施持续部署方面取得了巨大成功,同时保持了 SOC2 和 ISO27001 认证。我们使用的理由是,开发人员无法自己进行更改,他们提交了 GitHub Pull Request,需要其他人进行强制审核,并且对生产系统的所有更改都遵循相同的流程。CI/CD 管道配置也以相同的工作流程存储在 GitHub 中,使用 CD 进行部署,并且单个开发人员无法修改。这种设置有足够的职责分离来满足每个人的要求。

荣誉勋章

有时,就像我介绍中的情况一样,团队或个人会将部署(或构建或测试)的复杂性视为荣誉徽章。我确实理解这种心态,在我职业生涯的早期,我是一名 Unix 系统管理员,正如一位朋友指出的那样,我擅长手工处理大型复杂的任务,并使用手工制作的服务器。剥夺某人的这种能力可能会令人恐惧,在某些情况下,个人利用他们对复杂性的了解来误导工作保障。关键是要让个人放心,他们的工作保障不会因变革而受到威胁。如何处理这个问题在很大程度上取决于团队的性格。如果有人拒绝改变,他们就会对组织的健康构成风险,然后你可以将其作为绩效问题来处理。在实践中,如果您从小规模开始,通过一项服务实施持续部署,然后从那里扩展,这种反对意见通常会自行消失。

不是 SaaS

当您提供的软件不是典型的 SaaS,而是打包软件或设备时,连续部署可能是不可能的。然而,根据我的经验,持续交付仍然是可能且可取的。在这种情况下,您仍然应该遵循 CI/CD 流程,持续构建和测试软件,但实际部署是由外部流程触发(或阻止)的业务流程控制的,而不是由开发团队触发(或阻止)的。机制可能有所不同,但最终结果是相同的——产品团队为客户启用了新功能。在 SaaS 领域,这通常是通过在已部署的软件中启用功能标志来实现的,而对于应用程序来说,它可能会在 App Store 中部署新版本,而对于更传统的打包软件来说,它会在网站上发布新版本。持续集成和持续交付的相同原则适用于这两种情况。

衡量成功

Google 的 DevOps 研究和评估团队汇总了四个普遍接受的指标来衡量软件交付性能。在实施持续交付之前衡量这些,即使一开始只是轶事,也意味着您在实施期间有一个衡量基准。完整的“2022 年 DevOps 状况”及其指标已发布在此处,指标如下:

  1. 更改的提前时间:测量从代码提交到生产中发布的时间。
  2. 部署频率:组织将代码部署到生产环境的频率。
  3. 服务恢复时间:当服务事件或缺陷影响用户时,恢复服务所需的平均时间。
  4. 变更失败率:生产变更的百分比,导致服务质量下降,随后需要修复。

有几家公司正在构建服务来衡量这些值得关注的指标。我与其中任何一个都没有任何关系:CodeGemJellyFish是其中两个脱颖而出的。

下一步

如果您已经做到了这一点,那么这里有很多关于如何使用不同技术实现持续部署的精彩演讲和文章,并且有大量销售优秀产品的供应商可以提供帮助。我建议首先开始跟踪上面列出的四个指标,然后从对业务线不重要的小型服务开始。一旦您持续部署一两个服务,您的组织就会清楚其好处。

进一步阅读

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/191027.html

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!