13

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

参考：Vincent Driessen 的 git 流分支模型

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

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

（如何运行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发布（合并到master）
  5. 在产品中部署工件。

有没有人有这方面的经验，尤其是 step 2？应该如何唯一标识发布分支的工件？

我们正在考虑使用发布候选版本控制，其中 maven 版本1.1.RC1表示release-candidate1，之后是1.1.RC2，最后是1.1（最终版本）。

4

3 回答 3

2

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

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

  1. 项目清单
  2. 创建发布分支
  3. 发布版本 1.0.0，使用此版本进行 QA 测试
  4. 进行一些错误修复，从发布分支执行 maven 发布 1.0.1（.1 是额外的限定符）
  5. 准备好后完成发布，版本类似于 1.0.4
  6. 部署到产品

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

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

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

于 2017-02-15T16:41:22.073 回答
1

我认为使用限定符是有意义的，因为 maven 总是会考虑带有限定符1.1.RC-1的版本比没有限定符的版本旧1.1。

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

于 2016-08-12T12:54:25.537 回答
0

我遇到了同样的问题，并扩展了Vincent Driessen 的 git 流分支模型以包含代表环境 TEST、QA 和 PRD 的分支。

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

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

扩展的 git 流

于 2016-10-12T09:17:50.263 回答