共用方式為


選取有效的分支策略

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

為 Team Foundation 版本控制 (TFVC) 存放庫建立分支有助於隔離風險。 請考慮小組成員在處理由五或十多人組成之軟體專案時,通常會面臨一些挑戰:

  • 該群組有一些(或可能是數個)不同的功能小組,每個小組都處理一組相當不同的功能。 但每個小組也相依於其他小組所建置的功能。 您必須隔離這些小組中完成之工作所產生的變更風險,但最終,您必須將所有工作合併成一個產品。

  • 測試小組需要穩定的程式代碼版本來測試,但同時,開發人員需要繼續使用偶爾會破壞產品的新功能。

  • 軟體有兩個舊版和一個目前版本正在進行中。 儘管大部分的開發工作都投入在目前的版本中,但舊版仍必須支持偶爾的 Service Pack 版本、重大修正和安全性修補程式,以及其他變更。

本文會探索一些常見的分支策略,以協助您做出正確的決策。

不同於存放庫範圍的 Git 分支,TFVC 分支的範圍是路徑範圍,而不是輕量型。 設定您的列,以在需要程式代碼或釋放隔離時建立分支高,且只有分支。

僅限主要

「僅限主要」策略可以是資料夾型或主資料夾轉換成分支,以啟用其他可見度功能。 您會將變更認可至main分支,並選擇性地指出具有標籤的開發與發行里程碑。

主要僅限分支策略

風險:具有 TFVC 標籤標的可變性和缺乏歷程記錄可能會增加變更控制的風險。

從主要的分支策略開始, 以策略方式 分支,並採用其他策略,視需要演變成更複雜的策略。

開發隔離

當您需要維護和保護穩定的主要分支時,您可以從main分支一或多個開發分支。 它可啟用隔離和並行開發。 工作可以依功能、組織或暫時共同作業,在開發分支中隔離。

開發人員隔離分支策略

主要分支中可能會有變更。 一律將 (FI) main 轉送至 開發 分支,並解決合併衝突。 然後反向整合 (RI) 變更回 main。 跨分支維持相同的品質橫條。 在開發建置並執行組建驗證測試(BVT),就像您在主要所做的一樣。

注意:使用此策略,小組可能會永遠保留 開發 分支,而可能會建立大型合併票證歷程記錄。

功能隔離

功能隔離是開發隔離的特殊衍生,可讓您將一或多個 功能 分支從 主要分支,如所示,或從您的 開發 分支進行分支。

功能隔離分支策略

當您需要處理特定功能時,建立功能分支可能是個好主意。

保留功能工作的存留期和相關聯的功能分支短期存留期。 經常從父分支轉送整合 (FI) 變更。 只有在符合一些已同意的小組準則,例如完成的定義時,才能將反向整合 (RI) 回到父系。 主要上的功能復原成本可能很高,而且可能會重設測試。

釋放隔離

發行隔離會從 main 引進一或多個發行分支。 此策略允許在發行時間進行並行發行管理、多個和平行發行,以及程式代碼基底快照集。

發行隔離分支策略

當發行準備好要鎖定時,是時候為發行建立新的分支了。

永不向前整合(FI)從 。 使用訪問許可權鎖定發行分支,以防止對發行進行非預期的修改。 對發行分支所做的修補程式和經常性修正可以反向整合 (RI) 回到主要分支。

注意:沒有分支案例是不可變的,這就是為什麼您注意到在發行分支上執行的緊急 Hotfix。 發展每個策略以符合您的需求,而不會失去複雜度和相關聯的成本。

服務與發行隔離

服務與發行隔離策略引進 維護分支 。 此策略允許在發行時間同時管理 Service Pack 和程式代碼基底快照集。

服務發行隔離分支策略

如果您需要服務模型供客戶升級至下一個主要版本,以及每個版本的其他 Service Pack,請使用此策略。

如同發行隔離,當發行準備好鎖定時, 會建立維護 隔離和 發行 分支。 永不將主要整合至服務,或從服務轉為發行鎖定發行分支以防止修改。 未來的服務變更可以在維護分支上完成。

如果您需要該隔離等級,請為後續版本建立新的服務與發行分支。

服務、Hotfix、發行隔離

雖然不建議這麼做,但您可以藉由引進其他 Hotfix 分支和相關聯的發行案例,繼續發展策略。

服務 HotFix 發行隔離分支策略

此時,您已成功探索一些常見的 TFVC 分支案例。 您可以發展它們,或調查其他策略,例如 功能切換、切換功能,以及關閉功能,以判斷功能是否可在運行時間使用。

Q&A

為什麼分支應該短期存留?

藉由讓分支保持短暫存留,合併衝突會保留到盡可能少。

為什麼只在必要時才分支?

若要採用 DevOps,您必須依賴建置、測試和部署的自動化。 變更是 連續、頻繁且合併作業更具挑戰性,因為合併衝突通常需要手動介入。 因此,建議您避免分支,並依賴其他策略,例如功能切換。

為什麼要移除分支?

您的目標應該是儘快將變更恢復為 main ,以減輕長期合併的後果。 暫時、未使用且豐富的分支對小組造成混亂和額外負荷。

程式代碼基底是否可以跨項目進行分支?

是。 除非小組必須共用來源,且無法共用一般程式,否則不建議這麼做。

程式代碼升級策略呢?

程序代碼提升策略感覺就像瀑布式開發時代的遺物。 它通常具有較長的測試週期,以及個別的開發與測試小組。 不再建議使用策略。 如需此策略的詳細資訊,請參閱 分支指引

開發 合併至 main 分支時,為何不會偵測到任何變更?

例如,您可能已忽略先前合併中的變更,例如,使用 keep source 衝突解決選項。 如需詳細資訊,請參閱 將開發分支合併至main:沒有合併 的變更。

TFVC 與 Git 分支策略之間是否有相似之處?

TFVC 功能隔離分支策略類似於 Git 主題分支

作者:傑西·胡文、馬庫斯·費爾南德斯、邁克·福利和來自阿爾姆的威利·肖布 |DevOps Rangers。 您可以在這裡連絡他們

(c) 2015 Microsoft Corporation. 著作權所有,並保留一切權利。 本檔提供「依目前」提供。本檔所表達的信息和檢視,包括 URL 和其他因特網網站參考,可能會變更而不通知。 您必須承擔使用本文件的風險。

本文件不提供您任何 Microsoft 產品之任何智慧財產權的任何法律權利。 您可以複製和使用本文件,以參考為目的供內部使用。