構建一次，使用gitflow和gitversion部署很多

gitflow符合我們的需求，並且giversion似乎適合gitflow。但有一件事我不完全明白。讓我解釋一下困擾我的事情。構建一次，使用gitflow和gitversion部署很多

我們在開發分支上做了一些功能性工作 - 所有軟件包都標記爲1.3.0-unstable.1,1.3.0-unstable.2等等。
每個軟件包都會通過管道 - dev，test，uat，prod。
因此，當開發準備就緒並且一切都很好時，根據gitflow我們開始發佈分支。
在發佈時不需要做任何更改，我們馬上完成 - 發佈分支合併到主開發中。
構建服務器創建一個更多的包1.3.0這是一種prod準備就緒。

如何實現構建一次，在這裏部署多少？根據所有的規則，我們需要將1.3.0-unstable.x升級到prod env，這正是因爲這個軟件包在dev和test中測試過，但是版本看起來有點奇怪，不是嗎？當來自主分支的1.3.0從未在任何地方部署過。

問題是與此類似：In the git flow model should I build from the merge commit in master to release?

答案是不是真的滿意：

我們做-no-FF，同時合併到主
它仍然是一個不同的包

來源

2016-02-28 Max

我不完全理解你的問題，但重點是：開發人員測試產品的功能分支和開發分支。一旦軟件看起來很穩定，就會建立一個新的發佈分支，並將應用交給QA團隊進行更專業的測試。如果出現任何錯誤，您可以將它們修復到發行版分支（並將其合併回開發版）。發佈分支中不允許有其他功能。一旦測試完成，您的負責人可以將系統管理員發佈到主分支上進行部署。 –

@MargaretBloom這正是我們所做的。讓我舉個例子。就像你說的那樣：我們創建了一個發佈分支，並且在發生了一些錯誤之後，這個軟件包的版本將會是1.3.0-rc3。我們應該再次部署哪個軟件包來製作？ QA的最新消息？它有一個奇怪的名字rc3，或從主分支生成的？但是從master生成的包與rc3不同 - 在這裏我們違反規則：構建一次，部署很多。 – Max

我不是專家，所以你最好等待別人;我的理解是，「構建一次，部署多個」意味着您不會向QA團隊提供在IDE中運行的源代碼，或者系統管理員要構建的源代碼，而是爲您提供構建的產品。在你的例子中，一旦你修復了一個bug，你可以從源代碼重建，並將二進制文件交給QA和系統管理員。如果QA清除測試，則系統管理員將採用相同的構建並部署它。 –

讓我自己回答這個問題。我們走到了一個地步，我們意識到使用gitflow支持多個版本/多個環境是一個巨大的負擔。因此，我們正在尋找更簡單的東西，即github flow。當然，它並沒有完全解決原來的問題（爲我們構建一次 - 部署很多），但這是我們部分解決它的方式。

我們的管道改變

來自：開發 - >測試 - > UAT - >督促

於：開發 - >測試，然後UAT - >督促

所以像我之前說的，我們正在使用github流程。無論何時我們正在研究新功能，首先 - 我們從最新的主站創建一個分支featurename。這個分支的每個版本都是1.3.0-featurename.1,1.3.0-featurename.2等版本。

一旦開發者完成了他的實現並執行了所有的開發檢查，這些準確的二進制文件將進入QA的測試環境。在質量保證人簽署此版本之後，我們很高興通過我們的第二條管線uat - > prod來推動這項工作。我們合併了featurename分支的pull request和我們之後得到的build version，讓我們說：1.3.1轉到uat環境。一旦它在那裏簽名，我們就可以將相同的二進制文件推送到產品環境。

如果同時開發了多個功能分支，我們將下一個版本推送到測試環境，該環境應該在最新的主控制器上再次通過流水線重新組裝。

來源

2016-11-15 20:04:19 Max

構建一次，使用gitflow和gitversion部署很多

回答

相關問題