我的任务是立即更新我们的构建过程以提高效率，我花了一周的时间阅读最佳实践和策略，但我仍然没有找到解决当前问题的方法。
背景
目前我们有一个单片构建/应用程序，它真正需要拆分为至少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来确保所有依赖项都已编译并且是最新的？
答案 0 :(得分：0)
我只是想问你的想法，你的应用程序应该在不同的发布周期。模块化对于代码质量是一件好事，但如果您的模块处于单独的发布周期，则会引入大量开销。特别是，版本管理变得非常负担，如果你弄错了，你可以引入运行时错误。
这些单独的应用程序如何相互关联？它们之间是否存在依赖关系（可能通过共享库）？他们互相沟通吗？他们一起部署了吗？
如果它不是必要它们处于不同的发布周期，那么你最好将它们保持在一起。