Alan Tsai 的學習筆記


學而不思則罔,思而不學則殆,不思不學則“網貸” 記錄軟體開發的點點滴滴 著重於微軟技術、網頁開發、DevOps、C#, Asp .net Mvc、Azure、AI、Chatbot、Docker、Data Science

[05][讓團隊彼此知道程式碼走向]如何强制走Pull Request?以及設定符合規則才能合並分支

[05][讓團隊彼此知道程式碼走向]如何强制走Pull Request以及設定符合規則才能合並分支.jpg
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/、https://www.freepik.com/free-photo/magnifying-glass-stock-market-graph-paper_3095564.htm

在上一篇([04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程)介紹完了整個Code Review的過程,從最一開始的需求,到修改好之後,透過Pull Request做Code Review然後把修改合並回主線。

基本上所有的功能基本都會使用了,但是還有一個很大的問題:如果開發者不走Pull Request的話一切不都完了?

這一篇將來看一下,如何强制要求一定要走Pull Request,並且一些設定讓Pull Request一定要有符合某些條件才可以結束。

爲什麽想要强制走Pull Request?

相信看到這篇這個問題應該很好回答了,假設希望程式碼回去之前都有人一定要review過,那麽强制走Pull Request就很重要。

强制走Pull Request換句話説,就是不允許直接把local修改直接push上去,而一定要透過開分支,然後走pull request流程。

由於這個鎖是針對特定的分支(鎖住不允許直接push),因此在Azure DevOps這個設定叫做:Branch Policy。針對某一個分支所設定的policy。

Branch Policy 怎麽設定?

既然這個叫做Branch Policy,那麽從Branch功能進去是最直覺的方式。

假設今天想要設定master這個branch不允許直接push,而是要過pull request,那麽:

  1. 先在 Repos -> Branches列出所有的分支
  2. 找到要設定的分支,例如master,點選旁邊的3個點
  3. 點選Branch Policies進入設定
chrome_2019-06-11_21-14-41.png
對master設定branch policy

接下來就會看到設定的畫面:

chrome_2019-06-11_21-18-20.png
誰當Branch Policy的畫面

接下來對於幾個設定將做出介紹。

Require a minimum number of reviewers

這個設定將決定:總共有幾個Reviewer要投Approve才能夠過Pull Request

透過這個設定,能夠規定幾個人看過才算過。

這個設定還有幾個細節:

  1. 這個數字設定,最少有幾個Reviewer看過才夠
  2. 是否允許建立Pull Request的人算一個Reviwer - 有時候假設規定一定要有1個Reviewer看過,但是剛好大家都忙,那麽有勾選這個讓自己可以approve過然後complete就變得很重要
  3. 如果Reviewer的決定是Waiting For或者Reject,是否還是可以過
  4. 如果有Reviewer已經投狀態了,但是有新的update,是否要把他們的狀態reset
chrome_2019-06-11_21-21-34.png
設定幾個reviewer

Check for linked work items

這個設定將決定:Pull Request是否一定要綁定work items

很多時候某個修改不知道爲了什麽而改,如果每一個修改一定會對應到一個issue,那麽這個設定就變得很重要,因爲可以規定是不是一定要綁work item。

這個設定還有子項,可以覺得是硬性規定還是可選規定


設定一定要綁定work item

Check for comment resolution

這個設定將決定:是否所有的Comment都要Resolve

不管是針對某一個程式碼下comment還是針對overview裡面寫comment,每一個comment預設狀態都是un resolve。

這個設定就可以決定,是不是都一定要resolve才能夠complete。

和上一個一樣,能夠決定是不是硬性規定還是可選規定


設定一定要處理所有的comment

Limit merge types

當complete要merge回去的時候,可以選擇要用什麽方式merge回去

這個設定就是:鎖定可以選擇哪幾種merge方式

預設開啓4種方式:

  1. Basic Merge - 這個就是一般的git merge --no-ff
  2. Squash Merge - 把所有的commit壓縮成爲1個commit然後merge
  3. Rebase and Fast Forward - 透過rebase然後一般的merge - 最後結果是commit tree永遠是一條線 - 個人不推薦
  4. Rebase with Merge - 透過rebase,然後做一個--no-ff的gommit

這個就看團隊的git分支的策略來選擇就好。


Limit Merge Type設定截圖

Build Validation

一般來説,要merge回去之前一定會想要知道,這個branch是否build會成功。如果build成功,其實連看都不需要看了。

這個要搭配Azure Pipeline,如果Azure Pipeline有設定Build Definition,這邊就可以選擇要用那個Build Definition。

chrome_2019-06-11_22-19-00.png
設定Build Validation

Require approval from additional services

這個服務沒有使用過,不過看起來可以透過打一些狀態到Azure DevOps來,然後在依照這個狀態決定是否能夠過。

應該可以用這個搭配其他服務,然後透過打狀態的方式整合別的服務來決定是否透過pull request。

chrome_2019-06-11_22-26-26.png
設定其他服務的狀態

Automatically include code reviewers

在公司内部可能有些人是特別負責審核某些程式碼,這個時候可以透過設定,只要有建立Pull Request他會自動被設定為Reviewer。

這個設定就在設誰要變成自動加入的Reviewer。

chrome_2019-06-11_22-28-40.png
設定誰要自動被加入為Reviewr

結語

建立Pull Request來做Code Review是很好的控制程式碼品質的方式之一。

但是很怕會有人繞過這個機制,而偷偷上程式。

這篇介紹的Branch Policy就是爲了避免這個問題。

這個系列到這邊應該就暫時到一個段落 - 希望透過這個系列讓大家會想要做Code review,然後瞭解如何透過Azure DevOps讓做這一件事情變得簡單。

參考資料

Improve code quality with branch policies
官方介紹這個功能: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops

如果文章對您有幫助,就請我喝杯飲料吧
街口支付QR Code
街口支付QR Code
台灣 Pay QR Code
台灣 Pay QR Code
Line Pay 一卡通 QR Code
Line Pay 一卡通 QR Code
街口支付QR Code
支付寶QR Code
街口支付QR Code
微信支付QR Code
comments powered by Disqus