git-flow:制作 "release candidates"/QA 网络 Artifact 的工作流程

Question

我们正在使用 git-flow 分支模型开发几个由网络 Artifact 组成的项目。

引用:Vincent Driessen's git flow branching model

我们正在使用 develop 分支和 jenkins 自动构建和部署 SNAPSHOT 网络 Artifact 到测试环境。

我们手动运行 git flow release start 和 git flow release finish 来构建部署到我们的 Artifact 并最终部署到产品中的非快照 Artifact 。

(如何运行 git flow xxx 命令？这里有一个 cheatsheet )

我的问题:QA 的工作流程应该如何运作？

鉴于:

1. 我们不想将快照部署到 QA
2. 如果我们在 QA 中测试的相同 Artifact 部署在 PROD 中，那就太好了
3. 我们可以尽可能接近地使用git flow脚本和分支模型

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

1. 创建一个发布分支(例如 release/1.1)。
2. 从发布分支构建 Artifact 并在 QA 中进行测试。
3. 在 release/1.1 分支中进行更改，并根据需要返回步骤 2
4. 测试完成后，完成发布( merge 到master)
5. 在产品中部署 Artifact 。

有没有人对此有任何经验，尤其是步骤 2 ？应该如何唯一标识来自发布分支的 Artifact ？

我们正在考虑使用release candidate版本控制，其中maven版本1.1.RC1表示release-candidate1，后面是1.1 .RC2，最后是 1.1(最终版本)。

Answer 1

问得好，我们想做同样的事情。这是我们想出的。与@crea1 类似，添加了一个新的限定符(补丁号)。这现在可以是发布分支中单独发布的 Artifact 。

在实践中，它与您的提议没有太大不同:

1. 列表项
2. 创建发布分支
3. 发布版本 1.0.0，使用此版本进行 QA 测试
4. 修复一些错误，从发布分支发布 1.0.1 版 maven(.1 是额外的限定符)
5. 准备就绪后完成发布，版本大概是1.0.4
6. 部署到产品

我们有许多内部依赖项可能会因测试而改变。事实证明，这对那些人来说是一种有效的方法。对于应用程序本身，它是否是一个版本并不重要，但在 QA 完成后不必重建会很好。这也可以应用于此。

关键是版本发布时多了一个throw away number。我建议不要做类似 RC1 的事情。尽管它使它更具描述性，但如果它是最终版本，我会觉得有必要重新发布/构建 RC，以便 RC 不在最终版本中。我希望能够将经过测试的相同 Artifact 直接带入产品中，同时我的 pom 中没有用于产品发布的“RC”版本。

在我看来，这是应该包含在 gitflow 模型中的东西，一个发布候选选项。