5

所以这里是 Subversion、Jenkins、Beanstalk 设置：

  • trunk/ -> 开发主线
    • CI 建立在签到之上
    • 成功的 CI 构建产生 CD 构建，该构建推送到“测试”Beanstalk 环境
  • 分支/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 周期完成时，它会被推送到生产环境。

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

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

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

问题：

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

2 回答 2

7

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

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

示例场景：

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

  • /trunk（开发 3.0 的开发人员）
  • /tags/2.0（用于质量检查）
  • /tags/1.0（生产中的历史）

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

  • /trunk（开发 3.0 的开发人员，+ 2.0 缺陷修复）
  • /branches/2.0.*（使用 * 字符表示这是所有 2.0.* 修复将提交的位置。如果在 2.0 代码中发现另一个缺陷，您可以重用同一分支）
  • /tags/2.0（原始标签 QA 正在测试该缺陷）
  • /tags/2.0.1（2.0 代码库，只有缺陷修复）
  • /tags/1.0（生产中的历史）
于 2012-08-13T15:59:30.913 回答
1

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

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

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

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

于 2012-08-16T09:07:53.893 回答