[英]How to set up a code review workflow using gitlab,jenkins,git?
所以我的問題是我想建立一個代碼審查流程,我擁有的工具是:git,gitlab,jenkins .. 我的想法是擁有一種團隊成員需要在任何時候填寫的表格或清單其他成員想要合並一些新代碼,如果檢查表填寫正確並且新代碼被審閱者批准,則應該合並代碼,否則合並請求被拒絕。
每個人都知道我如何實現這一目標嗎? 或者也許有比清單更好的主意?
謝謝你們,
此致
你可以使用 GitLab CI,就像 Jenkins 一樣,他可以在合並之前通過測試、編譯和做你想做的任務。 在 Gitlab 中,您有自動合並,這在您配置時完成。 ( https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html )
使用GitLab 13.7 (2020 年 12 月),您不需要像 Gerrit 這樣的第三方工具。
您現在擁有正式的合並請求審閱者:
合並請求的審閱者
請同事審查您的代碼應該是貢獻代碼的常規部分,但它通常是不必要的復雜。
像要求評論這樣的簡單任務可能會導致混淆。 例如,你應該怎么問? 一封電郵? 評論? 聊天消息?
如果沒有正式的流程,審核可能會不一致且難以跟蹤。 以前,一個選項是為合並請求指定一個審閱者,但即使采用這種形式,作者和審閱者都出現在同一個受讓人字段中,這使得其他團隊成員很難知道誰在做什么。
GitLab 13.7 為合並請求引入了審閱者,允許作者向某人請求審閱。
新的“審閱者”字段允許以與受讓人類似的方式將用戶指定為審閱者。 審查者會收到通知,邀請他們審查合並請求。這為請求審查提供了正式流程,並闡明了合並請求中每個用戶的角色。
未來的迭代將包括顯示與合並請求最相關的審閱者以及將審閱者置於中心的簡化合並請求批准流程。
您可以在合並請求審閱者分配史詩中了解更多詳細信息。
同樣的GitLab 13.7 (2020 年 12 月)通過以下方式促進了審查過程:
直接從合並請求中選擇一次顯示一個文件
合並請求審查是確保來自貢獻者的代碼質量的一項基本任務,因為這是作者和審查者之間大部分交流的地方。 但是,隨着合並請求變得更大並且涉及更多文件,合並請求差異的導航和性能可能變得困難。
GitLab 13.7 引入了在合並請求視圖中一次顯示一個文件的選項。 當您導航到合並請求的更改選項卡時,單擊齒輪圖標並選中標記為一次顯示一個文件的框。 這將一次顯示一個文件,並啟用Prev和Next按鈕在文件之間導航。
單文件模式提供了更干凈的工作區並增強了審閱者對單個文件的關注,同時提高了合並請求差異的性能和導航。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.