发布与使用maven

Question

所以在这里多长寿命分支的颠覆，詹金斯，魔豆设置：

• 主干/ - >发展主线
  • CI基础上签
  • 成功的CI构建产卵CD构建推向 “测试” 魔豆环境
• 分支/ QA/- >当前发行候选版
  • CI基础上签
  • 成功的CI构建派生是推动CD构建以 “QA” 魔豆环境
• 分支/生产/ - >当前版本
  • CI基础上签
  • 成功的CI建立产卵是推动以 “督促” 魔豆环境CD构建

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

• 开发周期在启动干线（主干：0.1-SNAPSHOT）
• 当开发周期结束分支QA和QA被循环。也在trunk中开始下一个开发周期（trunk 0.2-SNAPSHOT，qa：0.1-SNAPSHOT）
• 当qa循环完成时，转到prod并执行maven release。也开始下一个QA周期（躯干0.2-SNAPSHOT，QA：0.2-SNAPSHOT，PROD：0.1），其中在每一个发展cylce的端

的想法是有短跑结束和QA周期开始。 qa周期完成后，它将被推送到生产环境。

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

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

这是一个为期一周的短跑运动的开发团队。

问题：

1. 这是如何设置的声音？
2. 我可以让maven正确行事，还是我需要编写脚本？
3. 谁是你的爸爸？他做了什么？

Answer 1

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

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

示例方案：

1.0版是集生产，你的团队刚刚发布了2.0到QA测试，并且现在正在开发3.0版本。此时你会：

• /中继线（开发工作3.0）
• /tags/2.0（用于QA）
• /tags/1.0（历史，什么是生产）

如果您的QA团队在2.0中发现问题，您将从2.0标签中创建一个分支。让你的修复，合并到主干然后释放分支为2.0.1（另一个标签）。然后你会被留下。

• /中继线（开发者3.0工作，+ 2.0缺陷修复）
• /branches/2.0.*（使用*字符表示这是所有2.0 *如果在2.0代码中发现另一个缺陷，您可以重复使用同一分支）
• /tags/2.0（原始标签QA正在测试该缺陷）
• /tags/2.0.1（2.0代码库，只有缺陷修复程序）
• /tags/1.0（历史是什么在生产中）

Answer 2

我之前已经做过一些类似的分支和释放工作，根据我的经验，您所描述的设置最终变得非常笨重和官僚化。

Domenic D.的答案非常接近我喜欢的那种设置，特别是对于少数开发人员。您拥有的分支越多，代码库管理越复杂，越多很可能你会通过错误的合并实践来引入错误。

在我看来，你没有提到的一件事很重要，因为在开始时要正确使用检查策略。 SCM不是不完整的工作的备份，您应该努力确保主线至少始终在建设中。对此要严格，最终会让每个人的生活更轻松。

但主要的是，不管你发布什么发布程序，都要确保你从你的团队买进，并且他们不必被“强制”到位。这是一个迹象，表明你所提出的内容可能有问题是不正确的，并可能很快被忽略或颠覆。