使用 Release Management 設定 ASP.NET Web Application 進行自動化佈署 Continuous Deliver
Release Management 自動化佈署解決方案
2012 年末的時候我們提到持續建置 Continuous Integration 和 持續交付 Continuous Deliver 可以運用 Team Build 來達到自動化的目的
我們公司的上版稽核就靠 Team Build 了！ 自動化建置、過版Log 歷程、報表 通通搞定！
這個方式主要還是從 AP Team 的角度出發，對於小型團隊或是上線的流程由 AP Team 完全掌控比較適合的方式。但對於大型企業需要的「內外稽」、「過版的簽核流程」、「上版的生產履歷」比較沒有完整符合需求。或是 Ops Team 完全主導 Production 環境 AP Team 沒有任何的權限可以進來，只能透過 RDP 的方式進行人工上版。這也是大部分的團隊常用的方式
Ops Team 有時候會因為資安的考量連網路都是隔離的作業，而且通常表面上講有過版人員，但也都是 AP Team 的人自已上陣。
那我們如何達到老闆的需求？又可以自動化？又可以簽核？那麼 Release Management 絕對是一個很棒的解決方案。
上次 PO 了 Release Management 2013 一步到位！圖形化 安裝手冊！
這次我們要介紹如何針對 ASP.NET Web Application 用 Release Managmenet 很簡單設定一下就好
文章中的環境
- ASP.NET 4.5 的 Web Application 專案
- IIS 7.5
- TFS 2013 和 Release Management 2013
- Visual Studio 2013 Ultimate
One Click 就可以過版
系統上版簡單與否完全取決於系統客製化的複雜度為主，尤其是 Server 並不是將 檔案 copy 過去就可以用。還要依不同的環境有不同的 Configuration 變數，或是有元件要放在特定的位置讓專案引用。佈署上去後還要確認 UI 系統內的資料初始化等等一些鎖碎的工作。所以專職的過版人員或是老闆都會想是不是能將過版的項目全程自動化，而且只要 One Click 就可以過版過去。
Release Management 有完整提供Web 的形式讓過版人員使用，並了解目前過版的 Status。平常過版的畫面都是用瀏覽器的方式來進行
後台管理平台可以看到目前的進度、過版的數量、目前上版的版本並對應到 Source Code 的建置版本
當然也有這一次的過版歷程的詳細記錄和目前流程進度，這個簽核記錄就可以符合 ISO 或是 內外稽的 Review
佈署前的準備 Configuration
佈署項目中其中有一個非常關鍵的項目除了 AP , DB 外就是 Configuration 設定，而且也必須要將 Configuration 納入到版本管控之中，沒有納入的話對於團隊來講有非常大的風險。另外，我們在稽核上也會被要求必須要確認上線的版本和版控中的版本必須是同一份，因此在 configuration 就必須要有機制可以替換，而不是用人工的方式修改。
這次我們用的方式也是一樣的使用 Web Deploy Tool 的方式進行系統的封裝，而所有要變更的參數都統一在 Parameters.xml 中。可以看到變數設定中有跨檔案的機制，這樣子對於非 web.config 也可以控制。
<?xml version="1.0" encoding="utf-8" ?>
<parameters >
<parameter name="Environment" description="請輸入環境和版號" defaultValue="__Environment__" tags="">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/appSettings/add[@key='Environment']/@value" />
</parameter>
</parameters>
封裝檔的部分設定
建立一個新的 Release 用的封裝設定
隨意取一個適合的名字
格式一定要在前後加上 __ 格式樣式：「__TailspinConnectionString__」
若是站台名稱永遠是固定的話，基本上是可以不用參數化的。
當然連線字串肯定要參數化，不然應該是有鬼的。基本上這個設定是 Package 幫你自動更換 web.config 中的設定，若是您的連線字串是特化過放在別的地方的話就必須要額外設定。請參考 Parameter.xml 的做法，但基本上不建議您這樣子做，因為 web.config 若是有人為介入修改的話，asp.net 會自動幫您重新載入，但自已寫的 xml 則不會套用最新設定。
按下發行後就會幫你包裝成 package 了。
可以看到封裝的結果，並且會將剛剛參數化的項目統一放在 SetParameters.xml 之中
可以看到剛剛在 Parameters.xml 設定的 Enviroment 也出現在這裡就對了，統一在一個檔案的好處是只要改一個檔案就好，不用再去記一堆有的沒的。
自動化建置
由於稽核要我們證明 Production 上的版本是從 TFS 版本管控中來的，所以我們必須在 Team Build 中設定觸發機制，讓系統自已可以對應。另外我們希望 Team Build 可以自動化產生 Package ，所以 MSBuild 的引數要加上我們剛剛設定好的 Package 即可。剛剛在上面設定的 Package 名稱是 TailspinToysRelease 如此一來才會用我們剛剛設定的 Parameters 的設定。
「/p:VisualStudioVersion=12.0 /p:DeployOnBuild=True /p:Configuration=Release /p:PublishProfile=TailspinToysRelease」
由於我這裡的開發工具是 Visual Studio 2013 ，避免系統誤用舊的版本所以額外指定了 /p:VisualStudioVersion=12.0
Team Build 建置完成後就可以看到 Package 和 Parameters 都有了 ，這樣子就代表要過版的東西都完成。
Release Management 過版設定
前置作業請務必照著 Release Management 2013 一步到位！圖形化 安裝手冊！ 安裝並全部設定完成
首先為了讓 Release Management 認得 Web Deploy Package ，請先下載這個套件並安裝在 Deploy Agent / Release Management Client 的機器上
http://support.inreleasesoftware.com/attachments/token/kfvabql0jv4omje/?name=irmsdeploy.exe
開啟 Release Management Client 工具，「詳細目錄」—>「工具」 然後建立 MSDeploy 的工具套件
「__WebAppName__.deploy.cmd /Y」
如此一來 MSDeploy 元件就可以被認得到，有了它就可以節省很多寫腳本的時間
設定應用程式
首先要先建立「元件」以便我們取得建置相關的檔案
「_PublishedWebSites\TailspinToysPackage_Package」
這個路徑是我們上面 Team Build 的結果中可以查得到的路徑，直接 copy 過來即可
接著在部署工具中選擇我們剛剛建立的 WebDeploy ，就會自動帶出來下面的引數設定。
組態變數則是佈署系統前要更換變數，請記得一定要選「安裝前」然後再把 Parameter 的變數加入到下面的清單中。
由於我已經將變數統一放在 Parameters.xml 並由 Team Build 自動轉換成 SetParamenters.xml ，所以我們只要針對這個檔案更換變數就行了。
設定發行流程
元件建立好後，我們就可以回到發行範本中將要部署的伺服器拖拉至部署序列中，再將剛剛建立好的元件也拖過去即可。
針對每一台伺服器的腳本中設定組態變數
WebAppName 則是 TeamBuild 所產生的 Package Zip 檔案名稱
ConnectionString 就不用多說了，連到 DB 的連線字串。在這裡的好處就是只有特定的人才能輸入
SiteName 請不要忘記 Default Web Site
Enviroment 是自已系統中的變數
把 DEV , UAT , Production 三個環境都如法泡製後就大功告成了
佈署
我們馬上來看一下成果吧！
首先先從 AP Team 程式開發完成後，決定從分支中要交付新的版本而觸發的 Team Build 機制
YES ！建置的報告全部都通過了
接著請過版的人員用 瀏覽器連到 http://tfs2013:1000/releasemanagement 的地方
可以看到剛剛建置好的項目，被知道有一個新的過版需求，當然這時候只要按下核准系統就會開始 Dev 的佈署。
系統會有一個通知說明建置完成
立馬來看一下系統是否已經建立
YES！系統可以正常執行，並且在 Enviroment 上也有出現剛剛在 Release Management 上的變數
當然我們馬上再往下佈署走到 UAT
定時發佈系統
佈署顯示目前的階段為何，確定完沒有問題我們再按下核准
確認我們要佈署的項目和時間
下午 3 點時間一到 Release Management 就會開始作業
太棒了，Release Management 正確地將 UAT 的環境設定檔替換掉，並顯示 UAT 的項目
從這裡可以看到我們在系統佈署上不需要再用人工的方式一個一個檔案佈版，也不需要跟過版人員說明這次要更改那些項目。更不需要再寫過版異動清單了，連同過版的簽核記錄和項目統統都有 Record 。最棒的是佈署時間很短又是自動，完全不用擔心人員上版時會不小心漏檔案或是少做其中某個步驟。
另外，善用 Web Deploy Package 機制 可以大幅減化佈署腳本的步驟 和 Release Management 的參數的設定讓我們可以用同一個 package 可以隨時替換成不同環境的項目
當然對於不能包 package 的專案也可以用 Command Line 或是 Power Shell 的方式執行，比如 SharePoint 我們已經有和 K 驗證過將 SharePoint 所有要過版的項目 (Design Page , Web Part , List ) 全部用 Release Management 進行自動化的系統過版。
若是您們的系統過版超過 5 分鐘以上，步驟超過 3 個步驟。那麼我非常非常建議團隊一定要好好思考一下 Release Management 的自動化過版。畢竟希望各位不要再遇到跟我一樣的問題，浪費很多時間在不美好的事情上。團隊有在導 Scrum / Agile 的話就更應該要導入自動化佈署，因為每兩週就要交付一個版本這個次數對於人力有限的團隊來講還要額外的功夫去佈署也是相當麻煩的。回想起2003年導入 XP 並要定期交付時第一個我改善的就是將系統佈署給予自動化，真的省下我超多的時間，後來帶新人時也非常好上手不容易出錯。
當然若是您們的團隊有外稽的話就更應該要導入，光是有簽核流程可以自訂和記錄就非常非常地方便，隨時都可以拿出報告出來跟稽核的人說我們現在上版的版本是對應到 版本管控中的那一個 ChangeSet 。
( 註記：以前在 VB6 時都沒有這些工具，全部都要人工的方式自已刻腳本和處理自動化更版的機制 )
參考資料
http://support.inreleasesoftware.com/entries/21487316
http://www.colinsalmcorner.com/2013/11/webdeploy-and-release-management.html
http://vishaljoshi.blogspot.tw/2010/11/team-build-web-deployment-web-deploy-vs.html
http://www.dotblogs.com.tw/franma/archive/2013/05/08/103206.aspx
http://vishaljoshi.blogspot.tw/2010/07/web-deploy-parameterization-in-action.html
