git-flow:制作"发布候选人"/ QA网络工件的工作流程

Question

我们正在使用git-flow分支模型开发包含Web工件的多个项目.

参考:Vincent Driessen的git flow分支模型

我们正在使用develop分支并jenkins自动构建和部署SNAPSHOTWeb工件以测试环境.

我们手动运行git flow release start并git flow release finish构建非快照工件,这些工件部署到我们的工件并最终部署在prod中.

(如何运行git flow xxx命令？这是一个备忘单)

我的问题: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.RC-1比没有限定符的版本旧1.1。

请注意，SNAPSHOT限定符很特殊，因此 Maven（可能还有 Artifactory）对待它的方式与其他限定符不同。Maven 将其视为增量构建，而其他限定符则不然。这意味着如果您不想使用限定符，您可能必须为发布分支中的每个提交设置一个新版本SNAPSHOT。