使用 Maven、TeamCity 和 TFS 的分支策略
我现在的任务是更新我们的构建流程以提高效率，我花了一周时间阅读最佳实践和策略，但我仍然没有找到解决当前问题的方法。
背景
目前，我们有一个整体构建/应用程序，确实需要将其拆分为至少 4 个带有一些共享库的应用程序。除非绝对必要，否则我们目前不会分支。我们有一个基于每次 TFS 签入的 teamcity 构建。当我们准备好发布时，我们会冻结代码，并且仅签入修复 QA 中发现的错误。显然这是一种糟糕的做法，我们终于获得了改变它的批准。
建议的解决方案
建议的解决方案将拆分应用程序，并为每个应用程序提供不同的发布周期，从 ant 迁移到 maven，并为每个版本创建分支。
分支 - 现在我们在源代码管理中只有一个主干。我认为当我们准备好发布时，我们希望从主干分支出来，并针对 QA 中发现的错误更新分支。当构建准备好发布时，将分支更改合并回主干。
以下是我计划如何设置 TFS。
+Apps
+App1
+Components
+Core
+Web
+Branches
+App2
+Components
+Core
+Web
+Branches
+Libraries
+Lib1
+Lib2
+Branches
现在考虑管理所有 POM 和 POM 中的版本似乎太困难了。我已经阅读了 Maven 发布插件，但我不确定它是否可以按照我认为我们想要的方式进行分支。
下一个问题是让 teamcity 正常工作。我正在考虑为每个应用程序创建 3 个 teamcity 项目。始终指向主干的开发项目、用于测试 QA 构建的 QA 项目和用于构建修补程序更改的生产项目。每次有新版本进行 QA 时，我都必须更新 QA teamcity 项目以指向新的版本分支并更新 teamcity 中的版本版本号。当该版本通过 QA 时，我必须更新生产 teamcity 项目以指向刚刚通过 QA 的分支，并将内部版本号更新为刚刚通过 QA 的内部版本号。
当然有比这更好的策略。
问题
我应该将这些分支文件夹放在哪里？
在构建进入预生产之前，QA 构建是否仍应为快照？
如何配置 teamcity 来获取这些分支而不更改每个版本的源路径？
开发人员使用每个应用程序是否应该有父 POM，以确保其所有依赖项均已编译并保持最新？
I have been tasked with updating our build process right now to be more efficient and I have spent a week reading best practices and strategies but I still have not found a solution for our current problem.
Background
Currently we have one monolithic build/application that really needs to be split apart into at least 4 applications with some shared libraries. We currently do not branch unless we absolutely have to. We have a teamcity build that builds on each check-in to TFS. When we are ready for a release we have a code freeze and only check-in fixes for bugs found in QA. Obviously this is a terrible practice and we have finally gotten approval to change it.
Proposed Solutions
The proposed solution will be to split up the application and have different release cycles for each application, move from ant to maven and branch per release.
Branching - Right now we just have a main trunk in source control. I think we want to branch off the trunk when we are ready for a release, and update the branch for bugs found in QA. When the build is ready to be released, merge the branch changes back into the trunk.
Here is how I was planning on setting up TFS.
+Apps
+App1
+Components
+Core
+Web
+Branches
+App2
+Components
+Core
+Web
+Branches
+Libraries
+Lib1
+Lib2
+Branches
Thinking about managing all of the POMs and versions in the POMs seems WAY too difficult right now. I've read up on the maven release plugin, but I'm not sure if it can branch in the way I'm thinking we want to.
Next problem is getting teamcity working. I was thinking of having 3 teamcity projects for each app. A dev project that always points at the trunks, a QA project for testing the QA build and a production project to build changes for hotfixes. Each time a new release comes to QA I would have to update the QA teamcity project to point at the new release branch and update the release build number in teamcity. When that release passes QA I would have to update the production teamcity project to point that the branch that just passed QA and update the build number to the build number that just passed QA.
Surely there is a better strategy that this.
Questions
Where should I be putting these branch folders?
Should QA builds be snapshots still until the build goes to pre-production?
How do you configure teamcity to pick up these branches without changing the sources path for every release?
Should there be parent POMs for each app that the developers use to make sure all of their dependencies are compiled and up to date?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我只是想质疑您的想法，即您的应用程序应该处于不同的发布周期。模块化对于代码质量来说是一件好事，但如果您的模块处于单独的发布周期，则会带来大量开销。特别是，版本管理成为相当大的负担，如果出错，可能会引入运行时错误。
这些单独的应用程序如何相互关联？它们之间是否存在依赖关系（可能通过共享库）？他们互相交流吗？他们是一起部署的吗？
如果它们没有必要处于不同的发布周期，那么您最好将它们放在一起。
I just want to question your thinking that your applications should be on different release cycles. Modularization is a good thing for code quality but if your modules are on separate release cycles you introduce a lot of overhead. In particular, version management becomes quite a burden and if you get it wrong you can introduce runtime bugs.
How do these separate applications relate to each other? Is there any dependency between them (maybe via a shared library)? Do they communicate with each other? Are they deployed together?
If it is not necessary that they be on separate release cycles then you're probably better off keeping them together.