使用maven发布多个长寿分支

Bri*_*ley 5 java version-control release-management maven jenkins

所以这里是Subversion,Jenkins,Beanstalk设置:

  • trunk/ - >开发主线
    • CI建立在签入之上
    • 成功的CI构建产生了CD构建,推动了"测试"Beanstalk环境
  • branches/qa/ - >当前发布的候选人
    • CI建立在签入之上
    • 成功的CI构建会产生推动"QA"Beanstalk环境的CD构建
  • branches/prod/ - >当前版本
    • CI建立在签入之上
    • 成功的CI构建产生了CD构建,推动了"Prod"Beanstalk环境

基本上我想要做的是:

  • 开发周期从主干开始(主干:0.1-SNAPSHOT)
  • 当开发周期完成时,分支到qa并且是qa循环.也在trunk中开始下一个开发周期(trunk 0.2-SNAPSHOT,qa:0.1-SNAPSHOT)
  • 当qa循环完成分支到prod并执行maven释放.也开始下一个qa周期(主干0.2-SNAPSHOT,qa:0.2-SNAPSHOT,prod:0.1)

这个想法是短冲刺,在每个结束时,一个开发循环结束并且qa循环开始.当qa循环完成时,它被推送到生产环境.

我想保留分支并从分支合并到\而不是删除和重新创建.这个想法是,在qa中进行的任何修复都将合并回介绍主干,并且在prod中进行的任何更改都将合并回qa(并返回到主干).

因此prod是一个"热门"分支,代表了生产环境的当前状态.

这是一个小团队的开发人员工作一周的冲刺.

问题:

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

Dom*_* D. 7

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

即使是QA(通过标签),您也应该对每个版本进行版本控制.Trunk用于当前的开发工作,标签用于已发布的版本(定义为"功能完整",而不是它所处的环境),分支用于缺陷修复(除其他外).

示例场景:

版本1.0正在生产中,您的团队刚刚发布了2.0到QA进行测试,现在正在开发3.0版本.此时您将拥有:

  • / trunk(开发人员在3.0上工作)
  • /tags/2.0(用于QA)
  • /tags/1.0(生产中的历史)

如果您的QA团队在2.0中发现问题,您将创建2.0标记的分支.进行修复,合并到trunk然后将分支释放为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(生产中的历史)