架构你的团队项目
节选自《Visual Studio Team System更佳敏捷软件开发》第8章“设置TSF版本控制”8.1节8.1架构你的团队项目（Structuring Your Team Project）
Team Foundation版本控制（TFVC）系统在安装Team Foundation Server（TFS）的过程中就已经设置好了，其相关的工具也随着Visual Studio Team Suite（或其他的编辑环境）安装在你的桌面上了，因此，大多数涉及项目设置版本控制的工作是关于你的存储库如何组织的问题，以使团队中的成员都能很容易地找到所需的东西。
产品和探索文件夹（Production and Spike Folders）
在Visual Studio Team System（VSTS）中，所有TFVC存储库中的根目录必须属于团队项目，这反映了一个事实，即存储库中的材料的基层结构是项目团队。开发团队可以在他们认为合适的根目录中自由构建他们在存储库中的那部分内容，但我们建议你在开始的时候就创建一个分离的区域，一部分区域存储你的开发团队打算交付商业应用的材料，一部分区域存储所有的非产品代码或测试，它们可能是不断开发出来的。
提醒：使用简单的规则，所有的东西都放进探索目录中，这些规则只是根据团队的产品标准开发的代码和产品目录层次。
练习8-1：在你的存储库中创建文件夹
以下的练习中创建了两个文件夹，分别是Production和Spike，它们都在$/OSPACS存储库的根目录下。
以Peter（OSPACS成员）的身份登录到开发PC上，打开Visual Studio，然后连接OSPACS团队项目，如第5章的练习5-7所描述的那样，有关这个PC机和Luke的安全组的项目信息请见附录A。
打开源代码资源管理器（视图|其他窗口），选择在第5章练习5-1中创建的$/OSPACS根文件夹，然后在上下文菜单（右击鼠标|获得最新版本）中选择获得最新版本。
浏览打开的文件夹对话框，因为你还没有在开发PC2上定义一个工作区的目录。因此，为这个工作区创建一个C:\Peter\OSPACS目录，并点击“OK”关闭这个对话框，然后完成获取最新版本操作。
在你的源代码控制资源管理器中选择
$/OSPACS根目录，然后在
$/OSPACS下创建两个文件夹，命名为“Production”和“Spike”，在源代码控制菜单中选择新建文件夹（文件|源代码控制|新建文件夹）。
重复步骤2，使你的工作区和存储库同步，这样Production 和Spike目录就会创建在C:\Peter\OSPACS中。
描述在进行原型工作时，敏捷团队经常使用术语spike——探索，用于探索他们的项目的某些方面。通常，一个开发人员会存储一些代码在个人的搁置集中（请见第9章中的练习9-6），当代码不再需要时会被抛弃。但是我们建议你在团队项目的根目录下创建一个标准的存储库文件夹，叫Spike，用于强调一个事实，在这个文件夹中找不到一个代码可以用于产品目标。在你的项目开始的时候定义这个文件夹，将有助于确认是否坚持了这个策略。
警告：在一个探索中产生的软件绝不能简单地粘贴到产品代码中，相反，它必须使用团队采用的产品标准和做法完全进行重写。（例如，结对编程、首先测试编程，等等。）
Visual Studio 解决方案、项目和目录的组织（Organization of Visual Studio Solutions, Projects, and Directories）
一个团队项目通常与一个或多个Visual Studio的解决方案有关，每个解决方案都包含一个独立的Visual Studio项目集合。你的团队应该采用一个标准的目录架构，用于存储这些解决方案和项目，因为这样可以鼓励人们正确地放置文件，别人也可以更容易地找到这些文件。例如，OSPACS团队有两个Visual Studio解决方案：一个是其图片管理产品osImageManager，另一个是其网站产品ospacsWeb。
因此，开发团队可能决定整理这些文件和目录，在其存储库中的$/OSPACS/Production文件夹下以如下结构创建osImageManager解决方案：
osImageManager——包含开发团队须要共享的Visual Studio解决方案文件。
– Db——包含数据库脚本、重构产品数据库、运行查询等；
– Documents——包含开发团队的文档，如须要添加到TFVC版本控制中的发布产品所需的注释，而不是将其放到SharePoint的文档库中；
– Help——包含所需产品的帮助文件（*.chm）；
– Install——包含所需的安装程序；
– Libs——包含采用的第三方类库；
– Src——属于这个解决方案的各种Visual Studio项目的根目录，并且可以在一起生成（生成|生成解决方案）；
– osImageManagerApp——Windows Forms 应用，提供图形化用户界面的启动项目；
– osImageManagerLib——包含大多数代码的类库；
– osImageManagerUT——包含osImageManagerLib 类库的单元测试的测试项目（请见第5篇的第12章）；
– osImageManagerCT——包含osImageManagerLib 类库的一般测试的测试项目（请见第24章）；
– osImageManagerFIT——包含用于osImageManager的框架集成测试（FIT）的类库（请见第22章）；
– Utils——各种各样的脚本、分支文件和开发所需的信息。
提醒：只有当你有多个Visual Studio 项目组成的一个集合并且希望其作为一个单元生成的时候，才会考虑创建另一个Visual Studio 解决方案。同一解决方案中的项目将在一起生成。
练习8-2：添加一个Visual Studio解决方案到一个目录结构中
在这个练习中，你将作为Peter在开发PC2中使用一些目录，然后创建一个空的Visual Studio解决方案“osImageManager”。采用这种方式，在Peter的工作区目录和存储库中的对应文件夹之间映射这些文件。
使用窗口资源管理器（或类似的东西）在开发PC2中的Peter的目录下创建图8-1中所示的目录。在每个目录中，创建一个index.txt文件，这样你就可以将目录的用途文档化了。
为osImageManager产品创建一个空的Visual Studio解决方案：
（1）从菜单条上选择“文件|项目”打开新建项目对话框；
（2）在其他项目类型节点中选择“Visual Studio解决方案”，然后选择“空解决方案”；
（3）命名解决方案为“osImageManager”，然后点击浏览按钮，选择练习8-1中第4步创建的C:\Peter\OSPACS\Production目录，选择“添加到源代码控制”，然后点击“确定”；
（4）当添加解决方案到源代码控制对话框出现的时候，选择你在练习8-1中创建的Production文件夹，但是放弃“osImageManager”作为解决方案文件夹的名字，点击“确定”，添加你的空Visual Studio解决方案到版本控制中。
http://images.cnblogs.com/cnblogs_com/bvbook/157720/r_%e5%9b%be8-1.jpg
图8-1工作区目录和存储库文件夹之间的映射
警告：记住，放入版本控制中，并不只是将源代码用于软件产品的生成，而且文件须要创建其与公共软件和工具之间的联系，以及用于数据集成和数据库定义的脚本。
决定放什么到版本控制中（Deciding What to Put into Version Control）
一旦你添加了一个解决方案或项目到版本控制中，大多数有关存入哪些内容的问题就由你决定。例如，当你创建了一个新的类，Visual Studio将会自动添加相关文件到版本控制。但一般情况下你不想给团队其余成员共享的自己工作区中的文件自动排除在这个过程之外；例如，你个人的集成开发环境（IDE）的设置文件（.suo）、可执行文件（.exe、.dll）和各种产品生成文件。
提醒：使用添加到源代码控制对话框（文件|源代码控制|添加到源代码控制）来改变排除在版本控制之外的文件的类型。很显然，要编辑属于你的解决方案（.vssscc）或项目（.vspscc）的“hint”文件。
决定放什么到版本控制中，是开发人员常争论的问题。一方面来说，大型项目经常会争论，项目中的每一个文件，包括所有的开发工具，都应该放到版本控制中。从另一方面来说，这需要敏捷编程实践和测试实践。
编程和测试实践
敏捷项目团队集中力量在那些能够驱动开发向前的事情上，也就是说，对于可执行的测试，我们称“什么”必须要执行，而对于源代码我们称“如何”满足这些需求。编程和测试实践将这些测试和源代码作为你的项目的主要成果，并且在可能的时候，使用它们自动生成需要的其他的文件和文档。这样，你要避免不必要的信息塞满你的存储库，这些信息混淆视听，是潜在的错误源。
开发项目倾向于产生纸面工作，经常，项目越大，产生越多的纸面文件。编程和测试实践是一个官僚主义的解毒剂，这些官僚经常在你试图用文档驱动项目的时候冒出来。问题在于软件开发是一个探索的过程，因此文档很快就变得过时了，如需求变革、模型改进、计划变化等。因此，在项目的进程中，你花费越来越多的时间保留文档，则留给重要的资源如生产代码和测试的时间就越来越少。编程和测试实践通过减少项目对文档的依赖来解决这个问题，只保留必需的文档。
编程和测试实践要求你仔细观察项目中发生的每件事，由此决定哪件事情实际增加了客户的价值。编程和测试的文件的确非常重要，因为如果没有它们，你就无法交付产品给你的客户。但是类图怎么办呢？如果你没有类图放到存储库中，客户会注意到吗？你可以从存储库中删除哪些文件，因为一旦代码和测试文件已经生成，相关的文件就是多余的了？你可以从存储库中删除哪些文件，因为它们可以从你的主要成果中简单地逆向生成？以这种方式工作，一点点地移除超重的包袱，这些包袱降低了你的客户的流动价值，并且使你执行不必要的维护来浪费资源。
注：编程和测试实践不能阻止你创建需要的文档和模型，但它们在完成对目标的服务之后，须要被删除。
版本控制团队文档（Version Control for Team Documents）
与你的团队项目有关的文档，如其版本状态，都通常位于你的项目门户中，请见团队资源浏览器中所列的文档文件夹。这样，人们就可以使用Windows Share-Point Services (WSS)和Microsoft Office 应用程序，在他们的浏览器里产生、编辑并复查这些材料了。
提醒：使用WSS版本控制来帮助你的团队共享存储在其项目门户中的文档。通过在文档库的一个页面中建立一个独立的文档，然后从相关的下拉列表框中选择签出（或签入）。
不幸的是，在WSS中的文档实际上并不存储在TFVC存储库中，虽然在将来某个版本可能会改过来，因此，使你的项目门户实现控制团队文档变更的目标意味着你最终将管理两个完全独立的版本控制系统。这样，你不可能对所有的项目成果简单地通过应用标签到TFVC存储库中来建立基线，因为标签不能用于存储在你的团队的WSS文件库中的文档。事实上，WSS甚至不支持在其整个文件存储内容中应用标签的概念，因此你必须人工地为每个文件（也就是说，签出文件，然后在再次签入的时候将你的标签作为注释填写）完成这样的工作。正因如此，我们建议你只在没有团队资源浏览器的人要访问这些文件的时候，才将这些项目成果放到SharePoint文档库中。你还应该把所有的东西都放到Visual Studio解决方案相对应的文件夹下，这样他们就可以存储在TFVC的合适的版本控制下了。
一个敏捷团队不应该产生大量的团队文档，但是有些文档是产品交付的部分，或是与其架构不可分割的，因此你可能要考虑将以下类型的文档放到Visual Studio解决方案的文档文件夹中。
[*]授权——你应该从未分发过任何没有定义某些授权形式的软件，这将保护你的知识产权并且说明你的工作方面的义务。授权文件和可执行文件一样作为可交付的一部分。[*]发布说明——当安装软件的时候，人们通常希望知道一些相关信息，例如，其目标环境、限制、新功能等。将发布说明放到程序安装目录的根目录下的一个名为readme.txt文件中是个很好的做法。[*]版本状态——这里介绍程序的目标，包含了什么，谁可以使用它，已经带来哪些好处。有个很好的主意，即提供一个可扩展的链接，将这个文档的类型与产品的帮助系统、安装程序或Web页中的下载链接在一起。[*]生成注释——你应该保留一个不断更新的工具和你的开发环境设置的列表，应特别关注像版本号和许可条款这类细节，请见第7章的软件配置管理那一节。将这类文件放到TFVC存储库中，你就可以用一个标签将你的开发环境的文档和指定的版本的代码链接起来。提醒：你可以在Visual Studio 解决方案的文档文件夹中创建一个文件，手工输入所有存储在你的团队项目门户中的文件的名字和版本历史，从而将用于TFVC的标签和存储在WSS中的文档链接起来。
第三方库类归档（Archiving Third-Party Libraries）
即使最简单的.NET程序也需要公用语言运行时（CLR）类库，因此管理第三方类库的问题是每个团队都须要解决的事情。总之，你的选择如下。
[*]类库与你的产品分开安装——让第三方管理在各种软件环境中安装这些类库，以及开发任务、生成、测试、产品等问题。在这种情况下，你只要简单地添加一小节内容到你的生成注释中，介绍在哪里采用了第三方类库，以及其安装介绍。你还须要将这个库的安装作为产品的发布声明中的先决条件，就像操作系统那样。通常在磁盘上或网络驱动上保持这些第三方类库的类型，这比试图将它们存储在版本控制系统中要好。[*]与你的产品一起安装——将类库的可重新分布的程序添加到产品的安装程序中，但是让第三方供应商支持生成它们。你应该添加一小节内容到你的生成注释中，描述这个类库，即它的出处、版本、名字和它的可重新分布的文件的位置等。你可能还须要添加一小节内容到你的发布说明中，描述其许可条款、版本注意事项等。我们建议添加这类类库到版本控制系统，将它们加到解决方案的库目录中。这样，你就可以时常重新生成一个产品的特殊版本，并且确保第三方类库的正确版本被包含在其安装程序中。[*]与你的产品分开生成类库——让第三方供应商支持用他们的源码生成可重新分布的程序，但这在一个独立的团队项目中可以这么做。然后你要添加可重新分布的程序到产品的安装程序中（像先前描述的那样）。实际上，你要考虑类库开发者的规则或与组织中的其余团队一起完成这个工作。按照不同的发布周期，适应第三方类库比只顾自己的团队项目更行之有效。[*]与你的产品一起集成类库——将第三方类库的源代码放到与你的团队项目有关的一个Visual Studio项目中，这样就可以作为代码的一部分进入相同的发布周期了。只有在产品的生命周期内扩展适应第三方代码的时候，才应该考虑采用这种做法，因为管理第三方类库经常由于供应商提供定期更新和修补程序，而使得同步你的类库代码的版本很困难。注：在Windows环境中使用第三方类库（.dll）可能充满挑战，因为管理相同类库的不同版本是非常困难的，尤其是在它们被不同的应用程序共同使用的时候。Don Box将其描述成臭名昭著的DLL地狱。 :shock: 支持一下，很不错
signature---------------------------------------------------------------
斗罗大陆 九顶记 斗破苍穹
页:
[1]