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上进行暂存/prod部署。我计划包含某种类型的集成测试。每个签入都会有一个CI / Build，以包括自动化测试。
只有当所有部分都完成时，整个应用程序才能正常工作。
问题
1)我应该如何构建我的源码控制和分支策略？我在考虑只有Dev/Main/Release分支，这6个部分应该放在一个分支中，还是它们都应该有自己的Dev/Main/Release分支？CI / Build / Versioning怎么样？它们应该是按部分还是按整个6个部分一起进行版本控制。
2)关于集成测试的结构化测试，我应该在哪里或者什么时候放入代码并运行测试？我不认为我可以做集成测试，直到最后。
任何建议都是很棒的。
乔希
回答 1
Stack Overflow用户
发布于 2013-09-13 21:32:08
这是一个相当主观的问题，但我可以提供一个意见。显然，根据团队、软件、测试需求等的不同，一个人的最佳分支策略可能不同于另一个人。
我的建议是为软件创建一个主分支，包括项目解决方案中的所有单元测试。当你在一个项目上做你的第一部分开发时，将该项目分支(或者如果它们都需要一起发布，然后将它们全部分支)到一个开发功能分支(实际上，只需创建一个名为dev的源代码控制文件夹，然后分支到该功能)。
当您完成开发后，将其合并回Main。Main作为一个门控签入通常是有意义的。一旦你合并了-删除你的开发功能分支。
当您准备好发布时，创建一个发布分支并从那里部署。如果您需要手动测试，那么请测试您的发布分支。如果你需要修复发布分支，然后转移到修复，修复，然后合并回来；在你完成之后删除该分支。
总之，创建一个分支，直到您有理由创建另一个分支；dev/main/release分支更具概念性-这并不意味着您要维护3个独立的代码库。
https://stackoverflow.com/questions/18778119
复制相似问题
腾讯云开发者
