3

要求發佈分支和持續交付

  • 我們有2個環境。 - 測試和產品
  • 我們想要做連續部署。
  • 我們正在使用Git Flow。

使用git-flow,我們應該在生產環境中部署release(或master)分支。 (兩個不同的管道,一個持續集成(分支開發),一個用於連續傳遞(分支主)。

應該如何使用我的版本分支?

我心目中是,如果測試通過開發,我會讓CI服務器創建一個發佈分支提交,並將更新的發佈分支部署到我的產品分段插槽中,經過業務批准後其中一個發佈點將被部署到產品中

這意味着我讓CI服務器自動創建發佈分支並重新運行生產環境的臨時插槽上的所有測試。如果失敗,它將報告並刪除發佈分支,否則它將創建發佈點,觸發網絡交換並將其合併到主控。

這種方法有什麼優點和缺點?最佳做法是什麼?

我們真的需要發佈分支特別是在我們沒有使用功能切換到獨立版本? (有許多人在同一項目上工作)

enter image description here enter image description here] [2

參考

回答

1

通常我會在您認爲代碼足夠接近穩定時創建/剪切發佈分支。然後你需要改進這個分支直到它準備好發佈。在此之後,您將進行廣泛的迴歸測試,然後最終標記並釋放它。

如果您正在進行真正的連續發佈,那麼您可能會跳過很多測試,因此即使擁有發佈分支也沒有什麼大問題。風險很大,但如果它符合你的模型,你就可以做到。

+0

「創建/剪切發佈分支」意思是在發佈分支中創建發佈點的CI? –

+0

@RıfatErdemSahin創建一個實際的分支。在分支「準備就緒」之後,您可以將它合併到「主」中,這可以啓動自動化部署或感謝響應的東西 –

+0

。我的計劃:思考發佈分支在部署中的部署步驟。主分支機構將從經過良好測試的分級環境中啓動網絡交換。 –

2

混帳流說,關於發佈分支:

發佈分支支持編制新的產能釋放。他們允許最後一刻點我的和交叉的。此外,它們允許修正小錯誤併爲發佈版本(版本號,構建日期等)準備元數據。通過在發佈分支上完成所有這些工作,開發分支被清除以接收下一個大版本的功能。

如果您的組的工作流程與發佈分支的用例不匹配,請勿使用它們。如果您發現以後需要它們,請開始使用它們。

我們在我工作的一個組中使用git-flow。通常我們只有一個或兩個開發人員在維護項目上工作,而且我們很少需要同時修復錯誤並添加功能。除非我們有特定的場景,否則我們不會使用發佈分支。

總的來說,我喜歡你設置的管線。

+0

發佈分支機構支持新產品發佈的準備。 >>>同意。商界人士可能不想與所有發佈點一起生活。有些是有道理的,有些是沒有意義的。 (可能有一個營銷活動需要時間安排) –