Staging pipline和发行

1）为什么需要停靠管线

• 构建和发布的可重复性；
• 快速和可预测的支线；
• 最大限度地减少风险（渐进式滚动、ficheflagi、回滚）；
• 合规性和变更控制。

2）参考供应流（高水平）

1.PR →自动检查（lint、unit、SAST、许可证）。
2.Build →确定性映像/数据包、签名和SBOM。
3.Ephemeral测试→公关预览环境。

4.Merge → Staging:

丢弃图像；

合同、集成、e2e测试；

DAST/IAST，回收，负载烟雾；

如有必要，手动UAT/QA。

5.Release Candidate (RC) → freeze window → Prod (canary/blue-green).

6.对SLO/error预算进行后期检查和自动检查。
7.Runbook/Changelog →关闭发行和回顾展。

3）标准化的YAML管线模板（摘录）

yaml
.ci/release.pipeline.yml stages: [verify, build, test, stage, approve, release, post]

verify:
- run: make lint test:unit sbom sast sca build:
- run:
docker build -t registry/app:$GIT_SHA.
cosign sign registry/app:$GIT_SHA oras push registry/sbom:$GIT_SHA sbom.json test:
- run: make test:contract test:integration
- run: make deploy:preview && make test:e2e stage:
- run: make deploy:staging IMAGE=registry/app:$GIT_SHA
- run: make test:e2e:staging && make dast approve:
manual gate: CAB/QA lead
- type: manual required_roles: [release_manager, qa_lead]
release:
- run: make release:canary TRAFFIC=5%
- run: make release:progressive STEPS="5,25,50,100"
post:
- run: make verify:slo && make notify && make create:changelog

4） Gates和准备标准（Quality Gates）

代码和安全：镜头，覆盖，SAST/SCA，依赖性政策，不存在"关键/高"。
合同：电路兼容性（API/事件），Pact/Buf验证。
测试：unit/integration/e2e p-通过阈值、稳定性（flake-rate）。
负载烟雾：p95/p99在预算范围内,没有降解。
DAST/IAST：没有关键的发现，敏感路径的泡沫测试场景。
观察力：dashbords/alerta "as code"已更新，runbooks已附加。
CAB/UAT：在发布窗口中确认（如果法规要求/业务要求）。

5）发布策略

金丝雀-流量份额逐渐增加（5％ → 25％ → 50％ → 100％），SLO和异常情况下的自动滚动/滚动。
蓝绿色-平行环境；瞬时开关，简单回滚。
Feature Flags-合乎逻辑地启用了没有redeploy的幻影；"黑暗发射"和A/B的可能性。
Shadow/Traffic Mirroring是对新版本的被动流量运行，对用户没有影响。
Ring Deployments是按地区/特南特划分的波浪。

6）回滚和发布安全策略

触发自动击退：错误率上升,p95/TTFB高于阈值,5xx/timeout增长,DLQ激增。
手动回滚：聊天机器人中的命令'/rollback <service> <sha>",发行控制台中的单个按钮。
Freeze windows：禁止发布到关键事件（锦标赛/高峰赛）。
Changelog&Release Notes：从PR生成,SemVer标签,组件,迁移。

7） DB迁移和互操作性

Expand → Migrate → Contract:

1.添加兼容字段/索引；

2.deploy应用程序（读取/写入两个方案）；

3.背景乔布斯数据迁移；

4.删除旧的。
方案进行转换，移交idempotent，dry-run到堆栈。
Protect destructive SQL： require flag/approval、自动备份和计划检查。

8）Ficheflagi和渐进激活

共享操作标志（用于安全操作）和产品标志。
按受众分列：百分比，地质，特南特，角色。
标志度量：对转换，后退，错误的影响。
有问题时-国旗卷积速度比回滚速度快。

9） Observability作为发布的一部分

Traces：从网关到DB/队列的端到端 "trace_id"；旧版本/新版本的比较。
度量标准：p50/p95/p99, error-rate, RPS, saturation, DLQ, retrais, Time-to-Wallet/Business KPI。
Logs：结构化的PII掩码,相关性"request_id"。
Alerts： SLO预算、紧急呼叫页面、自动卷积发布。

10）供应链安全（供应链）

SBOM用于每个法案，存储和绑定到发布标签。
映像签名（cosign）、群集验证（策略管理）。
SLSA认证：可证明的人工制品来源。
Policy-as-Code （OPA/Conftest）：用于基础架构PR的deny-by-default。
秘密：仅来自KMS，短寿命令牌，在管道中旋转。

11）变更控制与流程

RFC → CRQ → CAB：事先商定可记录的行为/合同变更。
Release Calendar：按产品/地区/团队可见的窗口。
Runbooks：每个组件的启用/回滚/诊断过程。
Postmortem/Retro：在有意义的版本之后-分析和动作。

12） staging测试简介

合同（API/Events）：阻止不兼容的更改。
整合/e2e："存款"，"KYC"，"输出"的端到端场景。
负载烟雾：代表性峰；跟随资源限制。
溷沌场景：断开提供商连接、潜伏期增长、网络翻转。
合成监控：按计划进行"试用"交易。

13） Makefile发布目标的示例（片段）

makefile release: verify build test stage approve prod post verify:
@make lint test:unit sbom sast sca build:
docker build -t $(IMG).
cosign sign $(IMG)
test:
@make test:contract test:integration deploy:preview test:e2e stage:
kubectl apply -k deploy/staging approve:
@echo "Waiting for QA/CAB approval..."
prod:
make release:canary TRAFFIC="5 25 50 100"
post:
@make verify:slo notify changelog

14）角色和责任

Dev/Team：代码质量，测试，迁移，运行手册。
QA：UAT/regression脚本，gates质量控制。
SRE/平台：管道可靠性，可观察性，策略。
Release Manager：日历、窗口、CAB、最终解决方桉。
安全：SAST/DAST/SCA，供应链，保密策略。

15）发布成熟度模型

1.基本的手动检查，罕见的发布，回滚是困难的。
2.先进的-标准化的CI/CD，迭加轮廓，金丝雀/蓝绿色，频繁发行。
3.专家-逐项递送，功能横幅第一，策略即代码，SLO自动售货机，完全可跟踪性和SLSA。

16）实施路线图

M0-M1 （MVP）： pipline模板,build+sign+SBOM, staging deplo, basic tests and gates。
M2-M3：金丝雀/蓝绿色，公关预览，合同测试，DAST，合成检查。
M4-M6：功能横幅平台、影子交通、政策即代码、自动售货机、发布日历+CAB造纸机。
M6+：按地区分列的ring-deployments，SLSA认证和严格的管理，完全自动化runbooks。

17）Prod发行前的支票清单

• 映像已签名,SBOM已下载并绑定到发行版。
• 合同是兼容的，测试是绿色的，e2e在舞台上通过。
• 已验证（dry-run）,备份已准备就绪,描述了回滚计划。
• Dashbords/Alertes已更新，SLO门处于活动状态。
• Runbook和Changelog已发布，发布窗口已达成一致。
• Feature flags配置为逐步激活。
• Freeze限制得到遵守，电话准备就绪。

简短的结论

精心设计的定格管线将发行版转变为可管理的例程：单一模板，清晰的质量目标，受保护的供应链，渐进式滚动和可观察性降低了风险，并减少了生产变更的输出时间，同时保持了质量控制和业务指标。