在上一篇([03]Azure DevOps的Pull Request提供了什麽功能？)瞭解了整個Azure DevOps的Pull Request功能之後，接下來就是看看在實際上如果整個串起來是什麽感覺。

這篇將從做一開始的需求，到最後整個功能確認修改好並且合併回主要分支。

這一篇也希望可以看到Azure DevOps這種一整套整合好的工具的好處。

整個Code Review的流程

在開始之前，先來看一下整個Code Review的流程會是如何：

在上面流程可以看到，總共有主要兩個角色：

1. 工程師：作爲開發功能的人
2. 審核者：作爲審核開發者code的人

整個步驟可以拆分幾個大項：

1. 建立需求單
2. 工程師建立分支修復完建立pull request
3. 審核者審核code - 留下comment
4. 工程師調整之後重新push
5. 審核者再次review
6. 結束

建立需求單

雖然在整個系列focus的點都是Pull Request的部分，但是可以看一下如果需求也是Azure DevOps管理的話整個會是如何。

可以在左上角的+號，或者從Boards -> Work Items 裡面去建立一個bug單。

工程師建立分支修復完建立pull request

有了需求單之後，接下來就是工程師要開始針對這個去修改。

修改的時候肯定希望開一個分支，這樣才能夠透過建立pull request來做code review。

在Azure DevOps上面的issue直接開分支很容易，只需要在單子的右邊點建立即可：

有了這個分支之後，工程師就可以針對這個分支去做修改，然後push，最後push上去然後建立pull request。

審核者審核code - 留下comment

pull request建立出來之後，接下來就是由審核者去審核code。

審核者進入Pull Request之後，可以先透過右邊的work items快速看到單子當初的描述，以及Definition Of Done，可以用來做審核的依據。

再來可以透過Files功能，來看實際修改内容

從Files tab可以看到title修改成功了，但是實際的描述沒有改到，因此這個時候就可以針對這一段做comment。

當然，如果有一些不是某一隻程式碼，那麽可以在Overview裡面的comment直接寫描述。

Review完了，直接把狀態改成Reject

工程師調整之後重新push

工程師收到被Reject之後，就會來看留下了什麽comment。

把相對應的修改commit之後在push上去，就可以在通知審核者可以在重新看一下。

還記得每一次的push都是一個update，這個時候就會多出update。

審核者再次review

這個時候審核著再重新Review的時候，可以直接看Overview的Tab頁面，就可以看到之前comment的程式碼修改情況。

1. 可以切換View Orginal Diff來看這次修改之前 (也就是第一次看到的時候)長的樣子，以及目前的樣子確認是否修改好
2. 切換的時候可以看右邊的修改結果是什麽
3. 沒有問題可以留下新的備注
4. 把這個comment resolve掉
5. 右上角可以看到所有comment都resolve結束

也可以切換到Files tab，然後只看最新的修改：

結束

最後檢查所有的comment都resolve完成。

這個時候可以把狀態改成Approve，然後Complete這一次的Pull Request。

complete之後，branch以及work item會自動關掉以及結束。

這個時候，如果回去看本來的bug單，會發現：

1. 狀態自動被改成Resolved
2. 自動增加一個comment表示merge完成
3. 有對應pull request鏈接以及merge commit的鏈接

結語

這篇介紹了整個code review從需求到結束的整個流程，並且看到了Azure DevOps作爲整個整合在一起的工具讓整個串在一起變得要找的時候非常方便。

相信到了這個階段，對於如何使用Azure DevOps做Code Review已經沒有什麽問題了，可是如果想要設定一些規則呢？

舉例來説，要完成pull request一定要至少程式可以build，或者至少有多少人Approve才可以。

這個要怎麽設定呢？下一篇([05][讓團隊彼此知道程式碼走向]如何强制走Pull Request?以及設定符合規則才能合並分支)來看看。