[DevOps自動化-11] Team Foundation Service整合Azure攻略

2016-12-24

517
0
DevOps自動化
2016-12-31

使用Team Foundation Service 的Build功能，搭配Release Management，將軟體部署到Azure 。

前言

最近公司在做APP的開發，希望後台放在Azure平台上，所以就踏上了整合Azure和Team Foundation Service之路。為了讓每步走的踏實，所以邊玩邊做筆記肯定不能少的XD。

小弟在玩整合服務的解決方案時，有個我覺得對個人蠻有幫助的流程，順便分享一下。首先，在開始深入解決方案的技術實作前，先以鳥瞰的視野去思考架構，當架構的藍圖描繪出來，才開始考慮每個整合點需要哪個技術來實現，先試著建立至少一個能滿足主流程的Prototype，有了骨架便能穩定軍心，主流程穩健後，便可以開始添加額外的加值服務。

玩Prototype不用怕失敗，也不用擔心浪費時間，因為，每次的思考都是一個成長的過程。

先暖暖身

大型軟體開發包含下面幾個主要關鍵流程(至少我是這麼認為)，這些都是在不談技術的前提下要實現的藍圖。

開發人員於版控取得新版程式
建立自己的分支
撰寫程式
Pull Request到版控系統
觸發編譯、自動測試、程式碼掃描
核准後合併分支
觸發自動產生Release版本
觸發自動部署到Server上

而關鍵流程會因為公司政策而有不同的實作模式，比如說，部署環境包含哪些，基本至少要有測試+正式環境，分工更細的可能還包含QA環境等等就是一個例子。但都不影響藍圖繪製，有了藍圖之後，再去思考每個流程用那些技術來實作，一切就變得清楚多了。

這次我遇到的需求是要將公司的WebApi部署到Azure上。所以，只有第7項(觸發自動產生Release版本)、第8項(觸發自動部署到Server上)需要調整，而前面的流程與之前文章介紹得差不多。有興趣的人可以參考[DevOps自動化]系列文。接著開始進入正題。

程式碼如何轉變成可用的軟體?

軟體在上線時，我們一定不是直接把程式碼交給客戶，而是要把這些程式碼轉換成對客戶有價值的軟體。

而我們可以透過微軟Team Foundation Service (簡稱TFS)的Release Management (簡稱RM)來達成。但RM並不知道我們要如何產生release版本，所以必須透過建立release definition 來告訴RM。

release definition 小貼士

它包含了所有相關聯的Artifacts (Google翻譯成神器，講白話就是程式碼編譯後的成品) 。
它包含了有建立哪些環境的資訊，如測試、正式環境。
它包含了一些task資訊，例如，將Artifacts 部署到Azure上就是task。

光說不練沒感覺，直接來個簡單的實戰操作，情境是透過TFS，Build程式，封裝成品(Artifact)，最後發布到Azure上。(本演練假設已有Azure環境、TFS帳戶)

登入TFS，先建立一個Build，選擇Visual Studio的樣板，基本步驟會都自動產生。

Repository的來源直接選擇TFS的Team Project專案，選擇指定的Repository (MvcWebSite)，選擇指定的Branch (master)，Agnent預設會是Hosted，建議建一台屬於自己的Agent，第一台免費，後面的才要費用，建立自己的Agent參考此篇，最後按下建立。

接下來可以看到我們的樣板就產生了。樣板提供五個Task，下面簡述各Task的工作。後面會再單獨對每一項作說明。

NuGet restore =>還原Nuget套件，這個應該不用多作解釋。
Build solution => 負責編譯專案。
Test Assembiles =>如果有測試專案的話，它會幫你跑測試。
Publish sybmols path => 上傳包含偵錯和專案狀態資訊的.pdb檔案。
Copy File => 搬移檔案，可以指定來源位置和目的位置。
Publish Artifact =>發布到封裝區，RM會從這裡下載Artifact資源。

大部分Task都有預設值，只要做小幅修改就可以使用，其中Nuget restore、Test Assembiles、Publish symbols path、Publish Artifact這三項Task完全不用任何變動，就能運行。

需要調整設定的有Build Solution、Publish Artifact兩項Task。首先來看Build Solution的設定，先從1號球處選擇.csproj檔案，再來設定Build的參數，/T代表target，代表要封裝成package，/p代表參數，Configuration=release代表要以release的config發布，PackageLocation設定封裝package的zip檔案存放位置。(MsBuild的參數設定可參考這篇)

畫面上有看到$(xxxxxxx)這種代表是變數，變數可以自己定義也可直接使用TFS內建的。內建的變數定義可參考官方文件

最後，設定Copy Files的位置，直接參考下圖。

這裡大家一定會對"來源資料夾"、"發布資料夾"感到困惑。如果有架設自己的Agent的話，我們可以直接連到主機上看資料夾就會理解。下圖是angent的根目錄。

我們只要定義一個Build，就會在agent下面產生一個編號的資料夾，下面例子是"1"，而這個Build產生的檔案都會放在此資料夾中，如需取得此資料夾路徑，可用內建的變數"$(Agent.BuildDirectory)"表示。

點開"1"資料夾可以看到下面有包含a、b、s三個資料夾，接著再觀察Copy Files的設定，配合下圖就能秒懂了。

然後透過Publish Artifacts，把上圖a資料夾的內容Publish。

完成以上步驟後，可以測試一下Build，如果成功的話，代表你已經把程式碼轉換成可用的軟體囉，剩下的步驟就是要把可用的軟體部署到伺服器上。

萬事俱備，只欠發布

只要設定完RM，便可順利發布軟體。請直接參考下圖步驟順序，建立起Release definition。

接下來選擇要繫結的Artifact來源，第一項Build是整合TFS (當然也可以整合Jenkins，下次再作介紹)，再來選擇你的Team Project，選擇我們剛剛建立的Build，最後選擇Agent (跟Build一樣，建議用自己的Agent)，都完成設定後按下Create。

接著設定1號球的AzrueRM的訂閱、2號球要發布的服務名稱，如果在Azure有註冊好Web App服務，這邊直接就選得到，而且也只能用選的，無法直接輸入。

點選Package Folder後面的...可以發現，剛剛設定的Artifact Name，其實就是資料夾名稱。

補充: 假如要新增其他帳號的Azure RM Service，按照下列步驟

打開Power Shell 輸入 Add-AzureRmAccount -SubscriptionId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx(訂閱ID)，接著會彈跳提示視窗輸入該訂閱ID所屬的帳密。
下載微軟提供的SPNCreation.ps1
執行該Script，會要求輸入SubscriptionName 如: Visual Studio Professional ，接著要求輸入Password (任意，等會會用到)
最後會顯示 Subscription Id、Service Principal Id、Service Principal Key、Tenant Id
按照對應填入下圖新增Azure RM Service Endpoint的表格，有問密碼的話，就是輸入剛剛設定的Password