git jenkins和生產構建方法

Question

我目前正在使用git和jenkins與maven進行構建。 我想知道您在“為生產而建造”方面的最佳做法是什么。

我的一個想法是創建一個新分支（我們稱其為Production），並在我們完成母版上的所有功能時進行構建。

另一個想法是在發布一個版本（使用maven：release）並構建該標簽之后。

我很想聽聽該領域的一些實際經驗

還有其他想法嗎？

Answer 1

我們正在使用此處描述的分支模型http://nvie.com/posts/a-successful-git-branching-model/

包括修補程序在內的所有開發工作都在分支機構中完成。 然后，當一個或多個分支合並到master中時，我們將進行生產構建和部署。 大多數開發是在開發分支的功能分支中完成的。 當工作合並到開發中時，它將被構建並部署到其他項目使用的開發環境中，即dev是整個生產環境的開發鏡像。 然后，當工作合並到發布分支中時，該分支將部署到我們的QA環境中。 在那里，我們的質量檢查團隊需要進行進一步的測試，當他們簽字后，我們將合並為大師。

我當時正在考慮對此進行更改，即每晚將所有功能和開發自動合並到一個單獨的每晚分支中，該分支僅用於構建它並驗證我們沒有引入合並問題或新的集成錯誤。 每天都會創建一個新的每晚分支。

Answer 2

您可能會發現Martin Fowler的這篇文章很有幫助。

CI的主要思想之一是將代碼從主要開發主干中釋放到生產環境中。 現在，在實踐中使用該方法可能會遇到一些麻煩，但是至少這是我們應該努力的目標。

我們為不同的客戶提供單獨的分支機構，但沒有針對開發與生產的分支機構。 當我們認為某個特定的修訂版本已准備好投入生產時（即通過所有自動化測試並且主觀具有一組全面的功能），它將轉到質量控制部門，然后“祝福”或“詛咒”它。 通過QC后，該版本將被半手動標記。 從理論上講，可以按需重建它，但是我們通常不必再次構建它，因為構建的主要工件是Release和Debug安裝程序。