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

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

前言

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

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

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

 

先暖暖身

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

  1. 開發人員於版控取得新版程式
  2. 建立自己的分支
  3. 撰寫程式
  4. Pull Request到版控系統
  5. 觸發編譯、自動測試、程式碼掃描
  6. 核准後合併分支
  7. 觸發自動產生Release版本
  8. 觸發自動部署到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的工作。後面會再單獨對每一項作說明。

  1. NuGet restore =>還原Nuget套件,這個應該不用多作解釋。
  2. Build solution => 負責編譯專案。
  3. Test Assembiles =>如果有測試專案的話,它會幫你跑測試。
  4. Publish sybmols path => 上傳包含偵錯和專案狀態資訊的.pdb檔案。
  5. Copy File => 搬移檔案,可以指定來源位置和目的位置。
  6. 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,按照下列步驟

  1. 打開Power Shell 輸入 Add-AzureRmAccount  -SubscriptionId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx(訂閱ID),接著會彈跳提示視窗 輸入該訂閱ID所屬的帳密。

  2. 下載微軟提供的SPNCreation.ps1

  3. 執行該Script,會要求輸入SubscriptionName 如: Visual Studio Professional ,接著要求輸入Password (任意,等會會用到)

  4. 最後會顯示 Subscription Id、Service Principal Id、Service Principal Key、Tenant Id

  5. 按照對應填入下圖新增Azure RM Service Endpoint的表格,有問密碼的話,就是輸入剛剛設定的Password

以上都設定完成之後,就可以測試一下觸發我們一開始設定的Build,就會看到一系列動作完成後,會觸發Release。

Release觸發成功,並且如果是綠色,便會按照我們的設定,把程式發布到Azure上。

相關文件參考

 

心得

TFS的整合功能真的非常強大,以往這些東西,如果要自己刻,可能要花上好多時間。

這次在研究TFS整合Azure的過程中,覺得最抽象的就是它資料夾的架構,如果是用微軟的Agent,真的比較難摸得懂,但透過自己架Agent,看資料夾的變化,再參考官方文件,就好理解很多。

另外各服務之間如何串接,也是需要花比較多時間了解觀念,比如PR怎麼觸發Build,Build怎麼觸發Release等等。這部分微軟大都已整合好了,但如果真的有客製需求話,還有大絕招Web Hook可以實作,真是太威了....以上小小心得分享....