VSTS：分支和合並發展最好的方法 - QA - 生產

Question

我使用VSTS源代碼控制，CI和發佈管理 我試圖建立的代碼只有一次，而不是每個環境或分支機構。 發佈管道是： Dev - > QA - > PROD

我只有一個分支或codbase，其中團隊提交更改。當修補程序的所有代碼準備就緒時，CI會觸發Build。我創建了一個發行版 ，並通過管道將其推廣，直到將其部署到生產環境中。

我需要知道一個分支是否適合我們，所以如果我們要解決一些錯誤或創建一個新功能，只需創建一個子分支並將代碼提交給主分支。

我試圖避免使用3個分支爲每個環境。我認爲CI和發佈管理爲我們提供了從以前的版本創建版本的能力。

那麼，是什麼在我的情況是缺點和這兩種方法的優點（3個分支機構或只有一個主科）？

Answer 1

通常，一個發佈管道應該只有一個分支。您可能在同一個管道中有多個環境，但部署到它們的版本應該是相同的，因爲發佈管道反映了一個過程，即在構建之後最終發佈了您的軟件。例如，該版本首先部署到QA環境進行測試，並且只能在QA環境測試通過後部署到生產服務器。 QA使用一個分支的構建並且Prod使用另一個分支的構建是沒有意義的。有關詳細信息，請參閱此鏈接：Where to deploy? Environments in Microsoft Release Management。

而對於分支，則是關於您的開發過程。以下是MSDN提供的一些建議供您參考：

何時該團隊添加分支？

您應在下列情況下創建分支：

• 當你必須在不同的時間表/週期比 現有分行發行代碼。

• 當你的代碼需要一個不同的分支政策。如果您創建一個新的 分支機構，並擁有新的政策，則可以爲您的 項目添加戰略價值。

• 當向客戶發佈功能並且您的團隊計劃 進行的更改不會影響計劃的發佈週期時。

您不應該爲每個用戶故事創建分支，因爲它會造成較高的集成成本 。雖然Team Foundation Server使 分支變得容易，但如果您有許多分支，則管理分支的開銷可能會變得很重要 。

檢查此鏈接瞭解詳細信息：Branch strategically

Answer 2

你不需要每環境分支，但你需要問自己關於你的開發過程中的一些問題。

您多久發佈一次新功能？您是否擁有完全自動化的全面的單元，集成，迴歸和用戶驗收測試，並在每次簽入時運行？

如果你開發新的功能，你沒有全套的真棒自動化測試，那麼你可能需要至少1個分支以上。 1開發新功能和1支持實時代碼庫。閱讀ALM Rangers branching guidance並從那裏出發。