流程定位

App 部署的風險集中在不可變 artifact 與外部 gate。IPA、APK、AAB 或桌面安裝包一旦被使用者安裝，團隊需要靠 hotfix、remote config、kill switch 或服務端相容性止血；store review、簽章憑證與 phased rollout 會決定錯誤版本能否快速收斂。

Version 階段負責讓 artifact 可追溯。App crash report、客服回報與 store console 都依賴 version / build number；版本號對應 commit 與 workflow run 時，事故定位可以直接回到發布紀錄。

App signing 階段負責維持發布信任鏈。簽章憑證、provisioning profile、keystore 與 notarization credential 都是發布能力；它們要用 secret 管理、權限隔離、輪替與備援流程保護。

Test 階段負責覆蓋目標裝置條件。App 測試要依實際使用者分佈選擇 OS、裝置、權限狀態、網路條件與升級路徑；只跑 emulator smoke test，通常抓不到真機權限、背景限制或升級資料遷移問題。

Store review 階段負責處理外部 gate。審核可能因 metadata、隱私揭露、權限使用、付款政策或 crash 被拒；CI/CD 文件要記錄誰能處理審核回覆、哪些變更需要重新提交。

Rollout strategy 階段負責控制新版本擴散速度。分批發布的觀察指標包含 crash rate、登入、購買、同步、推播與核心流程完成率；達到停損條件時應暫停 rollout，先讓已受影響範圍維持可控。

Recovery 階段負責處理已安裝版本。App 常見止血工具是 remote config、feature flag、kill switch、server-side compatibility、hotfix build 與要求使用者升級；每個工具都要在事故前實作，事故時才有路可走。

多版本共存契約

多版本共存是 App 發布的基本前提。後端 API、資料格式、推播 payload 與 remote config 都要支援一段時間的新舊 client，因為使用者更新節奏不受團隊完全控制。

這些契約要在 CI 或 release checklist 裡被驗證。若只靠後端「盡量相容」，App 發布失敗會在使用者更新後才暴露，回復成本會比 web 或後端高。

Release checklist

Release checklist 的責任是把外部 gate 與內部 gate 接起來。App 發布牽涉商店、憑證、客服、行銷與後端相容，因此 checklist 應該是流程契約，不只是提醒清單。

1. 確認 version、build number、commit 與 artifact 對應。
2. 確認 signing secret、profile 或 keystore 仍有效。
3. 跑 unit、UI、device matrix 與 upgrade test。
4. 檢查 API / remote config / push payload 多版本相容。
5. 上傳 internal / beta track，跑 smoke test。
6. 提交 store review，記錄審核狀態。
7. 用 phased rollout 推進，觀察 crash-free rate 與核心指標。
8. 觸發停損條件時暫停 rollout、關閉功能或準備 hotfix。

這個順序讓 App 發布從「把包丟上去」變成可觀測流程。每一步都對應一個失敗路由，事故時能知道下一個可執行動作。

下一步路由

• App 部署總覽：回 App 部署 CI/CD。
• 簽章概念：讀 App Signing。
• Gate 原理：讀 CI gate 與 workflow 邊界。

概念位置

Rollout Strategy 位在部署執行與正式流量切換之間，常見型態包含 rolling、canary、blue-green 與 phased rollout。

可觀察訊號

• 發布後需要觀察一段時間再擴大流量。
• 高風險變更不適合一次全量切換。
• 團隊需要把監控訊號綁定到擴大量決策。

接近真實服務的例子

後端 API 先以 10% canary 流量觀察錯誤率與延遲，再逐步推進。App 發布以 phased rollout 控制商店推送比例。

設計責任

Rollout Strategy 要定義推進節點、觀察指標、阻擋條件與升降級節奏，讓部署風險可被量化管理。

本篇以 5.2 Kubernetes 部署策略 與 5.3 load balancer 合約 為前置知識——rollout 批次、probe 對齊、drain contract 等概念在該兩篇定義，本篇直接操作化。lifecycle 狀態的完整定義見 5.6 Platform Lifecycle Contract。

服務路徑與切換責任

這條路徑是 client -> load balancer -> checkout-api -> payment provider/order db/order event。部署期間新舊版本會同時承接流量，核心風險在流量生命週期是否可收斂，image 替換本身反而是最可預測的部分。

切換責任分三層：

1. 版本可啟動：container/runtime/config 可用。
2. 版本可接流量：readiness 與依賴狀態對齊。
3. 版本可退場：drain 與在途請求可收束。

Preflight：先驗證可服務基線

Preflight 的責任是把「可啟動」與「可服務」拆開驗證。最小檢查包含：

1. image 與 runtime config 版本對齊。
2. secret 已注入且權限正確。
3. startup/readiness probe 能反映真實依賴狀態。
4. load balancer contract 參數與服務期望一致。
5. service discovery 註冊與摘除路徑可用。

Preflight 失敗時不進 canary。先把失敗收斂在控制面，避免切流後才發現版本不可服務。

Preflight 自動化

手動 preflight 在低頻部署時可行，部署頻率上升後會成為瓶頸或被跳過。穩定做法是把 preflight 檢查嵌入 CI/CD pipeline 的 pre-deploy stage：

1. image 與 config 版本對齊檢查：pipeline 比對即將部署的 image tag 與 ConfigMap / Secret 版本是否在相容矩陣內。版本矩陣可維護在 git（如 deploy/compat-matrix.yaml），CI 自動比對。
2. infra drift detection：部署前用 IaC 工具（Terraform plan、Crossplane drift check）掃描目標環境的實際狀態是否跟宣告狀態一致。drift 存在時暫停部署——在已漂移的環境上部署新版本，會把漂移與版本變更的影響混在一起，事故時無法分辨根因。
3. probe 語意驗證：在 staging 環境對新版本觸發 startup → readiness → liveness 全流程，確認 probe 回應與依賴就緒條件吻合。這步抓的是 probe 設定退化（如 readiness endpoint 被改成永遠回 200）。
4. rollback 可行性驗證：確認舊版本 image 仍在 registry 且可拉取、舊版本 config 仍相容。rollback 能力在 preflight 階段驗證，比事故時才發現「舊版拉不到」代價低得多。

Preflight 自動化的產出是一份 go/no-go 報告，進入 6.8 Release Gate 作為放行依據。pipeline 中的 preflight stage 失敗應阻擋部署而非產生警告——可忽略的 preflight 等於沒有 preflight。

Canary Batch 與 Stop Condition

小流量先驗證新版本行為，再決定是否擴批——Canary 回答的是「這個版本值不值得擴大」。

canary 判讀要維持 per-version 視角。只看整體服務平均值會掩蓋新版本局部退化。

Traffic / Drain：把退場變成可驗證流程

Drain 的責任是讓舊版本在下線前完成在途請求，不讓 rollout 把短暫切換放大成用戶錯誤。

退場順序：

1. 舊實例 readiness 先轉 not-ready 停接新流量。
2. 保留 drain 窗口完成 in-flight request。
3. 確認連線數下降到門檻後再終止進程。
4. 驗證無異常 reconnect 尖峰再進下一批。

Drain 條件的完整 workload 分類回到 5.6 Platform Lifecycle Contract，本段以 checkout service 為例：短 API 的 draining 窗口可短，長輪詢與 webhook callback 要更保守。

Rollback Compatibility

舊版本回來時仍可運作，是 rollback 能成立的前提——回退如果變成第二次故障，就失去了回退的工程價值。

要先驗證四個相容面：

1. config 相容：新設定不會讓舊版啟動失敗。
2. schema 相容：資料結構仍可被舊版讀取。
3. cache key 相容：舊版可讀新快取或有 fallback。
4. event schema 相容：舊版 consumer 不會因新事件欄位崩潰。

若這四項未完成，所謂 rollback 只會停在「版本回切」，無法恢復服務正確性。

Evidence Package

每一批切換要可被判讀、可被追責、可被回放——部署 evidence 支撐這三個條件。

這份 evidence 要對齊 4.20 Observability Evidence Package。

Release Gate

Release gate 的責任是決定下一批切換與是否凍結 rollout，不是報告「目前看起來正常」。

這組欄位要對齊 6.8 Release Gate。

Incident Decision Log

freeze rollout、rollback version、隔離 region、延長 drain 都屬事故決策，需寫入 8.19 Incident Decision Log。涉及流量規則 / control plane 設定推送的決策、見 5.7 跟 8.23 Control Plane Decision Log。

 1incident_decision:
 2  timestamp: 2026-05-11T15:06:00Z
 3  decision: "freeze rollout at 25% and rollback one region"
 4  context: "new version timeout to payment provider increased in ap-northeast"
 5  evidence:
 6    - query: checkout_error_rate_by_version_region
 7    - query: payment_timeout_ratio_by_region
 8  owner: release-incident-commander
 9  expected_effect: "contain customer impact and restore baseline success rate"
10  rollback_condition: "timeout ratio does not recover after rollback batch completes"

Case Write-back 與邊界

這篇回寫對齊 5.C9 反例、5.C1 Tradeshift 與 5.C3 Orbitera：前者看切換失序，後兩者看遷移路徑與回退策略。preflight / canary / drain 各階段的生命週期定義回到 5.6 Platform Lifecycle Contract。

這篇不處理 schema migration 本身、cache stampede 或 queue replay。若核心風險在資料正式狀態、快取回源或事件恢復，路由到 1.7 Schema Migration Rollout 證據、2.9 Cache Migration 與 Stampede Rollback 或 3.8 Queue Consumer Retry 與 Replay Handoff。