Digest-first基於不可變內容雜湊（SHA-256摘要）而非可變標籤的發行識別——確保逐位元組一致的部署 發行身分版本由內容尋址的 SHA-256 摘要識別，而不是可變標籤。相同摘要 = 相同產出物 = 相同證據。
- → 推進時標記→摘要解決
- → 相同摘要升級時重用的證據
- → 不可變責任鏈
發行編排
證明自己的推進活動
Environment具備感知的工作流程、政策閘門，以及以摘要為先的身分。每個發行決策都會匯出一個加密簽名的 Decision Capsule簽名的可匯出證據包，封裝發行決策的每個輸入和輸出，用於離線稽核和確定性重播。
典型CD工具的問題
大多數部署工具都會告訴您部署了什麼。他們無法告訴您為什麼部署是安全的。
典型CD工具
- ✗ 基於標籤的版本 - 可變，無法追踪
- ✗ 與產出物斷開連接的核准
- ✗ 部署時沒有安全狀況證據時間
- ✗ 回滾是“重新部署和希望”
Stella Ops編排
- ✓
Digest-first基於不可變內容雜湊（SHA-256摘要）而非可變標籤的發行識別——確保逐位元組一致的部署身分——不變、可稽核 - ✓ 綁定到精確產出物雜湊的核准
- ✓ Decision Capsule中記錄的安全判決
- ✓ 回滾到已知良好狀態證據
核心編排功能
Environment邏輯部署目標（例如dev、staging、prod），追蹤自己的發行歷史、晉升規則和策略門控意識推進將管道建模為具有升級規則的環境。開發→階段→生產，每一步都有證據門。
- → 每個環境的升級規則和核准要求
- → 通過基於日曆的阻止凍結窗口
- →
Environment邏輯部署目標（例如dev、staging、prod），追蹤自己的發行歷史、晉升規則和策略門控專屬政策剖面 - → 每個步驟的即時部署 UI記錄
每一步都有策略門
推進活動需要通過大門。安全判決、核准簽名和凍結窗口都會經過評估。
- → 安全門 — 掃描判決必須通過閾值
- → 核准門 — 已收集所需簽名
- → 通過
OPA開放策略代理 — 一個開源策略引擎，用於在整個堆疊中進行細粒度、上下文感知的策略執行/Rego 策略自定義門
與證據相關的回滾
回滾到具有完整證據追蹤的先前摘要。準確了解您要返回的內容。
- → 回滾目標特定摘要，而不是“先前”版本”
- → 保留原始推進的證據
- → 回滾本身會產生新的
Decision Capsule簽名的可匯出證據包，封裝發行決策的每個輸入和輸出，用於離線稽核和確定性重播
增量部署策略
每一步都有證據的漸進式推出。具有回滾安全性的 A/B 測試、金絲雀和功能標記部署。
- → 流量的 A/B 和金絲雀部署拆分
- → 功能標記版本（nginx重新載入、微服務插件）
- → 自動回滾觸發器的增量推出
請參閱操作
每個升級命令都會輸出結構化證據。
$ stella release promote api-gateway --to staging --reason "gate passed"
工作流引擎功能
DAG 執行
並行和順序執行的步驟圖。
步驟登錄庫
內建步驟加上自定義自動化。
工作流程模板
跨項目可重用的工作流程。
腳本步驟
用於自定義邏輯的 Bash 和.NET 腳本。
凍結窗口
基於日曆的部署阻止。
審核匯出
合規性證據包。
有何不同
Decision Capsule
每個推進活動都密封在可匯出、可重播的證據包中。
確定性重播
6 個月後重新執行任何升級決策，結果相同。
證據連結
由加密雜湊綁定的核准、判決和產出物。
部署模式
A/B 部署
在兩個發行版本之間路由流量。比較指標，然後向獲勝者提供證據。
金絲雀版本
首先推出到一小部分目標。僅在證據門通過後才能更廣泛地推進。
Blue/Green 切換
維護兩個相同的環境。策略評估後自動切換流量。
回滾到已知良好
立即恢復到最後一次已知的良好摘要。保留前向和回滾推進的證據。
準備好進行證據級編排了嗎？
從環境設置和第一次推進開始。