.net TFS分支/源控制策略

我目前正在为.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/构建，以包括自动测试

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

问题

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

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

任何建议都很好

---

Josh这是一个相当主观的问题，但我可以提供一个意见。显然，根据团队、软件、测试需求等的不同，一个人的最佳分支策略可能会有所不同

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

完成开发后，将其合并回主应用程序。Main作为门控签入通常是有意义的。合并后-删除dev功能分支

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

---

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

很抱歉回答得太晚，但我提出问题的原因是因为它们都是单独的部分/服务…只需考虑每个版本每个CI每个部署每个构建1个服务，而不是每个自动化测试运行每个CI每个部署（多台机器）每个构建10个服务。