部署指南範本(Deployment Guide Template)

部署指南範本(Deployment Guide) 參照標準:ITIL 4 Release Management / ISO/IEC 20000-1:2018 第 8.5.2 節「Release management」 文件用途:提供系統部署的標準化步驟指引,確保可重複、可追蹤、可回滾的部署流程 適用階段:部署與上線階段(Release & Deployment) 📋 章節目錄 文件資訊 部署概述 先決條件 部署架構 部署步驟 驗證程序 回滾程序 監控確認 聯絡窗口 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 DG-{專案代碼}-{序號} 文件名稱 {系統名稱} v{版本} 部署指南 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 計畫部署日期 {YYYY-MM-DD HH:mm} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 依據 ITIL 4 Release Management 實務,每次部署需有正式的部署指南 文件需在部署前完成審核,未經核准不得執行部署 適用於所有環境(SIT / UAT / Staging / Production)部署 💡 範例 項目 內容 文件編號 DG-HRM-003 文件名稱 HRMS v1.0.0 正式環境部署指南 計畫部署日期 2026-10-15 22:00(維護窗口) 核准者 IT 副總 — 黃資訊 2. 部署概述 📝 範本 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 / 版本升級 / Hotfix / 組態變更 部署版本 {Application Version} 目標環境 {環境名稱} 部署方式 全量部署 / 滾動更新 / 藍綠部署 / 金絲雀部署 預估停機時間 {分鐘/小時} / 零停機 影響範圍 {受影響的服務/使用者} 維護窗口 {起始時間} ~ {結束時間} 2.2 變更內容摘要 變更編號 類型 描述 {CR/JIRA 編號} 功能/修復/組態 {簡述} 2.3 部署風險評估 風險等級 說明 高/中/低 {為何此等級} 📖 使用說明 部署類型決定所需的審核層級與流程嚴格度 Hotfix 可簡化流程但仍需記錄 預估停機時間需告知業務方,以便安排使用者通知 💡 範例 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 部署版本 HRMS v1.0.0 (Build #2026.10.12.1) 目標環境 Production (Azure AKS - hrms-prod) 部署方式 藍綠部署(Blue-Green Deployment) 預估停機時間 零停機(流量切換時間 < 30 秒) 影響範圍 全公司員工(約 2,000 人) 維護窗口 2026-10-15 22:00 ~ 2026-10-16 02:00 3. 先決條件 📝 範本 3.1 核准與簽核 項目 狀態 確認人 日期 變更審核委員會(CAB)核准 ☐ {姓名} {日期} 測試報告簽核 ☐ {姓名} {日期} 業務方確認上線同意 ☐ {姓名} {日期} 回滾計畫審核 ☐ {姓名} {日期} 3.2 技術先決條件 項目 驗證方式 狀態 {基礎設施就緒} {驗證命令/方式} ☐ {相依服務可用} {驗證命令/方式} ☐ {資料庫備份完成} {驗證命令/方式} ☐ {SSL 憑證有效} {驗證命令/方式} ☐ {DNS 設定確認} {驗證命令/方式} ☐ 3.3 部署所需權限 系統/資源 所需權限 帳號 {系統} {權限} {帳號} 📖 使用說明 所有先決條件需在部署開始前全部確認(Checklist 全部打勾) 任何一項未完成則不得啟動部署 資料庫備份是最關鍵的先決條件,未備份禁止部署 💡 範例 3.2 技術先決條件 項目 驗證方式 狀態 AKS 叢集節點 ≥ 4 kubectl get nodes 確認 Ready ☑ PostgreSQL 資料庫完整備份 確認 Azure Backup 最新備份 < 1 小時 ☑ Redis Cache 可連線 redis-cli ping 回應 PONG ☑ AD 連線正常 測試 LDAP bind ☑ Container Registry 映像已推送 az acr repository show-tags 確認 v1.0.0 存在 ☑ SSL 憑證效期 > 30 天 openssl s_client 確認到期日 ☑ 4. 部署架構 📝 範本 4.1 目標環境架構圖 {架構圖或 Mermaid 圖} 4.2 環境資訊 元件 主機/端點 規格 備註 Application Server {Host/IP} {CPU/RAM} {說明} Database {Host/IP:Port} {版本/規格} {說明} Cache {Host/IP:Port} {版本/規格} {說明} Load Balancer {Host/IP} {類型} {說明} Storage {Host/Path} {容量} {說明} 4.3 網路與防火牆規則 來源 目的 Port Protocol 用途 {來源} {目的} {Port} TCP/UDP {用途} 📖 使用說明 架構圖幫助部署人員理解全貌,建議使用 Mermaid 或繪製圖示 網路規則需在部署前確認已開通,避免部署後才發現連線失敗 機敏資訊(密碼、連線字串)不寫入文件,使用 Secret Manager 或變數引用 💡 範例 4.1 目標環境架構圖 Internet → Azure Front Door → AKS Ingress → Service ├── hrms-api (3 replicas) ├── hrms-worker (2 replicas) └── hrms-web (3 replicas) ↓ PostgreSQL (Azure DB for PostgreSQL) Redis (Azure Cache for Redis) Azure Blob Storage 5. 部署步驟 📝 範本 5.0 部署前通知 時間 對象 通知方式 內容 部署前 {N} 小時 {對象} {方式} {內容} 5.1 資料庫變更 步驟 指令/操作 預期結果 確認者 1 {SQL / Migration 指令} {預期輸出} {姓名} 2 {SQL / Migration 指令} {預期輸出} {姓名} 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 {部署指令} {預期輸出} {姓名} 2 {部署指令} {預期輸出} {姓名} 5.3 組態更新 步驟 指令/操作 預期結果 確認者 1 {組態變更指令} {預期結果} {姓名} 5.4 流量切換 步驟 指令/操作 預期結果 確認者 1 {切換指令} {預期結果} {姓名} 📖 使用說明 步驟需按執行順序排列,不可跳步 每步驟需有具體指令(可複製貼上執行)與預期結果 「確認者」在部署時簽名確認該步驟已完成 資料庫變更必須先於應用程式部署(確保 schema 相容) 機敏值(密碼)用環境變數或 Secret 引用,不寫死 💡 範例 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 kubectl set image deployment/hrms-api hrms-api=hrmacr.azurecr.io/hrms-api:v1.0.0 -n hrms-prod deployment.apps/hrms-api image updated DevOps 2 kubectl rollout status deployment/hrms-api -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 3 kubectl set image deployment/hrms-web hrms-web=hrmacr.azurecr.io/hrms-web:v1.0.0 -n hrms-prod deployment.apps/hrms-web image updated DevOps 4 kubectl rollout status deployment/hrms-web -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 5 確認所有 Pod 狀態正常:kubectl get pods -n hrms-prod 所有 Pod 狀態為 Running,READY 1/1 DevOps 6. 驗證程序 📝 範本 6.1 Smoke Test(冒煙測試) 測試項目 驗證方式 預期結果 實際結果 Pass/Fail {基本功能 1} {驗證方式} {預期} {實際} {基本功能 2} {驗證方式} {預期} {實際} 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail {端點} {指令} {預期} {實際} 6.3 整合驗證 驗證項目 驗證方式 預期結果 實際結果 Pass/Fail {外部系統連接} {指令/操作} {預期} {實際} 6.4 部署成功判定標準 標準 說明 所有 Smoke Test 通過 — 健康檢查端點回應 200 持續 5 分鐘 無 Critical/High Alert 部署後 15 分鐘內 日誌無異常 Error 抽查近 100 條 Log 📖 使用說明 驗證程序在部署完成後立即執行,決定是否接受本次部署 Smoke Test 覆蓋核心業務路徑(如登入、主要功能),不需全面測試 若任何 P1 驗證失敗,立即啟動回滾程序 💡 範例 6.1 Smoke Test 測試項目 驗證方式 預期結果 實際結果 Pass/Fail 首頁可存取 curl -s -o /dev/null -w "%{http_code}" https://hrms.company.com 200 200 Pass 員工登入 使用測試帳號登入 成功進入首頁 成功 Pass 請假申請 建立一筆特休假申請 申請成功,狀態=待審核 成功 Pass 薪資查詢 查詢本月薪資明細 顯示薪資資料 成功 Pass 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail API Health curl https://hrms-api.company.com/health {"status":"healthy"} 同預期 Pass DB 連線 curl https://hrms-api.company.com/health/db {"status":"connected"} 同預期 Pass Redis 連線 curl https://hrms-api.company.com/health/cache {"status":"connected"} 同預期 Pass 7. 回滾程序 📝 範本 7.1 回滾觸發條件 條件 決策者 {觸發條件 1} {角色} {觸發條件 2} {角色} 7.2 回滾步驟 步驟 指令/操作 預期結果 確認者 1 {回滾指令} {預期} {姓名} 2 {回滾指令} {預期} {姓名} 7.3 資料庫回滾 步驟 指令/操作 預期結果 確認者 1 {DB 回滾指令} {預期} {姓名} 7.4 回滾後驗證 驗證項目 方式 預期結果 {驗證項} {方式} {預期} 7.5 回滾時間預估 項目 預估時間 應用程式回滾 {分鐘} 資料庫回滾 {分鐘} 驗證完成 {分鐘} 總計 {分鐘} 📖 使用說明 每次部署必須有回滾計畫,這是 ITIL 4 Release Management 的核心要求 回滾步驟需預先演練驗證,不可「部署當天第一次嘗試回滾」 資料庫回滾是最複雜的部分(若有 schema 變更),需特別規劃 藍綠部署的回滾最簡單:切回舊版流量即可 💡 範例 7.1 回滾觸發條件 條件 決策者 Smoke Test 失敗 2 項以上 DevOps Lead 部署後 15 分鐘內出現 Critical Alert DevOps Lead 業務方回報核心功能異常 IT 副總 部署超過維護窗口仍未完成 DevOps Lead + PM 7.2 回滾步驟(藍綠部署) 步驟 指令/操作 預期結果 確認者 1 通知團隊啟動回滾 Teams 群組通知已發送 DevOps Lead 2 kubectl rollout undo deployment/hrms-api -n hrms-prod rollback to previous revision DevOps 3 kubectl rollout undo deployment/hrms-web -n hrms-prod rollback to previous revision DevOps 4 kubectl rollout status deployment/hrms-api -n hrms-prod successfully rolled out DevOps 5 執行 Smoke Test 驗證回滾成功 所有項目 Pass QA 6 通知業務方服務已恢復 Email/Teams 通知已發送 PM 8. 監控確認 📝 範本 8.1 部署後監控期間 項目 內容 加強監控期間 部署後 {N} 小時 監控人員 {姓名/值班表} 告警通知管道 {方式} 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API 回應時間 (P95) < {ms} > {ms} {工具} Error Rate < {%} > {%} {工具} CPU 使用率 < {%} > {%} {工具} Memory 使用率 < {%} > {%} {工具} 活躍連線數 < {N} > {N} {工具} 8.3 日誌檢查項目 日誌類型 檢查重點 工具/指令 Application Log {重點} {工具} Access Log {重點} {工具} Error Log {重點} {工具} 📖 使用說明 部署後加強監控是確保部署穩定的最後一道防線 監控期間內若指標異常,仍可啟動回滾 建議部署後 24 小時為加強監控期,48 小時後轉為一般監控 💡 範例 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API P95 回應時間 < 200ms > 500ms Grafana + Prometheus Error Rate (5xx) < 0.1% > 1% Azure Monitor CPU 使用率 < 60% > 85% Azure Monitor Memory 使用率 < 70% > 90% Azure Monitor Pod Restart Count 0 > 2 Kubernetes Dashboard DB Connection Pool < 80% > 95% Application Insights 9. 聯絡窗口 📝 範本 角色 姓名 電話 備用聯絡 職責 部署指揮 {姓名} {電話} {備用} 部署決策、Go/No-Go 判定 DevOps 工程師 {姓名} {電話} {備用} 執行部署操作 DBA {姓名} {電話} {備用} 資料庫變更 開發 Lead {姓名} {電話} {備用} 技術問題排除 QA {姓名} {電話} {備用} 部署驗證 業務窗口 {姓名} {電話} {備用} 業務確認 📖 使用說明 部署當天所有窗口需保持電話暢通 部署指揮負責 Go/No-Go 決策與回滾決定 建議建立即時通訊群組(如 Teams/Slack War Room)方便即時溝通 💡 範例 角色 姓名 電話 備用聯絡 職責 部署指揮 黃資訊(IT 副總) 0912-xxx-xxx Teams Go/No-Go 決策 DevOps 周維運 0933-xxx-xxx Teams 執行部署 DBA 趙資料 0922-xxx-xxx Teams DB Migration 開發 Lead 吳開發 0955-xxx-xxx Teams 問題排查 QA 林品質 0966-xxx-xxx Teams Smoke Test 10. 附錄 📝 範本 10.1 部署 Checklist 總表 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☐ 部署前 資料庫備份完成 ☐ 部署前 通知使用者 ☐ 部署中 DB Migration 完成 ☐ 部署中 應用程式部署完成 ☐ 部署後 Smoke Test 通過 ☐ 部署後 健康檢查正常 ☐ 部署後 監控指標正常 ☐ 部署後 通知使用者服務恢復 ☐ 10.2 相關文件 文件 說明 {文件名} {用途} 10.3 術語定義 術語 定義 CAB Change Advisory Board,變更諮詢委員會 Blue-Green 藍綠部署,同時維護兩套環境,透過流量切換完成零停機部署 Smoke Test 冒煙測試,部署後快速驗證核心功能 Rollback 回滾,將系統恢復至部署前的版本 Maintenance Window 維護窗口,預先規劃的系統維護時段 📖 使用說明 Checklist 在部署當天使用,逐項確認並記錄時間 此 Checklist 同時作為部署紀錄保存,不可事後補填 💡 範例 10.1 部署 Checklist(已執行) 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☑ 10/13 15:00 黃資訊 部署前 PostgreSQL Full Backup ☑ 10/15 21:30 趙資料 部署前 Email 通知全公司維護 ☑ 10/15 18:00 PM 部署中 DB Migration (3 scripts) ☑ 10/15 22:05 趙資料 部署中 K8s Deployment 更新 ☑ 10/15 22:15 周維運 部署後 Smoke Test (5/5 Pass) ☑ 10/15 22:30 林品質 部署後 監控 15 分鐘無告警 ☑ 10/15 22:45 周維運 部署後 通知服務恢復 ☑ 10/15 22:50 PM 📌 範本使用注意事項 ...

May 18, 2026 · 6 min · 1274 words · Eric Cheng

TDD(Test-Driven Development)測試驅動開發教學手冊

TDD(Test-Driven Development)測試驅動開發使用教學手冊 📚 目錄 一、前言 1.1 教學目的 1.2 適用對象 1.3 預期學習成果 1.4 教學手冊架構說明 二、TDD 概念與原則 2.1 什麼是 TDD(Test-Driven Development) 2.2 TDD 的核心循環:Red → Green → Refactor 2.3 TDD 與傳統開發流程的差異 2.4 為什麼使用 TDD:好處與挑戰 2.5 單元測試 vs. 集成測試 vs. 系統測試 三、TDD 實踐步驟 3.1 Step 1:撰寫失敗的測試(Red) 3.2 Step 2:撰寫最簡單的實作通過測試(Green) 3.3 Step 3:重構程式碼(Refactor) 3.4 Step 4:重複循環與迭代開發 3.5 驗收標準(Definition of Done)與測試覆蓋率要求 四、TDD 開發環境與工具 4.1 測試框架介紹 4.2 IDE 與工具設定 4.3 持續整合(CI)與自動化測試 4.4 測試覆蓋率工具 4.5 測試資料與 Mock 工具 ...

November 7, 2025 · 48 min · 10109 words · Eric Cheng

TDD(Test-Driven Development)測試驅動開發教學手冊

TDD(Test-Driven Development)測試驅動開發使用教學手冊 📚 目錄 一、前言 1.1 教學目的 1.2 適用對象 1.3 預期學習成果 1.4 教學手冊架構說明 二、TDD 概念與原則 2.1 什麼是 TDD(Test-Driven Development) 2.2 TDD 的核心循環:Red → Green → Refactor 2.3 TDD 與傳統開發流程的差異 2.4 為什麼使用 TDD:好處與挑戰 2.5 單元測試 vs. 集成測試 vs. 系統測試 三、TDD 實踐步驟 3.1 Step 1:撰寫失敗的測試(Red) 3.2 Step 2:撰寫最簡單的實作通過測試(Green) 3.3 Step 3:重構程式碼(Refactor) 3.4 Step 4:重複循環與迭代開發 3.5 驗收標準(Definition of Done)與測試覆蓋率要求 四、TDD 開發環境與工具 4.1 測試框架介紹 4.2 IDE 與工具設定 4.3 持續整合(CI)與自動化測試 4.4 測試覆蓋率工具 4.5 測試資料與 Mock 工具 ...

November 7, 2025 · 58 min · 12199 words · Eric Cheng