[DevOps自動化-9] 建立專案的守護神

降低Code Reviewer的負擔,讓專案在審核之前,能依照定義的步驟進行編譯、測試、掃描等功能,並且設立分支合併的規則,守護程式碼品質。

前言

上篇文章描述了整合VSTS版控和Jenkins擔任發布工作。但假如產品沒有受到適當的保護,自動化流程就只是讓管理人員輕鬆而已,卻無法讓開發人員從無限迴圈的踩Bug、壓資料、挖坑、掉坑的泥沼中翻身出來。大部分團隊相信都有自己的一套程式碼品質控管流程,但真正能做到卻沒多少,因為Code Reviewer人員的負擔相當承重而且無趣,做到後來,睜一隻眼閉一隻眼還算是有毅力的,剩下的大部分都變成閉著眼睛在審核,讓審核流程變成一種浪費人力卻沒任何意義的形式。

所以本篇要分享的便是如何降低Code Reviewer的負擔,讓它們只需專注在檢查程式碼可讀性以及程式碼架構是否符合規範即可,剩下的工作能交給系統自動執行的就毫不留情的交接給系統吧。

 

建立第一個Build

VSTS的Build其實是一個廣泛的說法,我一開始誤會它的意思,以為是我們在Visual Studio裡面的那個編譯(Build)功能。但這個Build可以自由設定多個步驟,當然也包含編譯專案,不過除此之外還可以設定測試、程式碼掃描、喚醒Jenkins專案等五花八門的功能。

那麼話不多說,就直接來建立第一個Build,登入VSTS,選擇專案後會看到以下畫面,選擇Build功能,點選New,如下圖所示。

進入到選擇template的畫面,請選擇Visual Studio,並按下Next。

接下來設定原始碼的檔案來源,先選擇專案是放在哪個平台,下面的例子是VSTS,再來選擇儲存庫名稱,然後選擇預設分支,剩下的用預設值即可。

由於剛剛已經選擇了Visual Studio的template,所以預設就已經幫忙建好了五個步驟,直接按下Save,輸入Build名稱,按下OK即可。

建立完成後就可以在介面上看到已經建立好的Build。

實際來Run一個,看看是否有成功,請直接點選Queue new build,如下圖所示。


順利的話,專案便會按照我們剛剛指定的步驟,依序執行,而每個步驟所產生的Log也可直接點選該步驟查閱,下圖是查看Test步驟的範例,可以看到紅框處,測試結果是有Pass的。

 

建立分支的Policy

Build建立之後,不去執行,那就像是訂了法律,沒人遵守一樣,都是沒有用的。所以,這個階段的設定就是要為分支的合併訂立遊戲規則,尤其時走Git Flow的團隊,最基本的develop、master這種會發布到站點上的重要分支都要受到良好的保護,可不能讓別人隨便就合併進來。

設定Policy,請先點選Code,然後選Branches,點選...,最後選擇Branch policies,如下圖所示。

設定Automatically build pull requests,勾選1號球處的確認框,接著選擇Build規則是剛剛建立的DemoCIBuild,最後是3號球的位置,勾選當Build失敗時,禁止此分支合併回develop,只要自動測試的測試覆蓋率愈完整,搭配這個policy的設定,就能在一定程度上保護著develop分支內程式碼的品質。

在下方還有更嚴謹的管理方式,如要求必須要繫節Work Item,VSTS本身有提供Work協作的功能,裡面可以設定Task,將程式碼綁定Task,可以讓每段被修改的程式碼可以知道是為了那項需求而做變更,同時更能讓專案管理搭配驗收測試案例明確定義出何謂"完成",這是一個非常重要的專案進度指標。

剩下的設定,如至少需要幾名Code reviewer同意,或者是一定要通過哪個Code reviewer同意才能完成合併,就端看各團隊的需求再做設定即可。

 

build的步驟與Jenkins偕同執行

剛剛展示的所有動作都可直接由VSTS執行,但那畢竟是因為VSTS已有對應的Plugin,假設有某些需求服務雲端的VSTS無法叫用得到,就必須交由地端的Jenkins來負責。而兩個不同的平台如果想要互相合作,最重要的起手式當然是要讓VSTS先認識Jenkins,以前平台串接是很複雜的工作,但現在透過Plugin的方式,一切都變得相當容易。

以下總共兩個步驟就可完成VSTS與Jenkins協作

  • VSTS設定Jenkins終端點
  • VSTS新增Build steps

 

VSTS設定Jenkins終端點

一樣,在VSTS的專案頁面,點選右上角齒輪。

接著按照下圖的步驟,點選Service並新增Jenkins的服務端點。

Connection Name是自訂名稱,可任意命名,Server URL是登入到Jenkins頁面的URL位址,Username和Passowrd是登入的帳密,都完成之後可以點選"Verity connection"會出現綠色勾勾,然後按OK存檔。

完成的畫面如下所示。

 

VSTS新增Build steps

再來就可以在VSTS的Build steps裡添加與Jenkins偕同的步驟。

添加完畢,就來設定一下Jenkins Queue Job,Jenkins service endpoint直接選取剛剛建立的Jenkins endpoint,Job name是Jenkins裡建立的專案名稱(下面講到Jenkins畫面會說明),4號球處的確認方塊則是是否要等待Jenkins回報結果才繼續往下執行,建議是要勾選,否則不知道Jenkins是否成功失敗,之後按下Save存檔。

上圖3號球所填入的名稱是下圖紅框處的名稱,必須完全對應。

 

額外補充

Jenkins回呼VSTS時,VSTS會檢查Jenkins的URL位置,如果兩者不一致,VSTS會直接當作Build失敗,因為有人會忘記修改Jenkins的URL,預設是localhost。相關資訊可參考下圖。

 

擁有自己的Agent比較酷

VSTS預設有提供一組Hosted Agent,所以可以直接使用VSTS的Build功能。但問題也是多多。

首先是,免費版本每個月只有提供240分鐘的額度,這對稍微大一點點的專案,如果要搞真的持續整合,這分鐘數是遠遠不夠的。

再來,雲端Agent有一個致命的缺點,就是它初始化實在太久了,而且未來假如有使用到額外的Plugin,因為微軟都是重新初始化一個Agent給你,所以這些Plugin都要再次重複下載,大幅增加Build的時間。

最後就是,雲端Agent主機性能似乎普普,綜合以上所述,雲端的Hosted Agent真的只能玩玩而已,難登大雅之堂。

好在,微軟也有提供讓我們把Agent建在自己家的服務,Agent愈多,VSTS在執行Build的時候就不太需要排隊,但當然啦,一台是免費的,可如需安裝更多的Agent則是要開始收取費用,費用計算請參考這裡。至於要裝Agent好在也不是太難,大概下列幾個步驟。

  1. 下載Agent
  2. 建立Agent
  3. 設定Agent並啟動

下載Agent

登入VSTS,點選右上角齒輪,點選Agent queues,可以看到Download agent的按鈕,直接點擊下去。

建立Agent

選擇Windows版本,並且點選下載會得到一個壓縮檔,微軟有提供相關語法,直接在PowerShell執行便可順利建立Agent。

mkdir agent ; cd agent

Add-Type -AssemblyName System.IO.Compression.FileSystem ; [System.IO.Compression.ZipFile]::ExtractToDirectory("$HOME\Downloads\vsts-agent-win7-x64-2.108.0.zip", "$PWD")

設定Agent並啟動

設定的方式很簡單,直接在PowerShell執行config.cmd。

 .\config.cmd

執行此後,會出現一連串的提示問題,造著微軟的提示填寫內容即可,共六個步驟,可直接參考下圖。

填寫Personal access token的方式,點選右上角帳號,在Security區塊可以看到Personal access tokens ,點選新增出現下圖畫面,填寫名稱,授權的範圍請點選Agent Pools就好。

以上設定完成之後,建立新的Build時就可以選擇自己的Agent。自己家的Agent還是比較實用,因為有很多功能直接用內網就可以使用,而且主機性能比較佳的話,也會比雲端的Hosted Agent跑得要快很多。

自建的Agent的主機無須特別開啟任何Port給VSTS呼叫,只要確認Agent自己可以連到VSTS即可。

 

小結

到這裡為止,我們已經完成了基本的Build定義,以及設定了分支的Policy,最後也分享了如何建立自己的Agent來執行Build服務。這些動作都完成後,我們的程式碼在合併之前,前提就是要通過編譯檢查、並且通過測試,才能將程式碼合併到測試環境的分支內。

當我們連測試環境都用很神聖的心態對待它,並且保護它,那正式環境出錯的可能性就會大幅地降低。接下來要分享的是導入程式碼掃描,讓整個資訊團隊就像是有一個私人家教一樣,會指正出團隊一些比較不好的程式寫法,以及潛在的技術債,並藉由趨勢分析了解產品的健康狀態是愈來愈健康還是坑愈來愈大.....