前三天我們談到程式碼的管理、審查與測試掃描，以上都有後，再來就是如何部署了

今天我們就來看看團隊在既有的環境下，怎麼讓殘破的環境可以有品質的部署~

Situation

程式部署上線聽起來只是「把程式更新到正式機」，但實際上在整個流程中有很多重要的環節要注意。當時的上線流程有幾個狀況：

• 缺少統一的流程：大多數時間都是由需求人員與開發 IT 在測試環境驗證後就上版到正式環境，正式環境的異動沒有標準的檢查機制。若後異動後造成其他部門非預期錯誤時，受影響單位或管理層難以確定影響範圍和時間。
• 大量手動作業：原本網站程式上線的方式是直接將要修該的檔案從測試機複製到正式機覆蓋。人為操作可能發生的失誤包括相關檔案遺漏或開發中的異動意外被複製到正式環境。
• 資訊不透明：線上程式異動的過程只有經手的 IT 清楚，上線前後也沒有統一的通知，若非主要需求單位，常常需要主動詢問才能知道程式異動狀況。

Task

• 統一開發與上線流程，所有專案流程一致。
• 程式部署自動化，必須要能夠一鍵部署。
• 正式機異動資訊透明，所有人能第一時間掌握現況。

Action

• 規範開發與上線流程。因應 Web App 與 CRM 開發打包規模的不同分爲：
  • Web App：開發環境 > 程式包裝上版號 > 工程內部整合環境 > 跨部門驗收測試環境 > 上線核可 > 正式環境
  • CRM: 開發環境 > 工程內部整合環境 > 程式包裝上版號 > 跨部門驗收測試環境 > 上線核可 > 正式環境
• 所有系統 (Web, App) 皆經由 Azure DevOps release pipeline 串接 git，統一部署至 Azure 或 Dynamics365
• 所有部署流程 (Web, CRM) 皆會在正式環境之前加入主管核可檢查點，主管核可通過後才會部署到正式環境。
• 測試環境驗收並經由核可後程式可直動經由 pipeline 部署到正式環境。CRM 因內部資料處理等排程，統一於 7am 進行部署。
• 重要的系統上線或是異動到較大的服務時，上線時設置 Teams war room，所有參與人員隨時回報現況，例如：CRM 因需多人協作於程式上線後異動正式環境與其他系統串接配置，所以就有設置 war room 掌控情況。
• 重大更新上線前一週及上線完成後發送服務異動通知給相關單位。

Result

• 程式上線有統一的流程和標準，開發、維運以及相關單位對於線上程式異動更容易管理。
• 程式異動有固定時間點，非 IT 等相關單位可根據此可與其之時間安排對應作業。
• release war room 確保所有協作人員都能在第一時間掌握現況，增進效率。
• 上線前通知可提醒非 IT 等相關單位進行對應準備。
• 上線後通知可作為追溯異動的參考。