[转载]為什麼 Release Management (發行管理) 是團隊開發的最後一哩路? 系統維運人員也該關心

转载地址

http://blogs.msdn.com/b/msdntaiwan/archive/2013/12/10/why-release-management.aspx

各位朋友們,

今年 9月 TechDays 大會時，我們也同步進行 Visual Studio 2013 的台灣發表會，發表會中提到了 VS 2013 的一個新功能叫 - Release Management for Visual Studio 2013 (原名為 InRelease)，Release Management 依字面翻譯，是指「發行管理」，是指部署應用程式到多種執行環境的流程，執行環境包括開發、測試、或上線環境等。應用程式發行的過程需與開發團隊、測試/品管、系統維運團隊間溝通協調，「發行管理」的目的就是改善各角色間的溝通，讓軟體能快速、簡單、可靠、重複、並符合稽核的要求順利完成部署。叫「發行管理」聽起來很高深，但事實上每個開發團隊、系統維運團隊常常在進行軟體發佈，只是大家的管理方法不同而已，或甚至不管理，為什麼我叫它是「團隊開發的最後一哩路」呢? 本文打算用一些簡單的故事以及常見的佈署問題，讓第一次接觸到這名詞的朋友們能了解其價值。

一個小故事 - 電子商務網站手動上版的心酸

若是一個非常 mission critical 的系統，例如網路銀行、電子商務、企業關鍵營運系統 (ERP, CRM, MES) 等系統，其改版、上版流程是十分嚴謹的，定會有開發環境、測試環境、Staging 及Production 環境，為什麼呢? 因為一旦上錯版，或是嚴重 Bug，造成的損失是不可言喻的，試想一下若購物車出錯，算錯價格、或是網路銀行無法驗證身份是十分嚴重，因此在每個環境中反覆測試以確保每次改版其功能正確、符合資安要求、效能達到一定的標準、或通過 UAT 等驗證機制。筆者早期是在電子商務網站開發的軟體公司，每次一旦新功能要上線，身為 PM 及 Programmer 總是要戰戰兢兢，首先要確保在內部的測試環境執行無誤，因此要手動複製這次異動的程式檔，再三確定資料庫的table schema也同步更新了，接著 IIS 的設定又得檢查是否一致，再來許多 COM+ 元件得一一手動註冊。好了，光是人工做這些反覆設定、檢查的動作，就足以耗盡開發人員的腦力了，因此通常這類差事會由 PM 來做。再來若是上到 Staging 及 Production 環境，還得與系統維運人員 (System Engineer, or System Admin) 溝通，因為這些環境更不是任何人可以碰的，而且通常為了讓系統人員對於這次改版需異動哪些程式及設定，每次過版需填表單告知哪些系統設定需更新，若是金融單位，每次過版記錄都需留底供稽核，即使是一個簡單的功能換版動作，都得耗上許多溝通成本、時間以及冒上可能出錯的風險。

因此早年只要是進行上版的動作，通常是一整個 Team 都得 stand-by，一旦出問題，馬上得處理。再加上電子商務類的網站改版頻率很高，我只能說，系統上線後才是挑戰的開始。

愈是要重複執行的工作，愈要自動化 (人工容易出錯)

隨著技術的進步，各種自動化測試、佈署、Configration Management 的工具也愈來愈多，但我還是常常聽到一些企業很 mission critical 的系統仍由人工進行過版動作。原因最常聽到是，

1. 不知道有這些自動化工具可以幫忙。這個好解決，通常只要 Demo 一次，就會知道這類工具的價值了。

2. 反正改版頻率不高，過版所花的時間雖然要一天，但還可以忍受。這個可能要等人工過錯版時，知道痛了，才會重視。

3. 佈署是一件與開發 (Dev)、維運團隊 (Ops) 都有關的事，得花不少溝通協調工夫，得過且過。這個一樣要痛過，且上層主管重視，才會重視發行管理。

4. 我們的系統不容許過錯版，因此需要許多人 review 把關。這個也算小問題，發行管理就是可讓你設定發行關卡，確保發行正確性。

希望讀者可以盡早體會到 Release Management 的價值，並盡早規畫你重要系統的 Release Plan。

Release Management 的價值是什麼？為什麼系統維運者也該關心？與 Build 或是 CI (Continuous Integration) 持續整合機制關連是什麼?

以 Team Foundation Server (TFS) 為例，已經有自動化建置 Build ，並存在「組建-部署-測試」流程，可以很快建立 CI 的環境了。CI 可以說是 Release Management 的一環，但 Release Management 它涵蓋了開發 (Dev) & 系統維運 (Ops)，讓整個應用系統發行機制進行更好的管理、自動化、減少人工，因此可以說 CI 是 Release Management 的基礎。而 Release Management for VS 2013 它與 TFS 整合得很好，在TFS 中設定 Build 時，就可設定觸發一個 Release 的流程了，因此當開發團隊每天check-in程式碼，在 CI 環境中進行整合、建置、自動化測試的動作，然後觸發 Release 的流程讓整個發佈流程更自動化及完整，因此我稱 Release Management 是「團隊開發的最後一哩路」，且系統維運人員 (Operations)也應該關心。一個完整的發行管理機制，可以滿足以下的需求並提供價值，

Configuration 設定 - CI 環境可以透過呼叫 Script 或 command 的方式進行系統的 configuration，例如元件註冊、執行批次工作 (例如執行 SQL ETL 工作或排程工作)、建立網站目錄等，但 Release Management 可透過 UI 先設定這類的 configuration，讓 configuration 成為發佈的一個環節。
Release Path 是可變動的 - Release Management 讓你可以自定每個應用程式它的發佈流程，以及不同環境 (Dev, Test, Staging, Production) 都可以有獨立的發佈流程，這在大型的系統發佈是很常見的，像現在很常利用 VM 技術建置開發測試環境，但在上線環境可能還是實體機器，因此不同佈署環境它的發佈流程本來就不同，又像是電子商務網站，一些靜態的頁面其改版所需的嚴謹性不用太高，但關於購物車的程式改版，又需要十分嚴謹，這在 Release Management 是很容易可以實現的。
Dev & Ops 有一致的發行、佈署機制，以利溝通並降低出錯風險： 重複性工作和繁複的步驟，容易發生人為錯誤，一旦出錯往往需要不同團隊成員間的大量協調和溝通，收集錯誤紀錄並研究原因。若部署到正式環境要一次到位，除要有與正式環境一模一樣的測試環境及 Staging 環境外，多次的部署除可驗證上線流程外，也可讓相關人員熟能生巧，並模擬各種發佈狀況，當真正發生問題時才能從容不迫的處理。
符合法規及稽查：在較為嚴謹的產業，例如金融業，會要求部署需被授權、審核與稽查，有制式的流程，不可任意執行。Release Management 可以定義發行的關卡，需哪些 Gate Keeper 的審查才得以放行。

從 TFS 的 Build，進入 Dev -> Test -> Release 不同階段