Azure DevOps in Action - 建立你的第一個Build Pipeline

當開始邁向CI(continuous integration),我們第一個要實現的任務是,以雲端(伺服器端)的環境為準,來進行系統的開發、建置、佈署、與測試。

在過去(仿佛是上個世紀以前了),開發人員可能是以某一台個人開發環境的電腦為準,在多人開發協作之後,把程式碼集中在這台電腦上,進行最終的建置與測試。

但當我們導入了版控系統(像是Git)之後,即便多人同時開發、修改、增添新功能,甚至嘗試一些特殊調整。但在伺服器端,應該總是保持著一套最穩定的版本,可能是Master分支、或是Release分支(選擇分支的策略由團隊決定),這是之前我們討論版控時候的最終目標與CI的基礎。

當有了這個基礎之後,我們可以建立一個自動化建置的流程,一般稱之為CI Pipeline。由於使用不同的開發語言(或框架),可能會有著不同的建置流程,因此我們接著會逐步來看,在不同的開發技術下,CI Pepiline的設計方式。

建立 .net framework 專案的Build Pipeline

我們先來看基本的 .net framework專案,如果要練習,你可以建立一個新的Azure DevOps專案,並且在Repos處Clone/Import我們底下這個在GitHub上的程式碼。

https://github.com/isdaviddong/dotNetFxBMISample.git

這是筆者在github上的範例,是一個傳統的 .net framework MVC Web專案(後面我們會在介紹 .net core的做法),功能是實現一個計算BMI的Web應用程式。

你可以使用Azure DevOps Repos起始畫面的import功能,匯入這個GitHub上的Repo:

一陣忙碌:
enter image description here

完成後,你會看到類似底下這樣的程式碼:
enter image description here

有了source code在Repos中,接著,我們就可以來試試看建立Build Pipeline了。

請點選Azure DevOps左方主選單的Pipelines a New Pipeline:
enter image description here

在緊接著出現的畫面中(下圖),選擇最下方的『Classic Editor』。

下圖中上面的幾個選項是透過撰寫YAML Code的方式來設計Pipeline,而我們先選用GUI(Classic Editor):
enter image description here

由於我們的source code已經存放在預設的Azure Repo中(就是你剛才import進來的那份),且位於master主幹上,因此我們直接選擇預設的選項後,點選『continue』即可:
enter image description here

在接下來出現的畫面中,我們選擇 ASP.NET,按下Apply:
enter image description here

按下之後,你會發現系統自動帶出ASP.NET適用的Piepline模板:
enter image description here

上圖左方框起來的是Pipeline中的Tasks(自動化建置步驟),你完全無需修改,直接儲存順便跑一個建置動作(Save & queue)即可:
enter image description here

在出現的畫面上(上圖),按下『Save and run』。系統就開始雲端建置工作了:
enter image description here

上圖A中的Agent job1,就是正在雲端跑的自動化建置工作,你可以點進去,會看到運行的即時狀態:
enter image description here

上圖左方的A,是正在跑的Task,右方B的部分則是運行中的console顯示。如果你依照我們前面的說明一步一步做下來,沒一會兒可能會很訝異的看到底下這個錯誤畫面:

enter image description here

別怕,這是我們刻意的。

請注意,發生錯誤的位置是『Test Assemblies』這個Task,如果你對照前面的Editor畫面,就是底下這顆:
enter image description here

這顆Task是負責運行專案中的Unit Test的,我們曾經說過,近代軟體開發中,很倚賴Unit Test這樣的機制作為程式碼的把關。

Unit Test稱作單元測試,我們可以透過撰寫測試程式碼,以自動化的方式來測試主程式。這帶來了許多好處,可以大幅度的提高程式碼的品質,且減少回歸測試的工作量。

上面的Pipeline就是因為單元測試失敗,導致整個建置動作失敗。我們可以把這個專案透過Visual Studio 2019 Clone下來,並開啟。

然後接著以手動的方式Build整個方案:
enter image description here

你會發現,當你嘗試Build這個方案,他是可以正確地被建置的。

這表示這些專案沒有任何語法上的錯誤。然而,當你執行這個專案的程式時,它運算BMI的結果卻是錯誤的:
enter image description here

BMI是體重除以身高的平方,體重是以公斤為單位,身高是公尺。因此,上述計算正確的結果應該是24.22:

70/(1.7x1.7)=24.22

但我們的程式卻顯示為『70』。

這個錯誤源自於底下這段計算BMI的核心程式碼:

public float Calculate()
{
 float result = 0;
 //發生錯誤的位置
 float height = (int)Height / 100;
 result = Weight / (height * height);
 return result;
}

上面程式碼其中的

float height = (int)Height / 100;

造成了錯誤,(int)這樣的型別轉換導致計算結果不正確,如果你修改成

float height = (float)Height / 100;

則運算就會成功。

然而,這個程式碼邏輯上的錯誤,對於Build來說,卻不會造成任何問題(因為沒有寫錯任何語法),但執行的結果卻是錯的。

重點在於,Pipeline中運作Unit Test的tasks,順利地為我們抓取並攔截下了這個錯誤(雖然Build的時候沒有任何的語法異常),但撰寫了Unit Test的程式,在面對這類邏輯性的錯誤上,將可以為我們的系統帶來更大的保障。一切的前提當然是我們在專案中已經先撰寫好Unit Test的code了,但在這邊我們在這邊先不談Unit Test的撰寫,我們先了解Unit Test可以為我們帶來這些好處(後面會再找時間介紹如何開發)。

而用戶端Visual Studio的Test Explorer工具,可以幫我們手動運行Unit Test(下圖中左上角的Play按鈕):
enter image description here

例如上圖A是手動執行該專案中Unit Test的結果。

一般來說,成熟的專案中可能會有幾十甚至數百個Unit Test,這些為數眾多的Unit Test當不然可能頻繁的在開發端手動逐一執行,而Azure DevOps的自動化建置中的『Test Assemblies』這個Task,會在Pipeline進行Build的過程中,幫我們運行Unit Test,以確保開發品質得以提升。

總的來說,我們可以在程式專案中,撰寫更多的Unit Test,透過這些Unit Test,可以在Pipeline被執行時,自動檢查程式碼的正確性,守護系統的品質。當然,你必須先有Unit Test的觀念,如果你不曾寫過,暫且不用擔心,後面我們會介紹。

但你應當開始發現CI Pipeline的種種好處了…除了自動建置、持續整合(多人開發時),自動建置時帶入Unit Test的執行,也是很重要的…


----------------------------------------------------------

留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...