本卡屬 FR-167（母卡 CM-3241），卡 P1-9b，階段 P1 升級變安全、批 6。只改 BE（主 repo，Repo 欄空著）。依賴：P1-7。
CI 多一個排練 job：先在 e2e 機裝舊版、灌真實舊庫，再用新包升級；失敗就不准出包。這張卡只做腳本與 job 定義並在本機 dry-run，真跑 pipeline 是測試期的事。
1.21.0 的 fr093-4d 就是這樣抓到的；要自動化
extend：deploy_e2e.sh 既有 e2e 路徑加「先裝指定舊版」參數；舊庫用 smoke_tempdb 既有的 dump 來源
repo：~/Projects/Billows/Audit-Manager/compliance-manager-be
改既有：.gitlab-ci.yml
改既有：scripts/build/deploy_e2e.sh
細節在 design.md §5 對應段（~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/design.md，開 design.html 看導覽）；本段只列本卡要做到的點：
scripts/build/deploy_e2e.sh 加 --base-version <舊版>（先裝指定舊包、灌 smoke_tempdb.sh 用的那份 dump，再用新包 guidantai upgrade）與 --dry-run（只印步驟）。.gitlab-ci.yml 加 rehearse-upgrade job（stage 在 package 前；needs build 三顆；失敗 package 不跑）。--dry-run 與 glab ci lint；不跑 pipeline、不碰 190。glab ci lint 綠；deploy_e2e.sh --base-version 1.26.0 --dry-run 印出會做的步驟（先裝舊版、灌 dump、再 upgrade）且參數解析有 test；job 的 needs／rules 讓它紅就擋 package（讀 yaml 驗）。不跑 pipeline、不碰 190
測試期（不是你做）：這張卡在 190 的真實情境是「pipeline 多一個 rehearse-upgrade job：190 裝 1.26.0 → 新包升級成功、筆數一致；放壞 migration 時 job 紅、package 不跑」，由首腦在測試期操作、決策者看畫面。你只要確保上面的本機驗收全過、程式對這個情境沒有寫死假設。
對照雛形：~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/prototype/index.html（上方「跟著走」）。