我目前正在为.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上进行staging / prod部署。我计划包括某种集成测试。每次签入都会有一个CI / Build，包括自动化测试。
整个应用程序只能在所有部件完成后才能运行。
问题
1）我应该如何构建源代码控制和分支策略？我想只有Dev / Main / Release Branch，如果6个部分在一个分支中，或者它们都有自己的Dev / Main / Release分支？ CI / Build / Versioning怎么样？它们应该是每个部分还是整个6个部分的版本。
2）在构建集成测试测试方面，我应该在何时何地将代码放入并运行测试？我认为直到最后我才能进行集成测试。
任何建议都会很棒。
约什
答案 0 :(得分：2)
这是一个非常主观的问题，但我可以提出意见。显然，根据团队，软件，测试要求等，一个人的最佳分支策略可能会有所不同。
我的建议是为软件创建一个主分支，包括项目解决方案中的所有单元测试。当您在项目上进行第一次开发时，将该项目（或者如果它们都需要一起发布然后将它们全部分开）分支到开发功能分支（实际上，只需创建一个名为Dev and branch的源控制文件夹）进入该功能）。
完成开发后，将其合并回Main。通常有必要将Main作为门禁办理登机手续。合并后 - 删除您的开发功能分支。
当您准备发布时，创建一个Release分支并从那里进行部署。如果需要手动测试，请测试发布分支。如果你需要修复发布分支，然后分支修复，修复然后合并;完成后删除该分支。
总之，创建一个分支，直到您有理由创建另一个分支; dev / main / release分支更具概念性 - 它并不意味着你维护3个独立的代码库。