git-flow：製作「發佈候選人」的工作流程/ QA網絡工件

Question

我們正在使用git-flow分支模型開發幾個包含網絡工件的項目。

參考：Vincent Driessen's git flow branching model

我們使用develop分支jenkins自動構建和部署SNAPSHOT網絡文物測試環境。

我們手動運行git flow release start和git flow release finish來構建非快照構件，這些構件被部署到我們的工件並最終部署在產品中。

（？如何運行git flow xxx命令下面是一個cheatsheet）

我的問題：應該如何工作流程，QA的工作？

鑑於：

1. 我們不想快照部署到QA
2. 如果我們在QA測試的同一工件被部署在PROD
3. 我們可以使用git flow腳本很高興和分支模型儘可能接近

看着分支模型，我自己最好的理解是：

1. 製作發佈分支（例如， release/1.1）。
2. 從發佈分支構建工件並在QA中進行測試。
3. 請在release/1.1分支更改並返回到步驟作爲必要2
4. 當測試完成後，finish釋放（合併到主）
5. 在PROD部署工件。

有沒有人有這方面的經驗，尤其是步驟2？應該如何唯一標識發佈分支中的工件？

我們使用的是發佈候選版本，在Maven版本1.1.RC1表示release-candidate1，通過1.1.RC2以下考慮，最後1.1（最終版）。

Answer 1

我認爲使用限定符是有意義的，因爲maven總是會考慮使用比無限定符1.1的版本更早的限定符1.1.RC-1。

請注意，SNAPSHOT限定符是特殊的，所以maven（可能Artifactory）將其視爲與其他限定符不同。 Maven將其視爲增量構建，而其他的素質則不是。這意味着如果您不想使用SNAPSHOT限定符，則可能必須爲發佈分支中的每個提交設置新版本。

Answer 2

我面臨同樣的問題，並將Vincent Driessen's git flow branching model擴展爲包含代表環境TEST，QA和PRD的分支。

而不是讓MASTER包含生產中的最後一個代碼，我選擇讓MASTER默認指向QA中的最後一個版本。然後，部署到珠三角僅僅是推廣已經在珠三角進行質量評估的發佈候選人。

您現在可以對QA上的版本執行修補程序，這可能會發生在爲生產版本執行修補程序時。通過將主分支重置爲您要修復的生產版本，仍然可以爲生產做修補程序。

Answer 3

大的問題，我們希望做同樣的事情。這是我們想出的。類似於@ crea1，添加了一個新的限定符（一個補丁編號）。這現在可以是發佈分支中單獨發佈的工件。

在實踐中，這是不是比你提出什麼太大的不同：

1. 列表項
2. 創建發佈分支
3. 發行版本1.0.0，QA測試這個版本
4. 做一些錯誤修正，從發佈分支做一個maven版本1.0.1（.1是額外的限定符）
5. 完成發佈時準備好，版本類似於1.0.4
6. 部署到產品

我們有一些內部依賴關係可能因測試而改變。這被證明是對這些人有效的方法。對於應用程序本身來說，它不是一個重要的版本，但是在QA完成後不必重建就可以了。這也可以應用於此。

關鍵是在版本發佈時有額外的扔掉數量。我建議不要像RC1那樣做。儘管它使得它更具描述性，但如果它是最終版本，那麼我會覺得需要重新發布/構建RC，以使RC不在最終版本中。我希望能夠將直接進行測試的相同工件放入產品中，同時在我的產品發佈版中沒有「RC」版本。

這是我認爲應該包含在gitflow模型中的一個候選版本選項。