与maven,teamcity和TFS的分支策略

Question

我的任务是立即更新我们的构建过程以提高效率,我花了一周的时间阅读最佳实践和策略,但我仍然没有找到解决当前问题的方法.

背景

目前我们有一个单片构建/应用程序,真正需要拆分为至少4个带有一些共享库的应用程序.我们目前不分支,除非我们绝对必须.我们有一个teamcity构建,建立在每个TFS登记的基础上.当我们准备好发布时,我们会冻结代码并且只针对QA中发现的错误进行检入.显然这是一种可怕的做法,我们终于得到了改变它的批准.

提出的解决方案

建议的解决方案是拆分应用程序,并为每个应用程序提供不同的发布周期,从每个版本的ant迁移到maven和branch.

分支 - 现在我们在源代码控制中只有一个主干.我想我们希望在准备发布时分支主干,并更新分支以查找QA中发现的错误.当构建准备好被释放时,将分支更改合并回主干.

以下是我计划设置TFS的方法.

+Apps
    +App1
        +Components
            +Core
            +Web
        +Branches
    +App2
        +Components
            +Core
            +Web
        +Branches
    +Libraries
        +Lib1
        +Lib2
        +Branches

考虑管理POM中的所有POM和版本似乎现在太困难了.我已经阅读了maven发布插件,但我不确定它是否可以按照我想要的方式进行分支.

下一个问题是让团队工作.我想为每个应用程序提供3个teamcity项目.一个始终指向中继的开发项目,一个用于测试QA构建的QA项目和一个用于构建修补程序更改的生产项目.每次新版本发布到QA时,我都必须更新QA teamcity项目以指向新版本分支并更新teamcity中的版本内部版本号.当该版本通过QA时,我必须更新生产团队项目,以指出刚刚通过QA的分支并将构建号更新为刚刚通过QA的构建号.

当然,有一个更好的策略.

问题

我应该把这些分支文件夹放在哪里？

QA构建是否仍然是快照,直到构建进入预生产？

如何配置teamcity来获取这些分支而不更改每个版本的源路径？

是否应该为开发人员使用的每个应用程序创建父POM,以确保所有依赖项都已编译并保持最新？

Answer 1

我只是想质疑您的想法，即您的应用程序应该处于不同的发布周期。模块化对于代码质量来说是一件好事，但如果您的模块处于单独的发布周期，则会带来大量开销。特别是，版本管理成为相当大的负担，如果出错，可能会引入运行时错误。

这些单独的应用程序如何相互关联？它们之间是否存在依赖关系（可能通过共享库）？他们互相交流吗？他们是一起部署的吗？

如果没有必要将它们放在单独的发布周期中，那么您最好将它们放在一起。