效率和質量是軟件產品追求的兩個核心關鍵點，軟件產品研發是一個覆蓋多階段、涉及多團隊的過程，業界也已經總結出了一些很好的實踐，在保證研發效率的同時還能保證代碼質量。比如代碼提交規範、Code Review、代碼准入、CI/CD。

但是由於缺乏行之有效的研發流程規範，讓上述實踐在落地的時候往往流於形式、可有可無，讓保證質量、提升效率成為懸而難落的話題。而代碼提交不規範、不同開發模式下代碼審核與准入環節的缺失是導致質量與效率雙雙下降的重要原因。

所見非所得的代碼提交

代碼變更提交信息能夠讓外界對所變更的代碼有一個快速、清晰的認知，可以初步判斷出變更代碼的類型（新 feature 上線、bug fix、文檔修復等），變更代碼的範圍（某個接口的增刪改、某個功能的增刪改等），不僅利於代碼審核人員對於審核代碼有一個初步認知，也有利於出現問題之後的問題回溯，更重要的是有助於提高代碼的可維護性。

代碼提交規範是每個企業都在追求實踐的，但並非所有的企業都能夠通過流程 + 工具將規範進行到底，尤其在項目需要緊急上線，bug 需要緊急修復時，下面的這種代碼提價信息也就變得比較常見了：

4deaaed (HEAD -> main) add new feature
5224286 fix api bug
2506aa2 fix typo
70819a2 delete useless code

看似懂了又似乎沒懂的代碼提交信息折射出了不規範的代碼提交帶來的後果：所見非所得。

簡單但是熵增的開發模式

基於 “主” 分支的開發

由於 git 使用的複雜性，當團隊的 git 使用技巧（分支的管理、代碼的回退等）達不到一定程度時，在業務提交緊急時，git add && git commit && git push 就成了代碼提交三步曲，變更代碼被直接推送到主分支，走先提交再驗證的流程。

這是看似快捷方便的代碼提交會帶來以下問題：

• 逐漸失控的代碼倉庫
  代碼都是直接推送到 “主” 分支，代碼沒有先經過驗證就提交，容易導致有問題的代碼被合併到主分支，主分支可能會隨時被阻塞，難以保證主分支實時可用、可交付的狀態。另外，在不做提交文件限制（比如 pem、jar、war 等）的情況下，隨着功能的迭代，代碼倉庫就會 “爆倉”逐漸失控。
• 無法保證質量的代碼
  代碼變更都是先提交再去驗證（提交之後，在主線驗證），在提交前或提交後都不做 Code Review，代碼的質量是難以保證的，最終導致產品的整體質量下降。
• 返工嚴重，耗時耗力
  代碼提交到主分支上，驗證不通過就需要返工進行故障查找和修復。由於缺乏提交前的充分驗證和審核，就會導致這種返工是頻繁的、耗時耗力的。

基於 “多” 分支的開發

當然，隨着團隊對於 git branch 的熟悉，基於 branch 的業務開發也成為被很多團隊所採用的開發模式。開發人員不管是上線新功能還是修復缺陷，都是先創建一個新的分支，基於這個新分支完成代碼變更，經過驗證之後再合入主分支。

這種模式雖然能夠讓開發者之間 “互不干擾” 的進行開發，也能夠比上述基於 “主幹” 分支的開發，讓 “主幹” 分支被阻塞的時間大大縮短，但是依舊存在代碼質量無法保證的問題，因為缺失了兩個關鍵環節：

1. Code Review
Code Review 是保證代碼質量的有效一環。“只要眼睛多，bug 容易捉”，如果讓其他同行人員對於代碼變更進行 Review，不僅能夠對於變更代碼是否符合業務邏輯做一些檢查，還有可能發現一些潛在的缺陷，並且將反饋直接反饋給代碼提交者，在修復之後再進行代碼提交。很多時候，這種 Review 可能是多個回合，對於代碼質量的提高是非常重要的。

2. Approve Rules
代碼的合併需要有一定的准入規則，一來可以防止代碼提交者自己直接進行代碼合併，二來需要確保變更的代碼是經過了充分驗證的，諸如需要經過 QA 的驗證確認、需要安全團隊的安全掃描確認等，才能夠有特定的人員批准代碼的合入，變更代碼才會最終進入到主分支。

不管是上述的哪種開發模式，都沒有將項目管理、代碼變更、代碼審核、代碼准入完整的串起來，形成真正的規範化的研發流程來在保證效率的同時，保證代碼質量。

因此，尋求一個可以落地、可以推廣的規範化研發流程，是可以幫助研發團隊將一些想實施但是容易流於形式的做法真正實踐起來，真正的幫助團隊提高研發效率、保證代碼質量。而這一規範化的研發流程有幾個要素是不可或缺的：

• 所有變更的發起都要有跡可查，有地方記錄變更發起的原因，範圍等；
• 所有變更代碼都要強制執行 Code Review，避免流於形式；
• 所有變更代碼的准入要有一定的規則，只有被特定人員批准的代碼才可合入主分支；
• 所有變更代碼從構建到部署儘量自動化，避免過多手動步驟。

極狐GitLab Workflow

極狐GitLab Workflow 通過將需求管理、代碼審核、CI/CD、代碼准入、安全掃描等流程融合在一起形成規範的標準化研發流程，能夠提高不同團隊、不同人員之間的協作效率，加速軟件產品從想法到生產上線的速度，而且整個過程能夠保證代碼的質量和安全。

一切變更從 issue 開始

對於軟件產品的任何變更，諸如新功能添加、缺陷修復、安全補丁升級等，都應該有所記錄，這會讓故障回溯、安全審計變得更容易。

極狐GitLab Workflow 的起始就是利用 issue 來完成對於所需變更的詳情描述與記錄，而且可以通過 issue assign 來指定具體的負責人對 issue 進行處理與跟蹤。

比如針對一個需要修復的缺陷，可以通過下面的方式來完成缺陷的記錄：

在 issue 描述中可以詳細描述缺陷的特徵、發現的版本、如何復現、期望修復時間等信息方便修復人員對於缺陷有更清晰的認識，再通過 assignees 來指定 issue 的具體負責人，將修復責任落到實處。

此外，Epic、Milestone 等極狐GitLab 項目管理功能有助於項目管理人員對缺陷的修復進度進行查看與把控。

基於分支的開發

創建完 issue 之後，可以創建一個 MR（Merge Request）來實現基於分支的開發，後續的所有操作（代碼變更、CI/CD、代碼審核等）都與此 MR 相關聯，這也完成了 issue 與 MR 的關聯。

極狐GitLab Workflow 支持在 issue 創建的同時創建 MR，而且可以指定要創建的分支：

Code Review + Approve Rule，嚴格把控代碼質量

可以在 MR 中直接指定 Reviewer 對於 Code 進行 Review，而且可以指定多個 Reviewer。Reviewer 可以在提交的變更文件中進行代碼 Review，如果需要添加 Review 意見，直接在對應的代碼行數前點擊 comment 圖標，即可出現添加 Review comment 的方框，輸入 Review comment，點擊 Start a review 即可。

代碼提交者可以根據 Review comment 進行相應的修改，在確定可以合併後，即可和 Approver 進行溝通，進行代碼合併。

可以通過添加 Approve Rules 來對代碼的准入規則做限定：

比如可以指定對應的 Approver 以及最少 Approve 人數以及 Rules 生效的分支：

而且可以通過額外的設置還組織代碼提交者自己進行 Code Approval、組織隨意修改 Approval Rule 等，來進一步規範 Code Approval 流程：

這種多人進行 Code Review，多級進行 Code Approve 的機制，形成了把關代碼質量的雙保險。

CI/CD 實現變更的自動化構建

CI/CD 能夠完成變更代碼的自動化構建、測試、安全掃描等，不僅能夠加速代碼從變更到部署的速度，也保證了每次代碼變更都會經過同樣的構建、驗證流程。而且最重要的是 CI/CD Pipeline 的構建結果、測試結果、安全掃描等結果都可以直接反饋到 MR 中，為 Code Approver 提供數據決策：

沒有規範可落地的研發流程就無法在團隊、組織內推廣提高代碼質量與提升研發效率的一些最佳實踐。

極狐GitLab Workflow 通過將需求管理、代碼質量保證、CI/CD、安全防護等手段融合在一起，用流程 + 配置的方法讓流於形式、難以落地的實踐都發揮真正的作用，實現用標準化研發流程來實現效率與質量的雙提升。