拉請求通信策略需要

Question

做基於trunk的開發到實現持續部署。這是我們的分支策略。

主>什麼活在生產

發佈>測試通過並釋放CI服務器

開發>從開發團隊每天創建的合併點。

如果我們考慮從發佈到主階段執行pull請求。 該方法有什麼優點和缺點？我們如何與開發團隊溝通，他們想在開發分支做PR？

Answer 1

我真的不知道答案，但認爲這個問題的背景下值得進一步討論。

如果您正在進行連續部署，那麼我不確定發佈分支的目的。這似乎是重複的兩種目的：

• 「主」：代碼部署/發佈
• 「發展」綜合功能 分支機構，但不準備釋放

或者，是你使用它來分組裏程碑或計劃的主要版本（即版本/ 1.0,版本/ 2.0），就像一個小型主分支。
我不會考慮這種持續交付（部署，也許），但它肯定是一個有效的模式，如果您的項目需要分階段發佈而不是持續交付。

同樣考慮您的CI設置以及它如何與您的分支機構整合也很重要。它不是部署到Production的源代碼，而是來自CI系統的構建工件。考慮這可能會簡化您的分支模型。 如果你想回滾，你不想從源重建應用程序，你想重新部署先前版本的預構建工件。同樣，如果您的構建已通過所有測試並準備發佈 - 希望已在您的預生產環境中運行 - 您不希望將其合併到不同的分支，重新構建它，然後部署新的構建 - 您使用經過測試的構建。

下一個考慮因素是每個附加分支都會給開發人員增加時間&的複雜性。合併，拉取請求，等待CI運行等都不是免費的，因此將分支策略的複雜性降低到所需的最小值是一個很好的目標。

要回答您關於PR到哪裏的問題，您是否認爲「Develop」作爲主線，並試圖保持其穩定性並始終在工作？
如果是這樣，那麼從功能到開發的PR是關鍵集成。然後開發將被構建，測試並部署到您的測試環境中。
從那時開始分支（即創建一個Release分支）然後被認爲是好的。 將您的測試環境中的工件提升爲生產，無需重新構建，可能會取消您的某個分支機構的需求。