这可能是一个非常特殊的情况,但我们决定不创建一个单独的作业来删除构建,原因非常简单,就是将与特定构建号相关的所有日志记录保存在一个地方。设置如下:
此处的升级意味着使安装包 (RPM) 可用于给定服务器,其中自动更新处理包的实际升级。
我们有一个主构建,每次有新的提交可用时构建。我们对安静时间等进行了一些微调,但基本上每个新推送的提交集都会导致新的构建。该构建包含所有相关且可用的测试,这远未完成,而且可能永远不会完成。
每小时都有一个单独的升级步骤处理从登台到生产的升级。此构建启动了一个单独的促销活动,该促销活动将最新接受的构建从 CI 带到登台。在提升构建之前有 30 分钟的延迟 CI--> 暂存,以防止最后一秒提交的意外提升。一些 bash find 脚本实现了延迟。促销的顺序是这样的,以确保在进行促销之前(至少)一小时内可以进行构建。
实际答案:
升级步骤是作为单独的构建完成的。为了进行真正的提升,而不是使用单独的日志进行单独的构建,构建在主构建中启动实际提升,使用 curl 并调用远程 HTTP API。这会在主构建日志中留下一个相关的促销星。使用不同的颜色,促销活动一目了然。
为了降级构建,我决定创建一个单独的“降级构建”升级步骤。然后这将发出一个紫色星作为构建有缺陷的标志,因此被删除。降级是通过访问 UI 中的正确构建并按下“删除构建”按钮来完成的。此步骤没有添加自动化,但通过创建单独的测试步骤,自动化降级也相当容易。然而,我们还没有走到这一步。
这种方法的好处包括
- 通过访问失败的构建而不是通过提供参数来删除构建。更容易记录,并在压力下得到正确的结果
- 任何人都可以按下这样的“紧急按钮”,不仅在开发人员之间,而且在经理和 DevOps 之间建立信任和所有权。
- 发现死构建非常简单,因为除了其他升级日志之外还有可用的日志
- 在同一个构建中包含所有相关的促销调用使进一步的脚本编写更容易
我们仍然需要改进的重要事情包括在构建管道的后期阶段自动化测试,以及降级后降级构建的合适方法。例如,在生产中,一个有缺陷的构建和降级必须始终导致安装最后一个好的构建,这已被证明是相当难以实现的。生产数据中心很少被允许从 CI 系统所在的开发 DC 访问到此级别。此外,停止和启动构建管道必须是自动化的,否则就有可能滑回手动状态。
自然,本着持续改进的精神,总有需要改进的地方。整个设置有点像 bash/perl 脚本编写的混乱,但由于它是脚本化且可重复的,因此始终可以选择一次改进一小部分。最重要的是自动化,因为它允许增量步骤,任何手动步骤或多或少都会阻止。