使用 maven 发布具有多个长寿命分支的版本答案

【问题标题】：Releases with multiple long lived branches using maven使用 maven 发布具有多个长寿命分支的版本
【发布时间】：2012-08-05 01:36:09
【问题描述】：

下面是 Subversion、Jenkins、Beanstalk 设置：

trunk/ -> 开发主线
- CI 建立在签入之上
- 成功的 CI 构建会生成 CD 构建，该构建会推送到“测试”Beanstalk 环境
branches/qa/ -> 当前候选版本
- CI 建立在签入之上
- 成功的 CI 构建会生成 CD 构建，该构建会推送到“QA”Beanstalk 环境
分支/产品/->当前版本
- CI 建立在签入之上
- 成功的 CI 构建会生成 CD 构建，该构建会推送到“Prod”Beanstalk 环境

基本上我想做的是这样的：

开发周期从主干开始（主干：0.1-SNAPSHOT）
当开发周期完成时，分支到 qa 并成为 qa 周期。同时在主干中开始下一个开发周期（主干 0.2-SNAPSHOT，qa: 0.1-SNAPSHOT）
当 qa 周期完成时，分支到 prod 并执行 maven 发布。同时开始下一个 qa 周期（主干 0.2-SNAPSHOT，qa：0.2-SNAPSHOT，prod：0.1）

我们的想法是进行短冲刺，在每个冲刺结束时，开发周期结束，质量保证周期开始。质量保证周期完成后，它会被推送到生产环境。

我想保留分支并从分支合并到\，而不是删除并重新创建。这个想法是在 qa 中所做的任何修复都将合并回 intro trunk，并且在 prod 中所做的任何更改都将合并回 qa（并返回到主干）。

因此，prod 是一个“热”分支，代表生产环境的当前状态。

这是为一小群从事为期一周的冲刺工作的开发人员准备的。

问题：

【问题讨论】：

【解决方案1】：

我之前围绕分支和发布做过一些类似的工作，根据我的经验，你所描述的设置很快就会变得非常笨拙和官僚化。

Domenic D. 的回答与我喜欢的设置非常接近，尤其是对于少数开发人员而言。您拥有的分支越多，代码库的管理就越复杂，可能性也越大您将通过不良的合并做法引入错误。

在我看来，您没有提到的一件事很重要，那就是您的入住政策。 SCM 不是未完成工作的备份，您应该努力确保主线至少始终在构建。严格这一点，最终会让每个人的生活更轻松。

不过，重要的是，无论您提出何种发布程序，请确保您得到团队的认可，并且他们不必“强制”到位。这表明你想出的东西可能有问题，不正确，很可能很快就会被忽视或颠覆。

【讨论】：

【解决方案2】：

我不推荐 qa 和 prod 分支。阅读颠覆最佳实践。我推荐The SVN Book，特别是关于分支/合并的第 4 章。

即使是 QA（通过标签），您也应该对每个版本进行版本控制。主干用于当前的开发工作，标签用于发布版本（定义为“功能完整”，而不是它所处的环境），分支用于缺陷修复（除其他外）。

示例场景：

1.0 版正在生产中，您的团队刚刚将 2.0 版发布给 QA 进行测试，现在正在开发 3.0 版。此时您将拥有：

如果您的 QA 团队在 2.0 中发现问题，您将从 2.0 标记创建一个分支。进行修复，合并到主干，然后将分支发布为 2.0.1（另一个标签）。然后你会得到：

【讨论】：