我们如何在 GitLab 中发布软件补丁

在 GitLab，我们以两种方式处理软件修复：手动和自动。 请继续阅读，了解发布经理通过自动部署到 gitlab.com 来创建和交付重要更新的工作，以及供用户在自己的安装中使用的补丁。

我建议在您的智能手表上设置提醒：每个月 22 日，在其设施中使用 GitLab 的用户都可以看到我们产品当前版本的更新。 每月发布包含新功能、现有功能的开发，并且经常显示社区对工具或合并请求的最终结果。

但是，实践表明，软件开发很少是没有缺陷的。 当发现错误或安全漏洞时，交付团队中的发布经理会为我们的用户及其安装创建补丁。 Gitlab.com 在 CD 过程中更新。 我们将此 CD 过程称为自动部署，以避免与 GitLab 中的 CD 功能混淆。 这个过程可以结合用户、客户和我们内部开发团队提交的拉取请求的建议，从而以两种截然不同的方式解决发布补丁的无聊问题。

«我们确保开发人员每天制作的所有内容都部署到所有环境中，然后再将其部署到 GitLab.com”，解释说 马林·扬科夫斯基，基础设施部高级技术经理。 ”将您的安装版本视为 gitlab.com 部署的快照，为此我们添加了单独的步骤来创建包，以便我们的用户可以使用它来安装在他们的安装上“。

无论 bug 或漏洞如何，gitlab.com 客户都会在发布后不久收到修复程序，这是自动化 CD 流程的好处。 用户自行安装的补丁需要发布经理单独准备。

交付团队正在努力实现创建版本所涉及的大部分流程的自动化，以减少 平均时间点 （平均生产时间，即生产所花费的时间），从开发人员处理合并请求到在 gitlab.com 上部署的时间段。

«交付团队的目标是确保我们作为一家公司能够更快地行动，或者至少让交付人员工作得更快，对吧？，马林说。

gitlab.com 客户及其安装的用户都受益于交付团队为缩短周期时间和加快部署所做的努力。 在本文中，我们将解释这两种方法的异同。 问题，我们还将描述我们的交付团队如何为在其设施上工作的用户准备补丁，以及我们如何使用自动部署确保 gitlab.com 是最新的。

发布经理做什么的？

团队成员每月 转移发布经理的角色 我们在用户的设施中向用户发布的版本，包括版本之间可能发生的补丁和安全版本。 他们还负责领导公司向自动化、持续部署的过渡。

Marin 解释说，自安装版本和 gitlab.com 版本使用类似的工作流程，但运行时间不同。

首先也是最重要的，无论发布类型如何，发布经理都会确保从应用程序在 gitlab.com 上启动的那一刻起，GitLab 就可用且安全，包括确保客户的基础设施中不会出现同样的问题自己的能力。

一旦 Bug 或漏洞在 GitLab 中被标记为已修复，发布经理必须评估是否将其包含在用户安装的补丁或安全更新中。 如果他认为某个错误或漏洞值得更新，则准备工作就会开始。

发布经理必须决定是否准备修复程序，或者何时部署它 - 这在很大程度上取决于情况的上下文，”与此同时，机器并不像人那样善于管理环境“马林说。

一切都与修复有关

什么是补丁以及为什么我们需要它们？

发布经理根据错误的严重程度决定是否发布修复程序。

错误根据其严重程度而有所不同。 因此，S4 或 S3 错误可能是风格上的，例如像素或图标位移。 Marin 解释说，这一点同样重要，但不会对任何人的工作流程产生重大影响，这意味着为此类 S3 或 S4 错误创建修复程序的可能性很小。

然而，漏洞S1或S2意味着用户不应该更新到最新版本，或者存在影响用户工作流程的重大错误。 如果它们包含在跟踪器中，则许多用户都遇到过它们，因此发布经理立即开始准备修复。

一旦漏洞 S1 或 S2 的补丁准备就绪，发布经理就开始发布补丁。

例如，GitLab 12.10.1 补丁是在发现几个阻塞问题之后创建的，并且开发人员修复了导致这些问题的根本问题。 发布经理评估了分配的严重级别的正确性，确认后启动了发布修复程序的流程，该修复程序在发现阻塞问题后的 XNUMX 小时内准备就绪。

当大量 S4、S3 和 S2 积累时，发布经理会查看上下文来确定发布修复程序的紧急程度，当达到一定数量时，将它们全部合并并发布。 博客文章中总结了发布后修复或安全更新。

发布经理如何创建补丁

我们使用 GitLab CI 和 ChatOps 等其他功能来生成补丁。 发布经理通过在我们的内部渠道上激活 ChatOps 团队来开始发布修复程序 #releases 在松弛中。

/chatops run release prepare 12.10.1

ChatOps 在 Slack 中工作以触发不同的事件，然后由 GitLab 处理和执行。 例如，交付团队设置了 ChatOps，以自动化各种事情来发布补丁。

一旦发布经理在 Slack 中启动 ChatOps 团队，其余工作就会使用 CICD 在 GitLab 中自动进行。 在发布过程中，Slack 中的 ChatOps 和 GitLab 之间存在双向通信，因为发布经理会激活该过程中的一些主要步骤。

下面的视频展示了为 GitLab 准备补丁的技术流程。

自动部署在 gitlab.com 上的工作原理

用于更新 gitlab.com 的过程和工具与用于创建补丁的过程和工具类似。 从发布经理的角度来看，更新 gitlab.com 需要更少的手动工作。

我们不使用 ChatOps 运行部署，而是使用 CI 功能，例如 预定管道，发布经理可以使用它安排在所需时间执行的某些操作。 与手动流程不同，有一个每小时定期运行一次的管道，用于下载对 GitLab 项目所做的新更改、打包并安排部署，并自动运行测试、QA 和其他必要步骤。

“因此，在 gitlab.com 之前，我们在不同的环境中运行了很多部署，在这些环境状况良好并且测试显示出良好结果后，发布经理开始 gitlab.com 部署操作，”Marin 说。

支持 gitlab.com 更新的 CICD 技术将整个过程自动化，发布经理必须手动启动生产环境到 gitlab.com 的部署。

Marin 在下面的视频中详细介绍了 gitlab.com 更新过程。

交付团队还做什么？

gitlab.com 更新流程与内部向客户发布补丁的主要区别在于，后者需要发布经理花费更多的时间和更多的手动工作。

“由于报告的问题、工具问题以及在发布单个补丁时需要考虑到许多细微差别，我们有时会延迟向客户安装补丁，”Marin 说。

交付团队的短期目标之一是减少发布经理的手动工作量以加快发布速度。 该团队正在努力简化和自动化发布流程，这将有助于修复低严重性问题（S3 和 S4、 约译者）。 关注速度是一个关键的性能指标：有必要将 MTTP（从收到合并请求到将结果部署到 gitlab.com 的时间）从当前的 50 小时减少到 8 小时。

交付团队还致力于将 gitlab.com 迁移到基于 Kubernetes 的基础设施。

编者注：如果你已经听说过 Kubernetes 技术（我毫不怀疑你已经听说过），但还没有亲手接触过，我建议参加在线强化课程 Kubernetes 基地，将于 28 月 30 日至 XNUMX 日举行，以及 Kubernetes Mega，将于 14 月 16 日至 XNUMX 日举行。 这将使您能够自信地导航和使用该技术。

这两种方法追求相同的目标：为 gitlab.com 及其设施中的客户快速交付更新。

对我们有什么想法或建议吗？

欢迎每个人为 GitLab 做出贡献，我们也欢迎读者提供反馈。 如果您对我们的交付团队有任何想法，请不要犹豫 创建一个请求 标 team: Delivery.

来源： habr.com