使用Maven的Gitflow工作流程-何时构建什么? [英] Gitflow Workflow with Maven - when to build what?

问题描述

Gitflow引入了几个分支，例如develop，release，hotfix，并鼓励使用功能分支.

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

尽可能自动地完成构建过程是明智的，但是问题是:什么时候我们应该构建SNAPSHOT版本，什么时候应该构建发行版本，什么时候不应该构建所有版本?

我认为以下内容很明智:

• 只要功能分支合并回develop，就会触发SNAPSHOT构建并将其部署到Maven存储库.
• 创建release分支后，将开始发布版本.

但是还有更多情况:

• 当我修复release(或hotfix)分支上的错误时，我是否总是想要一个新的发行版?
• 在开发功能期间，我应该建立在功能分支上吗?如果是这样，该版本应被称为(1.2.3-FEATURE1-SNAPSHOT?)?

解决方案

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

一旦您放弃了这些想法，事情就会变得简单得多.而且，由于不能将基于分支的版本用于发行版，因此使功能分支有所不同的意义何在?您可能会忘记将分支和版本控制的概念混合在一起.

使用持续交付功能(即使您没有充分使用它，您也可以借鉴它的想法)，任何构建都可能会进入PRD，因此:

1. 使用您喜欢的任何类型的版本构建二进制文件.使用Maven，最简单的方法就是坚持使用SNAPSHOT *，而永远不要使用发布"版本.它是独特的，是标准的，并且在Nexus(保留策略)方面具有一些优势.
2. 当您准备好使用PRD并选择了发行版本时-以某种方式对其进行标记.它可以是一个CI Job，可以跟踪所有PRD部署；或者您可能会在页面上看到所有发行版本；或者您可以将二进制文件转移到另一个Maven存储库(仍然可以是SNAPSHOT类型).如果您使用快照的保留策略，则后者很方便.

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

PS:如果您只是想遵循GitFlow的建议-会有一个官方页面用于版本控制.但是您将遇到问题中已经提到的所有(或更多)问题.

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

Gitflow introduces several branches like develop, release, hotfix, and also encourages feature branches.

In a Maven project, you usually build SNAPSHOT and release versions, and often number them with semantic, three-digit versions.

It would be sensible to automate the build process as much as possible, but the question is: When should we build a SNAPSHOT version, when should be build a release version, when should we build none of that at all?

I image the following could be sensible:

• Whenever a feature branch is merged back into develop, a SNAPSHOT build is triggered and deployed to the Maven repository.
• When a release branch is created, as release build is started.

But there are much more situations:

• When I fix bugs on the release (or hotfix) branch, do I always want a new release build?
• During developing a feature, should I build on the feature branch? If so, what should this version be called (1.2.3-FEATURE1-SNAPSHOT?)?

解决方案

Let's start with releases. Whether a version is going to be released or not is decided in the future when an already-built binary is deployed to TST envs and checked. When committing or building you can't predict whether the version will be a "release".

Once you abandon these ideas things will become much simpler. And since you can't use branch-based versions for releases, what's the point of making things different for feature branches? You might as well forget about mixing the concepts of branching and versioning together.

With Continuous Delivery (you can borrow its ideas even if you don't use it to the fullest) any build may potentially go to PRD, thus:

1. Build a binary with any type of versioning that you like. With Maven the easiest is to stick with SNAPSHOT* and never use "release" ones. It's unique, it's standard, it has some advantages with Nexus (retention policies).
2. When you're ready to go to PRD and the release version is chosen - tag it somehow. It can be a CI Job that keeps track of all PRD deployments; or you may have a page with all the release versions; or you may transfer the binary to another Maven repo (still can be a SNAPSHOT type). The latter is convenient if you go with retention policies for the snapshots.

Also we usually want to mention from which commit the binary was built. You can put this into the binary (some kind of version.properties) during the build time. You may even create an endpoint in your app that servers this version for convenience.

PS: if you simply want to follow GitFlow advice - there's an official page for the versioning. But you'll have all the problems (and more) that you already mentioned in the question.

* Maven automatically resolves SNAPSHOT versions into timestamp-ones. But you can't actually use this functionality because the timestamp is going to be different for different artifcacts during the build. If you want to keep version the same across all the binaries in the build you need to generate and assign a timestamp version manually using versions:set. It's not complicated, but is worth mentioning.

这篇关于使用Maven的Gitflow工作流程-何时构建什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！