TFS 分支/源代码控制策略

Question

我目前正在启动一个包含许多不同部分的 .net 项目，也就是

1) Web Service API
2) Web Portal
3) 2 Windows Services + 1 Biztalk server
4) About 3 different Databases
5) Service bus connects them all via pub/sub
6) Client Web Application (Old) that already exists on another Team Collection to consume the web service api.

每个项目区域都是可单元测试的，因此可以将它们与不同的消息传递部分隔离开来。我计划在 AZURE 上进行登台/产品部署。我计划包括某种集成测试。每次签入都会有一个 CI / Build 以包含自动化测试。

只有在所有部分都完成后，整个应用程序才能运行。

问题

1) 我应该如何构建我的源代码控制和分支策略？我想有简单的 Dev/Main/Release 分支，这 6 个部分应该在一个分支中还是应该都有自己的 Dev/Main/Release 分支？ CI / 构建 / 版本控制呢？应该按部分还是按整个 6 个部分对它们进行版本控制。

2) 就集成测试的结构化测试而言，我应该在何处或何时将代码放入并运行测试？我认为直到最后我才能进行集成测试。

任何建议都会很棒。

乔什

Answer 1

这是一个相当主观的问题，但我可以提供一个意见。显然，一个人的最佳分支策略可能因团队、软件、测试要求等而异。

我的建议是为软件创建一个主分支，在项目解决方案中包含所有单元测试。当您开始对项目进行第一次开发时，将该项目（或者如果它们都需要一起发布，则将它们全部分支）分支到开发功能分支（实际上，只需创建一个名为 Dev and branch 的源代码控制文件夹进入该功能）。

完成开发后，将其合并回 Main。 Main 是一个门控签到通常是有意义的。合并后 - 删除您的开发功能分支。

当您准备好发布时，创建一个发布分支并从那里进行部署。如果您需要手动测试，请测试您的发布分支。如果您需要修复发布分支，然后分支修复，修复然后合并回来；完成后删除该分支。

总之，创建一个分支，直到你有理由创建另一个； dev/main/release 分支更具概念性 - 这并不意味着您维护 3 个独立的代码库。