摘要

在軟體開發專案中，協同合作開發能使專案開發更迅速，但也常常因為某些問題造成專案的開發效率更慢，這些問題會發生在兩個階段，第一階段是系統開發時的程式碼整合問題(Integration Hell)，第二階段則是發生在系統測試時環境部署的問題。有鑑於此，微軟(Microsoft)所開發的Team Foundation Server即是為了解決上述問題的解決方案，他完整的實現了Continuous Integration(持續整合)，讓專案團隊更能夠掌握專案的開發節奏，提早發現系統中的問題並解決，達成「及早發現，及早治療」，加速專案目標的達成。

專案開發所遇到的問題

在系統開發階段時，常常會發生下列的問題，當修正完程式，想要將程式版本Commit到程式版本庫(Version Repository)時，結果發生衝突；或者是當我們Commit程式後，發現之前修改好的某段程式不見了，造成整合測試時發生問題。這些問題造成專案中的開發者需要花大部分的時間在解決程式衝突，而非對專案有貢獻的系統開發，這就是所謂的「Integration Hell」。

當系統開發完成後，需要一套嚴謹的系統上版流程，一般來說都會分成系統整合測試環境(SIT)、使用者驗收測試環境(UAT)、平行測試環境(PT)及正式上線環境(Production)。為什麼要分這麼多套環境呢? 因為一旦上線的版本有漏洞或是過版過到錯誤的版本，這個後果是十分嚴重的，往往要付出的代價都非常高。因此在每個階段的測試進行反覆的驗證，確保系統上所有功能正確、效能可達到一定的水準、符合資訊安全的標準是非常重要的。

當系統準備好要進行到SIT與UAT的測試時，都需要重新佈署環境，包括手動複製有異動的元件、設定檔的設定以及IIS的設定，確保在UAT階段的測試結果與SIT階段的測試結果是一致的。因此每當進行到一個新的階段測試時，都需要反覆的進行上述的每一步動作，光是設定這些環境，就足以耗盡開發人員的腦力了。接著，當要進行到PT環境及Production環境時，還需要與系統維運人員做溝通，因為這些環境通常已經是對外的網段，任何人都不能在這環境上隨意做動作。此外，為了讓系統維運人員了解此次改版需要異動那些元件以及設定，每一次的過版都需要填寫過版清單，告知那些系統設定需要更新。因此，光是一個簡單的功能換版動作，就得消耗許多溝通上的成本、時間，最重要的是，還會增加出錯的風險。

自動建置與自動部署

為了解決上述專案開發時的問題，持續整合(Continuous Integration)概念被提出來，它的核心概念是「Build At Every Change」。持續整合顧名思義就是隨時整合，無時無刻都在進行整合，整合的過程會驗證程式碼的正確性並進行單元測試，測試結果都正常後，再自動部署系統的元件至測試環境中。當程式碼被更新與改變時，立即進行自動化的整合作業，自動化在持續整合中扮演重要的角色。因此持續整合的工具的核心動作有兩項：自動建置及自動佈署。

自動建置可解決「Integration Hell」的問題，每當專案成員簽入程式碼後，持續整合的工具即會立即建置整個專案中的所有程式碼並且回饋報告，若發現建置有問題時，專案成員透過報告即可提早發現錯誤，盡早修正，節省專案成員花費在解決程式碼衝突的時間，讓專案成員能夠花費更多心力在開發系統上。

自動部署可讓佈署新環境的動作能夠更快完成，透過自動化佈署的腳本可讓系統知道如何建置新環境，包括要使用哪種組態、異動那些元件，因此在過版新環境時，也不須人工手動一個一個的拉版，減少人工手動的繁複程序，大大減低出錯的風險，同時也可讓專案成員可將更多心力放在系統的開發以及整合測試上，提升系統的品質。

微軟(Microsoft)所提出的Team Foundation Server包含了從需求分析開始，系統分析、Work item checking、版本庫、程式碼分析、測試、產生分析報表、建置、部署、bug tracking，是一套完整實作持續整合概念的工具。下面將介紹如何使用TFS進行自動建置與自動部署。使用TFS進行自動建置與自動部署時，需有2個前提如下：

‧專案中的程式需撰寫相對應的單元測試，讓TFS可以在自動建置時同時進行單元測試。
‧專案中的每個成員必須對自己所開發的部分負責，養成良好的程式簽入、簽出的習慣，在簽入程式前確認在自己本機可建置成功。

確認專案中的程式碼都確實實行了上述兩個前提後，在使用TFS做自動建置與佈署時才能夠發揮最大的效果。

TFS自動化建置前的準備事項

系統會有一定的編譯順序，我們需要設定一套腳本讓電腦知道如何進行編譯。電腦無法知道系統的程式碼放置位置、編譯的順序以及建置完成的元件應放置何處，所以必須要事先準備好「自動化建置的腳本」讓電腦可以照著我們的腳本來執行，如此一來才能達到自動化的效益。

必備的項目

‧建立版本庫:用來存放專案程式碼，是整個系統開發程式碼的基準。
‧設定專案的編譯順序:程式專案之間的編譯順序，避免專案引用到舊的元件。

版本庫

由於專案中一定會同時有多個專案成員會同時開發專案中不同的子系統，因此須有一個共同存放程式碼的集散地，稱之為「版本庫」，只有在版本庫上的程式碼，才可以拿來討論、比較、說明，不論在開發、測試和部署，都要以版本庫上的為基準。除了版本庫之外，還需要再建立一個專職做建置程式碼以及放置元件的Server，這部分可參考微軟官方網站的安裝 Team Foundation Server指南http://msdn.microsoft.com/zh-tw/library/dd631902(v=vs.110).aspx。確認將Team Foundation Server(TFS)安裝完成並已將專案中的所有程式碼簽入TFS的版本庫後，繼續設定專案編譯步驟的腳本。

專案建置順序

由於系統在建置時會有一定的編譯順序，即底層元件建置完成後，才可繼續建置其他元件，避免專案引用到較舊的元件。但由於電腦並不會知道元件之間的編譯順序，因此我們必須事先定義。這個部分可透過TFS所提供的專案相依性來定義（如下圖所示）



自動化建置設定

主要是定義組建定義，讓TFS知道建置的程式碼來源為何、專案建置的週期以及建置元件的放置目錄。

設定組建定義

操作方式如下：開啟TFS的Team Explorer-> 組建 -> 新增組建定義



設定組建名稱



選擇使用連續整合，確保每次建置後，若有錯誤，可以盡早發現。



設定程式碼來源要下載的版本庫。



設定自動建置好的元件要放置的目錄。



設定流程使用預設值即可，並儲存組建定義，



透過上述設定步驟，即可完成自動建置。現在每當簽入程式碼後，TFS即會自動啟動一個新的建置，並列出建置的log以及Report。如下圖所示：



自動化佈署前的準備事項

不同的測試環境，其環境設定也不同，因此我們必須事先準備好各環境的組態設定。同時，我們也需要定義佈署流程的腳本，讓TFS知道佈署環境的步驟。

必備的項目

‧環境設定(組態設定):自動化佈署必須要針對 SIT、UAT 或是 Production 不同的環境來套用不同的環境設定。 (舉例來說：測試環境和正式環境的 資料庫帳號密碼驗證或是加密問題都需要納入管理 )

‧安裝Web Deploy Tool: Web Deploy 工具是一個可以讓TFS直接在 IIS 7.0 中進行應用程式部署的工具集，快速在測試環境中建立Web應用程式。可參考下列網址安裝此工具。http://www.iis.net/downloads/microsoft/web-deploy

‧佈署流程的腳本:編譯完成的項目和元件後，搬到Server 指定的目錄中並且檢查 Server 相關的設定(若是IIS 上沒有該站台，腳本就會自動建立)。

‧組建定義參數設定:定義建置後，要用什麼方式佈署元件。

環境設定（組態設定）

對於每個環境都需要設定不同的組態，需自行在建置 -> 組態管理員下新增相對應的組態，如下圖所示：



點選新增後，就可以指定要從那一個組態複製( 比如新增的 SIT環境可以從Dev設定檔複製 )：



接著可讓系統自行產生相對應的Web.config，若是沒有修改過組態的話，這裡是無法點選的。



產生相對應的Web.Config後，必須再下載XDT Transformation Tool以利建置時可做到組態轉換。



佈署流程的腳本

由於系統佈署時需定義佈署網站的位置以及IIS網站建立的目錄，因此必須定義出一套佈署流程的腳本 -> 定義發行設定檔。

第一步是定義發行設定檔的名稱



由於網站佈署機制就是直接用 IIS Web Deploy Tool 3.5 的版本，所以佈署的方式請用 Web Deploy ，接著定義準備發行的Sever以及網站名稱。



定義發行的環境，目前是設定使用AutoDeploy環境。另外，由於Web.Config也需隨著環境的不同而改變，因此這裡指定的 Connection String 必須也要同步更新 Web.Config ，這樣子程式才能正確地指定資料庫。



定義完成後，點選發行測試是否能夠發行成功。




組建定義參數設定

設定MSBuild引數如下，以下說明參數的意義為何:

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=
True /p:MSDeployPublishMethod=InProc /p:MSDeployServiceUrl=localhost /
p:DeployIisAppPath="Default Web Site/MvcWebDev" /p:UserName=domain/user /
p:Password=password /p:Configuration=AutoDeploy



/p:DeployOnBuild=True – 定義TFS建置時，同時佈署元件至測試環境中。

/p:DeployTarget=MsDeployPublish – 讓Team Build知道要使用Publish的Web Deploy Tool 機制，而不是用原本MSBuild的項目。
/p:CreatePackageOnPublish=True – 定義是否再佈署網站時同時產生Web封裝包。

/p:MSDeployPublishMethod=InProc – 定義佈署的方法，由於此範例是將網站佈署到本機，因此設定InProc。(註：若是要將網站佈署到其他Server上，則必須修改為WMSVC，因此會變成/p:MSDeployPublishMethod=WMSVC)

/p:MSDeployServiceUrl=localhost – 定義佈署的Server位址。

/p:DeployIisAppPath="Default Web Site/MvcWebDev" – 讓Web Deploy知道如何建立IIS。

/p:Configuration=AutoDeploy – 定義發行時使用的組態為何，若要佈署至其他測試環境，則將此參數值修改為那個測試環境相對應的組態名稱。
透過上述設定步驟，即可完成自動部署。現在每當簽入程式碼後，TFS即會自動啟動一個新的建置並佈署，佈署後的網站如下圖所示：



原本TFS上的Web.Config連線字串如下：



自動部署後的網站，其Web.Config中的ConnectionString也轉換為AutoDeploy組態裡定義的



結論

系統品質對於專案是最重要的，因此如何讓專案成員有更多的時間花費在測試系統的所有面向，並妥善管理系統中的程式碼是很重要的課題，微軟所提出的TFS即是為了此問題所提出的解決方案，他完整的實作了持續整合，節省了專案成員花費在處理程式碼衝突、佈署環境的時間，可提早找到危害專案的程式漏洞，讓專案成員可以有更多的時間在修正與開發系統上，藉此來增進系統品質。

參考資料

1.自動化建置教學
http://vishaljoshi.blogspot.co.uk/2010/11/team-build-web-deployment-web-deploy-vs.html
http://www.chrissurfleet.co.uk/post/2011/07/21/Setting-Up-Continuous-Deployment-In-TFS.aspx

2.持續整合概念
http://en.wikipedia.org/wiki/Continuous_integration


(本文轉載自RUN!PC網站8/7發表文章)