CICD的Git分支策略

Question

只是在考慮以下分支策略時要牢記CICD。

1. 主分支-

   1.1開發部門-大師級的分叉

     Team A branch - Fork from Development branch and merge to development branch after feature implementation for QA/Integration testing Team B branch - same as above 1.1.1 Release branch - Goes in PROD 

團隊A和團隊B分支合並並完成質量檢查后，請創建發布分支並對其進行最終回歸。 此發行分支將進入生產。

然后將Release合並到master分支。

目的-

1. 主分支是穩定的，並且其中包含生產運行代碼。

2. Team分支可以部署在DEV環境上，並且在服務器上具有必需的CICD配置。

這種方法有什么問題嗎？

Answer 1

這不是真正的CI（用CI，我指的是開發策略，而不是工具），因為您有團隊分支，這意味着團隊的工作直到合並到master中才被整合-總是有其他團隊看不到並且看不到他們的工作的團隊。查看其他團隊的工作（因此可以進行調整基准/合並地獄 ）。

對於真正的CI戰略的所有團隊將在工作master （如果真的拉任務的分支，他們會被合並到主非常快，不超過幾天的壽命更多） -每個人都幾乎是在同一頁上。

CI工具（可能在暫存環境中為CD工具）將密切關注master健康狀況。

只要master是current release就緒的，或者當下next release更改開始與current release發生沖突（發行分歧）時， current_release分支就會被拉出，並且永遠不會合並回master（由於發行分歧，這種合並將是一個大問題） 。 current_release任何錯誤修復（如果也適用於master ）都將被精心挑選和兩次提交（僅因為一個分支上的修復是確定的，並不意味着它在另一分支上是確定的）。

實際上， current_release分支是您的生產分支。 它需要根據current release功能量身定制的CI / CD設置。 生產版本只是該分支上的標簽。

master分支將繼續朝着next release發展。

沖洗並重復。

您還可以為多層發行版（major / minor / etc）提供current_release其他子分支，這些子分支也永遠不會合並回其父分支。 每個此類子分支與其父級之間的關系與current_release和master之間的關系完全相同。

Answer 2

要真正地執行CI（並且需要CD才能執行CI），您將非常有規律地合並以掌握母帶，並且沒有很長的功能分支。 我相信，每天將其設置為“ CI”。

您建議的一種替代方法是讓短暫的開發人員分支從事日常工作。 然后要有一個部署管道，通過一系列測試階段來移動每個代碼更改。 只有在每個階段都通過更改后，它們才能進入下一個階段並准備投入生產。 這使您可以在主服務器上工作，但保持穩定，並且只允許傳遞代碼進入生產環境。

要處理獨立的要素工作，可以使用要素切換而不是分支。 如果一切正常，您可以打開功能並按下以測試它們並進行部署。 如果不是這樣，或者如果業務需要刪除某個功能，則可以關閉該功能並繼續安全使用master。 我已經在使用的兩個產品上看到了很好的效果。

我知道這非常簡化，但這只是為您提出替代建議，希望對您有所幫助。 您可以了解更多有關在大量博客上實現這些技術以及stackoverflow答案的信息-http: //martinfowler.com/articles/feature-toggles-http : //www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf - 功能切換與功能分支