4. 门禁配置管理：声明式定义、存储与版本化

在 GitOps 流水线中，门禁配置本身也是“代码”。将门禁规则以声明式方式定义、存储在 Git 仓库中，并实施版本化管理，是确保门禁系统可审计、可回滚、可复现的核心实践。本章聚焦门禁配置的声明式定义方法、存储位置策略以及版本化管理机制。

4.1 门禁配置的声明式定义

声明式定义的核心思想是：描述门禁规则的“期望状态”，而非“如何执行”。常见的声明式门禁配置格式包括 YAML、JSON 或 HCL。以下是一个基于 YAML 的门禁规则定义示例：

apiVersion: gating.example.com/v1
kind: GateConfig
metadata:
  name: production-gate
  namespace: default
spec:
  gates:
    - name: code-review
      type: approval
      requiredApprovals: 2
      approverGroups: ["senior-devs", "security-team"]
    - name: unit-test
      type: test
      minPassRate: 90
      requiredDuration: "5m"
    - name: security-scan
      type: scan
      scanner: "trivy"
      severityThreshold: "HIGH"
      failOn: "CRITICAL"
    - name: integration-test
      type: test
      minPassRate: 100
      requiredDuration: "15m"
  order:
    - code-review
    - unit-test
    - security-scan
    - integration-test
  rollbackOnFailure: true

上述配置定义了四个门禁关卡及其执行顺序。每个门禁都包含类型、阈值、参数等关键属性。声明式定义的优势在于：

• 可读性：使用结构化格式，便于团队成员理解门禁规则。
• 可校验：可通过 Schema 验证配置的合法性，避免运行时错误。
• 可组合：支持通过引用或模板组合复用门禁规则。

4.2 配置存储位置（Git 仓库）

门禁配置的存储位置直接影响其可发现性和管理效率。推荐采用以下两种策略：

实践中，推荐采用混合模式：全局基础门禁规则存储在集中仓库，而服务特定的门禁规则（如自定义测试阈值）存储在应用仓库中。流水线在执行时，会合并两层配置。

4.3 配置版本化管理

版本化管理是 GitOps 的基石。门禁配置的版本化管理包括以下核心机制：

• Git 标签与分支：使用语义化版本标签（如 v1.2.3）标记门禁配置的发布版本。使用分支（如 release/1.0）管理长期支持版本。
• 变更记录：每次门禁配置变更必须附带清晰的 Commit Message，描述变更原因和影响范围。
• 回滚能力：通过 Git revert 或 reset 快速回滚到上一个稳定版本。
• 审计追踪：所有配置变更的历史记录、审批人、时间戳均保存在 Git 日志中。

以下是一个门禁配置版本化管理的典型工作流：

1. 开发者修改门禁配置 YAML 文件。
2. 提交 Pull Request，触发配置校验流水线。
3. 审批通过后合并到主分支。
4. 自动创建 Git 标签（如 gates-v1.4.0）。
5. ArgoCD 或类似工具检测到配置变更，自动同步到目标环境。

4.4 门禁配置版本化架构图

下图展示了门禁配置从定义、存储到版本化管理的完整架构：

4.5 配置版本化对比表

下表对比了不同版本化管理策略的适用场景和关键特性：

4.6 门禁配置版本化工作流

下图展示了门禁配置从修改到生效的完整版本化工作流：