一千萬個為什麽

搜索

是否有一個CI工具可以保證分支質量水平沒有回歸?



傳統上,CI系統僅對集成分支中的質量水平進行監控,方法是在已經提交更改的代碼庫上執行QA驗證,觀察回歸並發送人工幹預通知。

但是,當檢測到這些回歸時,分支機構至少在開始QA驗證後就已陷入困境,並且將保持這種狀態(甚至變得更糟!),直到找到所有的肇事者,對其進行維修並進行新的QA驗證確認分支質量水平已恢復。在這段時間內,該分支可能會被視為正常開發阻塞。

是否有CI工具能夠實際阻止這樣的回歸發生,它將執行

commit  QA驗證,並且僅當用相應提交更新代碼庫時才允許提交還要通過那些預先提交的QA驗證,從而保證最低的分支質量水平?


Update: the assumption is that suitable automated QA verifications with appropriate coverage to be able to detect the respective regressions are available for invocation by the CI tool(s).

轉載註明原文: 是否有一個CI工具可以保證分支質量水平沒有回歸?

一共有 4 個回答:

據我所知,您正在尋找一種工具來拒絕提交來破壞構建 - CI工具可能無法通過實際修復代碼來阻止回歸,但它可以阻止您將錯誤的代碼添加到存儲庫。

Atlassian has a few interesting applications of Git hooks:

服務器端預接收鉤子對於持續集成來說是一種特別強大的補充,因為它們可以防止開發人員將代碼推送到主人,除非代碼符合某些條件 - 如精英忍者監護人,從而保護它免受不良代碼的侵害。

如果您使用的是Git,那麽這些鉤子非常強大(並且對於 SVN Mercurial 和其他版本控制系統),您可能會發現使用它們來運行預先提交檢查很有用。

Git文檔有創建頁面如果他們不符合某個標準,就會拒絕推送,這很容易適應這種用例。

然而,很多人會認為拒絕提交

是個壞主意feature 分支上 - 當構建因某種原因而中斷時,你只是在浪費時間來對抗你的CI系統,而不是真的修復這個bug。

master 分支上,拒絕破碎的合並是有意義的,因為您可能希望確保它始終生成。對於特性分支,您 不可避免地破壞事物,並且由於代碼現在不會進入生產,所以更有意義警告你,而不是完全拒絕你的提交。

沒有工具可以保證沒有回歸 - 這取決於你的測試,而不是執行它們的工具。但是,您可以幫助防止將陷入的回歸陷入集成分支。你可以使用預先提交的鉤子來做到這一點,但通常使用pull請求會更容易(希望你已經用於同行代碼審查)。

如果一個分支與它的上遊(PR合並到的地方)保持同步,並且它的測試通過了,那麽它們在合並後仍然會通過;合並後目標分支的狀態將與合並之前源分支的狀態匹配。

通常不是特別困難(取決於所使用的工具)來指示PR中的源分支是否與目標保持最新,以及它是否具有傳遞的CI構建。您可以將此作為需求(通過策略和/或在軟件中實施)來合並拉取請求。

像Reitveld和Zuul一樣,真正的持續集成工具(而不僅僅是連續測試)可以提供幫助,盡管它們與您編寫的測試和代碼評論一樣好。

ApartCI is a CI system designed exactly to prevent regressions, thus guaranteeing flat or increasing branch quality level. Still in beta.

它以這種方式編排集中的預先提交驗證,以確保只有在驗證之後才進行更改,以及所有其他所做的更改,以達到或超過最新的分支質量級別。

與傳統的開發人員驅動的預先驗證驗證相比,這是經常並行執行的關鍵區別,這為由未曾一起測試過的幹擾性更改所引起的回歸留下了空間。

該工具也是旨在輕松擴展 - 能夠保持非常高的傳入候選人變化率和支持在同一個集成分支中工作的開發人員數量為100人/ 1000人。

Disclaimer: I'm the author of the tool and founder of the company offering it. Apologies for the ad.