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限制得到遵守，電話準備就緒。

簡短的結論

精心設計的定格管線將發行版轉變為可管理的例程：單一模板，清晰的質量目標，受保護的供應鏈，漸進式滾動和可觀察性降低了風險，並減少了生產變更的輸出時間，同時保持了質量控制和業務指標。