我看到在我的xxx.visualstudio.com帐户中我只能有一个项目集合（defaultcollection）。我想做的是组织项目和文件夹（我有一些不同网站共享的图书馆项目），但我找不到任何方法来做这件事，而且我找不到任何关于这样做的文件。
我是唯一需要这个吗？
理想的结构如下：
DefaultCollection
---分享帮助
--- Library2
--- Library3
---的WebSite1
--- WEBSITE2
--- WebSite3中
然后每个网站链接并使用任何图书馆项目。
应该很容易......
AB
答案 0 :(得分：1)
首先关闭：无论是在Visual Studio Online还是自托管服务，都要将所有内容保存在一个TPC中，除非您是一家拥有多个部门的大公司。即便如此，我还是认为你并不需要不止一个TPC。 其次：通常，您希望尽可能少地使用团队项目;您拥有的越多，更新流程模板，工作项等时的维护就越多。如果您在产品中使用相同的流程模板，这可以使生活变得更加简单。 第三：Blankenship等人在Professional Team Foundation Server 2012的书中有一个很棒的部分。关于各种场景的分支/版本控制设置，包括这个场景，但是我会重新发现我认为对你来说相关的内容，以及为我们做了什么（好吧，我帮助我们走向了什么） 。 这可能会有点偏离主题，但我认为我需要更深入一些才能正确回答这个问题。 让我从基本的分支结构开始。
这里有几个问题 - 您是否希望将内部库发布为Prod1和Prod2解决方案中包含的.dll，NuGet包或.csprojs等？
假设.dlls / nuget 为了简单起见，并且为了避免我们曾经有过的毛茸茸的问题，让我们假设我们已经使用相同版本的已发布内部库发布分支获得 Prod 1和Prod 2 即可。任何要修复的修补程序都被视为针对Release进行的生产修补程序，然后重新发布Release并将修补程序合并到其他分支。 内部代码的持续开发是针对Dev，unstable / RC针对Main。
假设您将内部库项目直接添加到Prod1 / Prod2解决方案 - 创建解决方案文件夹InternalLibraries，然后在那里添加.csprojs。问题是您所指的内部图书馆的分支是什么？你需要回答这个问题的最前沿 - 如果发布，你就可以发布dll或NuGet。如果是Main，您可以帮助验证内部库是否已准备好合并到发布和发布。如果Dev，你是一个勇敢的灵魂，并且基本上做持续集成，所以我想考虑取消内部图书馆Dev分支并坚持使用Main和Release。或者你可以匹配分支 - Prod1 Dev - ＆gt;内部图书馆Dev，Prod1 Main - ＆gt;内部库主要等。这种内部库和客户产品的发布周期相同。
好的，这在源代码管理中会是什么样子？假设每个产品有一个团队项目：
$ / PROD1 主要 开发 释放
$ / Prod2的 主要 开发 释放
$ / InternalLibrary 主要 开发 释放
在解决方案中：
Prod1.sln
InternalLibraries \
InternalLibrary1
AllYourOtherStuff \
我建议你的分支保持在同一级别（即$ / Prod1 / Main和$ / Prod1 / Dev而不是$ Prod1 / Main和$ / Prod1 / Features / Feature1，因为相对参考路径可能会变得毛茸茸您是直接将内部.csproj文件添加到Prod1 .sln。如果您使用.dlls或NuGet发布，则会更容易。
然后，您只需要正确设置本地和团队构建工作区，并且（应该）是金色的。
在这个主题上显然有很多，但如果我在这里正确的轨道，你需要更多的反馈，请告诉我。我有一种感觉，这可能已经过度或者没有回答这个问题:-P