在基于主干的开发中发布(版本)提交 [英] Release (version) commit in trunk based development
问题描述
我最近一直在研究基于主干的开发(https://trunkbaseddevelopment.com)以及我们的工作非常适合这种方法(小团队、频繁发布、一些直接提交或短期分支等).
I've been looking into trunk based development recently (https://trunkbaseddevelopment.com) and what we do fits the approach nicely (small team, frequent releases, some direct commits or short-lived branches, etc.).
我唯一的困难是标记版本.我们做 CI，但并不是每一次都投入生产，我们希望在代码交付到客户环境后增加(更改)版本.
The only struggle I have is tagging the releases. We do CI but not every coming goes to production, and we want to increment (change) the version once the code is shipped to the customer's environment.
在主干基础开发中(以惯用的方式)我应该如何发布?你对 master 上的 release 提交感觉如何?我可以看到两种方法(我正在使用 Java + Maven 位，这只是应该妨碍的工具).
How in the trunk bases development (in an idiomatic way) should I do a release? How you feel with release commits on master? I can see two approaches (I'm using Java + Maven bit that's just tooling that should come in the way).
方法#1
- //trunk 中的版本信息:'SNAPSHOT'
- git checkout -b release/1.11
- //在发布分支上更新版本并提交
- //构建完整的项目并发布
- git 结帐大师
- //继续功能
方法#2
- //主干中的版本信息:'1.11-SNAPSHOT'
- git 分支发布/1.11
- //将 master 分支上的版本更新为 1.12-SNAPSHOT'
- git checkout release/1.11
- //将发布分支上的版本更新为1.11"并提交
- //构建完整的项目并发布
- git 结帐大师
- //继续功能
第二种方法在存储库的历史记录中留下一个提交，我不知道如何看待.后一种方法使代码更具可追溯性，并且发布过程更容易一些.
The second approach leaves a single commit in the repository's history, which I'm not sure how to feel about. The latter approach makes the code slightly more traceable and the release process a bit easier.
顺便说一句，我不太关心错误修正等.我们确实发布了一个新版本.但如果需要修补程序，我们计划挑选
On a side note, I don't much care about bugfixes, etc. We do release a new version. But if a hotfix is required, we plan to cherry-pick
推荐答案
不是为了更新版本而创建发布分支，而是以真正的 CI/CD 方式将每个提交视为可发布.
Instead of creating release branches just to update the versions, treat every commit as releasable in true CI/CD fashion.
- //主干中的版本信息:SNAPSHOT"，开发者从未编辑过，仅在本地构建时使用
- 每次推送到主干时，您的 CI 工具都会构建并运行所有测试并创建一个可发布的包.在做任何事情之前，CI 工具将 SNAPSHOT 版本替换为某个唯一的版本号(见下文).永远不会提交此版本更改，它仅用于构建.为了便于跟踪，CI 工具可以添加唯一版本作为指向提交的 git 标记(如果唯一版本号是从下面描述的 git 信息派生的，则不严格要求)
通过这种方式，您向主干提交的所有内容都是潜在发布，除了记下交付给客户的唯一版本需要作为发布的一部分完成之外，无需其他流程.
This way all you commits to the trunk are potential releases and no additional process except for noting down the unique version shipped to the customer needs to be done as part of a release.
关于唯一版本号我通常让 CI 工具将 SNAPSHOT 版本替换为类似 <git commit date>-<short git commit hash> 之类的东西有以下好处
Regarding unique version numbers I usually let the CI tool subsitute the SNAPSHOT version to something like <git commit date>-<short git commit hash>, which has the benefits of
- 真正独一无二(感谢哈希)
- 很容易被人类解释和比较(感谢日期)
- 可复制(由于使用了 git 信息)
这篇关于在基于主干的开发中发布(版本)提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
