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敏捷開發與專案管理實戰』
留言