一千萬個為什麽

搜索

持續集成和隔離功能測試



我已經接受了工作中的任務,即將所有人從使用TFS源代碼管理轉移到Git,因為開發團隊一直認為Git可能是解決大量團隊問題的靈丹妙藥。 我在一個月前進行了遷移,幸運的是,Git為團隊修正了一件事 - 代碼審查現在更加結構化,因為Git中的pull請求為開發人員和審閱者提供了一個可審計的平臺,以便將代碼合並到master分支中。然而,仍然存在合並沖突的問題,其中一些需要2或3個小時才能解決。團隊質疑工具(Git)是否應該受到責備,而在分析過程中,我認為團隊中存在許多其他基本過程和錯誤。僅舉幾例,這些與我不一樣:

  • 公司維護的所有產品(Visual Studio項目)都位於一個Visual Studio解決方案下。這大約有40多個VS項目,包括圖書館,服務和數據庫層級。如果需要對一個產品進行生產更新,則需要發布整個解決方案(以及其他產品)。
  • 有4個Scrum團隊在同一個VS解決方案上工作,負責管理他們自己的產品。所有Sprint都在不同的日子以兩周的周期開始,因此在任何時候,每個團隊的Sprint都處於不同的狀態。但是,由於第一個問題提出的問題,當涉及到每月產品發布的復雜性時,每個產品的代碼可能處於不同的階段。

無論如何,這描繪了部分場景來幫助提出我的問題。我們現在使用以下結構使用Git:

  • 功能分支 - 用於在Sprint中處理的每個用戶故事
  • 開發分支 - 一旦Pull Request獲得批準,並且在測試服務器上單獨對進行了單獨測試,所有Feature分支均合並到此處
  • 主分支 - 已成功測試的功能在主分支中被挑選出來

我的問題是,DevOps/CI如何獨立處理新編碼的功能?我從來沒有在一個完全隔離的地方測試過新的變化,所以我無法理解為什麽它對我的新開發團隊如此重要。在我看來,我們能夠越早地測試代碼庫其他部分的新變化就越好。

轉載註明原文: 持續集成和隔離功能測試

一共有 2 個回答:

首先,git當然不是為了合並需要很長時間。清潔合並是 git的標誌,除非它以某種破碎的方式使用。所以我鼓勵你看看究竟是什麽問題。如果您的開發人員經常對相同的文件進行徹底更改,那麽它可能更多地是內聚/耦合問題,而不是基礎合並工具。

第二;我喜歡做獨立的功能測試,如果您認為您的測試套件是在幹凈的環境中運行的功能分支(只有分支更改)。事實上,我喜歡用這種方式來測試所有的分支。如果 developmaster 分支中的某個功能不能使用,那麽它怎麽會變成綠色?不言而喻, develop / master 也需要進行測試。

您甚至可以通過將 feature 合並到 temp_develop_with_feature (或任何您可能稱之為的)來執行預合並測試,也就是模擬將分支合並到 develop (使用不同的名稱)並測試 。

顯然,所有這些都假設足夠的測試資源(虛擬機等)可用並且速度足夠快,並且所有內容都是100%自動化的,這兩者應該很容易用Jenkins,Gitlab或任何您使用的工具來實現(如果不是的話,那麽可能是時候看另一個......)。

然而,仍然存在合並沖突的問題,其中一些沖突   需要2或3個小時才能解決。該團隊正在質疑,如果   工具(Git)應該歸咎於分析。

導致合並麻煩的是什麽?

  • 為什麽解決合並沖突需要兩或三個小時?
  • 開發者使用什麽工作流程?

總之,這個合並沖突的原因是什麽?

git是否導致此問題?

這與git無關,但看起來像是一個工作流程問題。

我最喜歡的流程是 GitHub流程。當必須創建一個功能時,將從主服務器創建一個新的分支,當開發完成時,將創建一個PR,當檢查完成時分支可以合並到主服務器中。

還有其他的流量,但我不喜歡 gitflow 是我見過的在多家公司中,開發人員正在應用一種“通過墻壁”的方法,因為他們將多個功能合並到開發分支而沒有發布。幾個月之後,軟件必須從主機上釋放出來,然後會出現很多問題。我個人喜歡此答案中的以下引用

不要使用git-flow。因為這個圖,它看起來不錯   可愛的彩色點和很好的線條,但在現實中   看起來像一個瘋狂的彩色線條和點的雜亂網絡。

更頻繁地發布軟件

當應用github流程時,將會出現較少的合並沖突,因為當創建新功能時,必須從主設備創建一個分支。由於功能被合並到主設備中,功能分支中的提交將在主設備之後發生更大的變化。

學科</強>

盡管可以應用工作流程,但最重要的是紀律。開發人員應確保如果他們創建了一個Pull Request,它們駐留在功能分支中的提交超出了主控。其他開發人員應該強制執行這些功能,因為這些功能很難合並且難以查看。