java - Gitflow 与 Maven 的工作流程 - 何时构建什么？

Question

Gitflow 引入了多个分支，例如 develop、release、hotfix，并且还鼓励功能分支。

在 Maven 项目中，您通常会构建 SNAPSHOT 和发布版本，并经常使用语义的三位数版本对它们进行编号。

尽可能自动化构建过程是明智的，但问题是:我们什么时候应该构建快照版本，什么时候应该构建发布版本，什么时候应该不构建任何版本？

我认为以下可能是明智的:

• 每当功能分支 merge 回 develop 时，都会触发 SNAPSHOT 构建并将其部署到 Maven 存储库。
• 当创建 release 分支时，发布版本启动。

但还有更多情况:

• 当我修复 release(或 hotfix)分支上的错误时，我是否总是需要新的发布版本？
• 在开发功能期间，我应该在功能分支上构建吗？如果是这样，这个版本应该叫什么(1.2.3-FEATURE1-SNAPSHOT？)？

Answer 1

让我们从发布开始。当将已构建的二进制文件部署到 TST envs 并进行检查时，将在将来决定是否发布版本。当提交或构建时，您无法预测该版本是否会是“版本”。

一旦你放弃这些想法，事情就会变得简单得多。既然你不能使用基于分支的版本来发布，那么对功能分支进行不同的处理有什么意义呢？您不妨忘记将分支和版本控制的概念混合在一起。

通过持续交付(即使您没有充分利用它，您也可以借用它的想法)，任何构建都可能会转到 PRD，因此:

1. 使用您喜欢的任何版本控制类型构建二进制文件。对于 Maven，最简单的方法是坚持使用 SNAPSHOT* 并且永远不要使用“发布”版本。它是独一无二的，它是标准的，它具有 Nexus 的一些优势(保留策略)。
2. 当您准备好前往 PRD 并选择发布版本时 - 以某种方式对其进行标记。它可以是一个持续跟踪所有 PRD 部署的 CI 作业；或者您可能有一个包含所有发行版本的页面；或者您可以将二进制文件传输到另一个 Maven 存储库(仍然可以是 SNAPSHOT 类型)。如果您采用快照保留策略，后者会很方便。

此外，我们通常想提及二进制文件是从哪个提交构建的。您可以在构建期间将其放入二进制文件(某种 version.properties)中。为了方便起见，您甚至可以在应用程序中创建一个端点来服务此版本。

PS:如果您只是想遵循 GitFlow 建议 - 这里有一个示例 could version 。但是您将遇到问题中已经提到的所有问题(以及更多)。

* Maven 自动将 SNAPSHOT 版本解析为时间戳版本。但您实际上无法使用此功能，因为在构建过程中不同的 Artifact 的时间戳会有所不同。如果您想在构建中的所有二进制文件中保持相同的版本，则需要使用 versions:set 手动生成并分配时间戳版本。这并不复杂，但值得一提。