如何在不阻止热修复的情况下强制执行策略

Source: Dev.to

热修复的本质

• 紧急 – 生产已经受到影响。
• 小幅 – 目标是止血，而不是重新设计系统。
• 高风险 – 它们在压力下触及实时系统。
• 高影响 – 即使是一行代码的更改也可能影响成千上万甚至数百万用户。

许多团队仍然对拥有数周背景的大型功能 PR 以及在事故期间凌晨 2 点的 一行生产修复 使用相同的规则。这种不匹配会产生摩擦，最终导致政策违规。

“跳过检查标签” 反模式

大多数组织都有这种痛感，因而采用一种常见的变通办法：引入手动标签，如 skip-ci、emergency 或 hotfix，以禁用必需的检查。这些标签通常是未记录的约定，仅为高级工程师所知。

表面上看，这似乎加快了速度。实际上，它是对政策的悄然侵蚀。

当跳过检查成为常态时：

• 责任感下降
• 审计变得困难
• 安全团队失去对 CI 信号的信任
• “紧急”变成一种习惯，而非例外

问题不在于对速度的渴求，而在于标签移除了防护栏，而不是对其进行重新塑造。

两阶段流水线检查

现代工程系统依赖基于 Git 的工作流，即使是热修复也通过受必需检查保护的拉取请求（PR）进行。为避免阻塞紧急修复，许多组织将验证拆分为两个有意的阶段：

合并前检查

快速、轻量的检查，验证更改不会立即导致测试失败或违反基本政策。

检入前检查

合并前检查通过后，开发者即可进行检入前检查。成功的检入前检查会自动合并 PR，消除人工延迟，同时仍确保每个热修复遵循受控且可审计的路径。

在大多数公司，合并更改需要同时通过 合并前检查 和 检入前检查。对于热修复，可以使用 规则集 或 分支保护规则 使合并前检查更可靠。

优秀热修复规则集的示例

• 仍然需要拉取请求（禁止直接推送）
• 更少且更快的必需检查（单元测试、冒烟测试、机密扫描）
• 需要批准，但仅限于值班人员/发布负责人
• 仍然阻止强制推送
• 仅允许极少数人绕过，并且始终记录日志