Azure DevOps in Action - 從需求建立分支的開發流程

前面提過,當我們有一個新的功能(或是bug)需要開發時,可以從tasks上建立branch,這個模式是走feature branch的開發流程[1]。一般來說,我們可以在Azure DevOps的Boards或是Sprints來建立:

其實我自己比較喜歡在Azure DevOps的Sprint畫面中來建立:

原因很簡單,因為開立tasks與branch的這項工作,幾乎都是在Scrum的Planning Meeting Part 2中進行,Planning Meeting Part 2,是團隊在討論某一個backlogs該『如何做?』的會議。這個會議進行時,肯定已經進入迭代(Scrum的迭代稱為Sprints),且已經決定好哪些backlogs要放入此迭代進行開發。所以,上面這個Azure DevOps中Sprints的畫面,團隊討論時一邊開起來看最適合不過了。

至於在哪一個tasks身上開Branch? 完全無所謂。因為最後相關的tasks都應該一併納入。

例如,上圖中,團隊準備開發『計算BMI』這個backlog,在planning meeting時,為該backlog建立了三個tasks,分別是編號942, 944, 945。不管你在哪一個task身上開branch,都會出現底下這樣的畫面:

請在(上圖A)的地方,輸入branch名稱,然後把所有相關聯的tasks都加進來(上圖B),直到三個與此branch都相關tasks都被納入。[2] 完成後,按下『Create Branch』鈕建立即可。

接著系統會自動帶你到底下畫面:

你會發現,該branch已經建立好了(上圖A)。這時候,你可以透過你的開發工具,把程式碼sync/pull到你開發端的電腦上,然後你會發現,在開發端的電腦上,已經可以看到該branch:

你可以透過Visual Studio的branch管理工具(上圖A),點選『管理分支』,然後就可以在出現的遠端分支中,找到剛才建立的分支(上圖B)。開發人員即可切換到此分支,開始撰寫程式碼。

建立PR(Pull request)

一但程式碼撰寫完成,開發人員可以透過同步(sync)的方式,把Committed在開發端的程式碼,同步到伺服器端。

一但程式碼完成同步,你會發現當你開啟Azure DevOps伺服器端的檔案檢視畫面時:

Azure DevOps會提醒你,你剛才更新了程式碼,並建議你開立一個PR單。

你可以點選(上圖A)的按鈕,開立一個PR單,點選後會出現底下畫面:

你會發現在這個畫面中,系統告訴你這張PR單準備要處理從『feature-計算BMI』分支合併到主線(master),你可以輸入一些描述或補充說明(上圖B),然後選擇程式碼code review的reviewer[3]

在(上圖D)的部分會自動帶入先前與此Branch相關聯的work items(還記得嗎?先前我們選了一些tasks),即便你先前漏掉了,在這個步驟依舊可以加添,這些被選定的tasks,在完成code review並merge之後,其狀態都會被自動設定為done。

確認輸入的資料無誤之後,您可以按下『Create』。

進行Code Review與Merge

接著reviewer會收到通知,點選通知後會被帶到PR的reviewer畫面:

Reviewer可以在這個畫面中檢視程式碼差異比較(上圖C),並且撰寫評論(上圖A),你也會看到頁面上有帶出相關聯的工作項(上圖B),在完成code reviewer之後,可以按下(上圖D)的Approve(當然有必要你也可以不approve,改選Reject。

確認無誤後,最後可以按下右上角的『Complete』鈕,它會將這段變更merge回到目標分支。

如此就完成了整個開發流程。

Branch與PR帶來的價值

透過上面這個流程,開發人員能夠更嚴謹的管理程式碼變更,同時團隊所修改的程式碼,會跟需求(或bugs)關聯在一起,讓整體的透明度有很大的提升,我們可以輕鬆地知道,某個需求改動了哪些程式碼? 反過來,我們也可以知道某一行檔案、某一行程式碼之所以變更,是因為哪一個需求。

不僅如此,我們也可以有效的保護master(主線,或其他目標分支)的穩定性與正確性,不會因為開發人員隨意修改主線,導致改壞了原本可以正常執行的系統。

這還只是版控而已,後面我們會從這個基礎點開始,接著加上CI與相關的自動化掃描,以及CD和相關的程式碼檢測。這對於軟體品質的改善將會有顯著的提升。

而PR過程中的code review,也是一個很重要的步驟,由於這個流程會誘導團隊自然而然地進行code review,那怕只是先從合併前的review開始,讓code review的習慣在團隊中慢慢萌芽。久而久之,對於團隊開發品質,與開發人員的功力成長[4],都有很大的幫助。


[1] 再強調一次,走哪一種開發流程,會依照團隊的特性、技能、習慣、甚至喜好而有所不同,並非放諸四海皆準。但要把握的原則是,我們之所以不直接改master主線,是因為要維持一個可以隨時建置佈署的穩定分支。

[2] 其實,如果你有兩個backlogs,底下的tasks也都與此branch有關,你可以把相關的tasks都納入,不一定要by每一個backlog都各自開一個branch。因為branch太多也不見得是好事。不過這部分請依照團隊習慣做選擇。整個團隊必須有一致性。

[3] Reviewer的對象並沒有一定要是團隊中的誰,一般來說,我們可能會選擇自己以外的一兩位資深開發人員、或是團隊中的leader來擔任reviewer。

[4] 學習程式碼最好的方式其實不是看書,是觀摩其他人寫的code。不管其他人寫的code比自己好或比自己糟,都會是一個很有效的學習。

---------------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
本文摘錄自『Azure DevOps敏捷開發與專案管理實戰

留言

這個網誌中的熱門文章

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

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

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

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

專業的價值...