git flow：制作的工作流；“释放候选人”QA web工件

我们正在使用

git-flow

分支模型开发几个由web工件组成的项目

参考：

我们正在使用

develope

branch和

jenkins

自动构建和部署

SNAPSHOT

web工件来测试环境

我们手动运行

git-flow-release-start

和

git-flow-release-finish

来构建非快照工件，这些工件被部署到我们的工件工厂，并最终部署到prod中

（如何运行

git flow xxx

命令？下面是一个示例）

我的问题：QA的工作流程应该如何工作

鉴于：

我们不想将快照部署到QA

如果我们在QA中测试的相同工件部署在PROD中，那就太好了

我们可以尽可能地使用

git-flow

脚本和分支模型

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

创建发布分支（例如，

release/1.1

）

从发布分支构建工件，并在

QA

中进行测试

在

release/1.1

分支中进行更改，必要时返回步骤2

测试完成后，

finish

release（合并到master中）

在prod中部署工件

有没有人有过这方面的经验，尤其是步骤

2

？发布分支中的工件应该如何唯一标识

---

我们正在考虑使用发布候选版本控制，其中maven版本

1.1.RC1

表示

release-candidate1

，后面是

1.1.RC2

，最后是

1.1

（最终版本）。

我认为使用限定符是有意义的，由于Maven将始终考虑具有限定符<代码> 1.1的版本。RC-1 < /代码>比没有限定符的版本<代码> 1.1 < /代码>。

---

请注意，

SNAPSHOT

限定符是特殊的，因此maven（可能还有Artifactory）将其与其他限定符区别对待。Maven将其视为增量构建，而其他限定符则不然。这意味着，如果您不想使用

快照

限定符，您可能必须为发布分支中的每个提交设置一个新版本。

我遇到了同样的问题，并扩展到包括代表测试、QA和PRD环境的分支

我选择让MASTER默认指向QA中的最后一个版本，而不是让MASTER包含生产中的最后一个代码。然后，部署到PRD只是将已经在QA上的候选版本升级到PRD

您现在可以在QA上对版本进行热修复，这可能会比对生产版本进行热修复发生得更多。通过将主分支重置为要修复的生产版本，仍然可以对生产进行热修复

---

好问题，我们也想做同样的事情。这是我们想到的。与@crea1类似，添加了一个新的限定符（补丁号）。现在，它可以是来自发布分支的单独发布的工件

实际上，它与您的建议没有太大区别：

列表项

创建发布分支

发布版本1.0.0，使用此版本进行QA测试

进行一些bug修复，从发布分支执行maven 1.0.1版（1是额外的限定符）

准备好后完成发布，版本类似于1.0.4

部署到prod

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

关键是在发布时版本中有一个额外的丢弃号。我建议不要做像RC1这样的事情。尽管这使它更具描述性，但如果它是最终版本，我会觉得有必要重新发布/构建RC，以便RC不在最终版本中。我希望能够将直接测试过的同一工件引入到prod中，同时在我的pom中没有prod版本的“RC”版本

---

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

是的，我明白你的观点。你只需要善于管理你的版本。可能在主分支中使用1.0，在通过QA-1.0.X推送发布时使用1.0.1，最终在prod中使用。