持續部署

1）CD是什麼以及它與CI/CD的區別

持續部署（連續部署，CD）是自動釋放每個經過驗證的跨度更改的做法，而無需手動「釋放列車」。CD與CI（自動裝配和商品測試）的不同之處在於，它完成了鏈條：代碼→工件→驗證→生產。在受監管的行業中，CD通常與漸進式交付（分階段發布，受眾限制）結合在一起。

• 減少市場時間和變更成本。
• 減少大版本的風險：小批量→更容易找到原因和回滾。
• 引導質量紀律：「每個商品都是潛在的銷售」。

2）基本原則

小調。短的fiche樹枝，快速咆哮，激進的merging。
組件的確定性。可重復的廣告牌環境，鎖定文件，hermetic builds。
Shift-left質量。Linters，靜態分析，unit/合同測試在集成之前。
像環境一樣生產。相同的configs，通過vault的秘密，數據是合成/非個人化的。
全程自動化。從commit到路由流量和回滾。
默認可觀察性。度量標準，logs，traces，alertes-作為Definition of Done的一部分。
按設計安全。SAST/DAST，SCA，簽名工件，策略驗證。

3）pipline CD參考體系結構

1.觸發器：VCS（推動/merge）中標記為「prod-eligible」的事件。
2.Build：工件組裝（圖像，軟件包），SBOM，簽名（Sigstore/Cosign）。
3.測試快速：lint/unit/合同；快速後退（<5-10分鐘）。
4.測試深度（並行）：集成，E2E，負載「輪廓」，堆棧中的混沌樣本。
5.安全門：SAST/DAST/SCA，秘密檢查，策略檢查（OPA/Conftest/Kyverno）。
6.Compliance Gate：如有必要,SoD/4眼,索償的可追蹤性,支票單。
7.Promote：通過環境（dev stage → prod）將工件提升為相同的→。

8.Deploy Strategy: blue-green / canary / progressive + feature flags.

9.後部署驗證：降解時的自動健康，SLO/SLA，變量，自動滾動。
10.Audit&Evidence：工件、日誌、檢查協議-在不變的存儲中。

4）發布策略

Blue-Green：兩個探測站（Blue=當前,Green=新）,原子路由切換。另外-即時回滾。減號-雙重基礎架構。
金絲雀：帶有自動SLO門的流量分量啟動（1% → 5% → 25% → 100%）。
進步交付：目標隊列（區域，提供商，VIP段），病變半徑限制。
Feature Flags：提供「關閉」代碼,按用戶/cohorts打開。必然：「flag lifecycle」策略。

5）測試和質量

獨立微服務發布的合同測試和消費者驅動合同。
按實際模式（RPS, p95/p99,開放/封閉型號）設置負載配置文件。
DB遷移測試：直接/可逆,兩個版本的兼容性（expand →合同）。
Chaos/Resilience試用：斷開依賴關系、網絡延遲、資源限制。
從接近用戶的點進行射擊後檢查（smoke+synthetic）。

6） CD中的安全和合規性

文物簽名，provenance，SBOM。追蹤來源，消除「供應鏈」風險。
Policy-as-Code：我們只允許從受信任的註冊表中讀取映像,並進行掃描。
秘密：短壽命令牌，可旋轉密鑰，KMS；禁止在git中隱藏秘密。
職責分工（SoD）：開發≠程序訪問；所有操作都是通過管道進行的。
審核跟蹤：不變的發布日誌,是誰/什麼/何時；通過監管來存儲N年。

7）變更管理和風險控制

Change Types：標準（全自動）、正常（自動+批準）、緊急（加速窗口+後處理）。
CAB極簡主義：CAB用於改變風險和基礎設施「打破」升級，其余通過自動質量門。
風險矩陣：影響×概率→策略選擇（金絲雀更深，標誌，附加監控）。
Runbooks&Playbooks：針對每種發行和回滾類型的明確說明。

8）可觀察性，SLO和自動滾動

黃金信號：潛伏期，錯誤，飽和，交通；業務指標（轉換、存款、付款成功）。
Guardrails：如果p95>閾值，error rate↑，業務metrika↓是自動停止/回滾。
發布儀表板：小部件：versiya→metriki→flagi→kanareyechnyye流量份額。
Alerts：降噪水平、呼叫旋轉、事件管理聯系。

9）CD度量

DORA度量標準：降級頻率，更改時間領先，MTTR，發行失敗的比例。
隊列上的更改失敗率（按提供商，區域，設備）。
門的通過時間：瓶頸在哪裏（安全掃描、集成測試）。
成本到釋放：窗口分鐘成本,基礎架構策略加價（藍色綠色vs金絲雀）。

10）回滾模式和兼容性

自動滾動：在路由級別（交通開關）和/或轉換級別（K8s滾動undo）。
DB遷移：expand-migrate-contract策略,幻燈片掩蓋了無法訪問的字段。
Idempotency&Exactly-once-like：對於隊列/支付-等速鍵，重復數據消除。
Back-pressure和graceful degradation：降級時-禁用不起作用的菲奇。

11）實用環境模型

GitOps方法：目標狀態存儲在git,控制器應用清單。
Environments：「dev」（快速和骯臟），「stage」（像素描，混沌樣本），「prod-A/B」（藍綠色）或帶有金絲雀池的「prod」。
數據隔離：作為數據的configs，映像外的秘密，單獨的憑據/限制。

12）流程和角色

RACI：架構師（策略），平臺團隊（管線，集群），產品團隊（測試/標誌），安全性（策略/掃描），SRE（SLO/可靠性）。
ChatOps：從PR機器人發布，狀態可見，「/promote」，「/rollback」。
SOP：發布支票單，發布後評論，「aging」旗幟控制。

13）高調控域的功能（如iGaming/fintech）

可跟蹤性：審計中的trebovaniye→tiket→PR→bild→artefakt→sreda→log。
Geo版本：按國家/司法管轄區,具有本地支付配置/CUS。
反親和力/風險引擎：金絲雀流量池，監視假正向/非正向。
KYC/AML/負責任的遊戲：通過帶有強制用戶曝光監視的標誌釋放菲奇。

14）頻繁的反模式

階段之間的手動步驟（「用手帶來了人工制品」）。
沒有主人和壽命的「灰色旗幟」。
一個常見的「厚」集成測試代替合同。
沒有可逆的DB遷移。
降級後而不是降級後的安全掃描。

15）CD準備就緒迷你支票清單

• 比爾是確定性的；文物簽名；有SBOM。
• E2E人的合同測試和測試。
• 安全/合規門作為代碼；秘密-通過保險庫。
• 可觀察性：邏輯/度量/軌跡，發布的行車記錄儀，SLO門。
• 發布策略：canary/blue-green+auto-rollback。
• DB遷移程序（expand/contract）。
• 具有「創建→使用→刪除」策略的特征旗。
• RACI/Runbooks/ChatOps集成。

16）流示例（腳本）

1.「主線」中的Merge觸發管道。
2.容器裝配，簽名，SBOM。
3.Lint/unit/合同 →通過。
4.SAST/SCA/秘密掃描 →「綠色」。
5.舞臺上的汽車浪漫：E2E+混亂+輪廓負荷。
6.金絲雀占1%，誤差/潛伏控制/業務指標。
7.升級到25%/50%/100%的綠色門。
8.自動顯示「rollout-guard」標誌,記錄審核工件。
9.發布後審查，刪除臨時標誌。

17）結果

CD不是「丟棄按鈕」，而是小，安全和觀察到的變化的文化。通過正確的策略和自動化，CD可以降低風險，加快價值交付，並使發行成為例行公事而不是事件。對於高負載和可調節的系統，成功的關鍵是嚴格的質量門，分步滾動，幻燈片，可觀察性和每個步驟的可重復性。