tfs的使用心得(精选).docxVIP

TFS 使用心得--权限管理 ??? 最近一段时间负责管理公司技术人员的TFS的权限分配，在此之前，我对tfs一点都不了解，没用过，也没听朋友用过，只在进公司时指导我的组长帮我把这个工具装上，告知要在上面报bug，即bug管理在上面，之后的很长一段时间就只知道tfs可以管理bug，可以管理文档，可以管理源代码，这点是从我负责HYPERLINK javascript:; \t _self测试的那个项目下的文件夹中看到的，至于怎么来管理，其中有多复杂，没有太多的了解。 ????指导两个月前，接手tfs权限管理HYPERLINK javascript:; \t _self工作以来，才知道里面有多复杂，经理只告诉我怎么分配项目成员的项目权限， HYPERLINK javascript:; \t _self 其他的都不知道，起初还以为这样就万事大吉了，呵呵，原来那些只是皮毛，里面的权限还十分的复杂，这是在我两个月来的管理中琢磨出来的，凭现在对tfs权限管理的了解，基本可以应对公司员工的tfs权限的分配。 ??? 说tfs权限的复杂，其实也不是很复杂，它只是把各部分的权限分开控制，但各部分的权限又可以相互继承，分的多了，操作起来就容易出现问题，关联的多了，更容易出现问题，继而形成了它的复杂度。 ????下面来分享一下我的使用心得，我还是刚入手，了解的一点点，拿来汇总一下，以便今后的工作和HYPERLINK javascript:; \t _self学习，有帮助的可以看看。 ????tfs的权限分不同的级别，不同级别的权限其安全性不同，这点帮助文档中部分信息十分完备： ???? 权限决定了是否授权用户进行工作区管理和项目创建等操作。当在 Team Foundation Server 中创建项目时，无论选择哪种过程模板，都会为该项目创建四个默认组。默认情况下，为这些组各自定义了一组权限，这些权限决定了组成员可以执行的操作。 Project Administrator Contributor Reader Build Services 要管理默认组并创建自定义组，管理员必须了解权限的含义以及显式设置权限引起的安全问题。 注意：本主题不讨论  HYPERLINK javascript:; \t _self Windows SharePoint Services 或  HYPERLINK javascript:; \t _self SQL Reporting Services 的权限。本主题只讨论在 Team Foundation Server 中设置的权限。权限设置 Team Foundation Server 中的权限有两种显式授权设置：“拒绝”和“允许”。还有一种隐式授权，它既不将权限设置为“允许”，也不将其设置为“拒绝”。此授权是一种隐式“拒绝”设置，又称为“未设置”。 拒绝 “拒绝”不允许授权用户或组执行权限说明中提到的操作。“拒绝”是 Team Foundation Server 中最强大的权限设置。如果用户所属的 Team Foundation Server 组将特定权限设置为“拒绝”，那么即使用户所属的另一个组将该权限设置为“允许”，该用户仍无法执行该功能。此规则的唯一例外是用户属于项目的“Project Administrators”组的成员或者属于“Team Foundation Administrators”组的成员的情况。如果用户是项目的 Project Administrators 同样，如果用户是 Team Foundation“Administrators”组的成员，则该组的特权将覆盖该用户在 Team Foundation Server 中的显式“拒绝”。 允许 “允许”则允许授权用户或组执行权限说明中提到的操作。“允许”是 Team Foundation Server 中第二强大的权限设置。它也是设置最频繁的权限设置。如果不将权限显式设置为“允许”，用户或组将不能在 Team Foundation Server 中执行该操作。 未设置 默认情况下，Team Foundation Server 中的多数权限既没有设置为“拒绝”，也没有设置为“允许”。权限处于“未设置”状态，它隐式拒绝授权用户和组执行权限说明中指定的操作。但是，因为权限既没有显式设置为“拒绝”，也没有显式设置为“允许”，它可以从用户或组所属的其他组继承授权。 继承 当用户或组的权限为“未设置”时，因为 Team Foundation Server 中的权限是可继承的，所以用户或组可能受到其所属组权限的显式设置的影响。例如，如果一个用户属于某一项目中的两个自定义组，其中一个组将权限显式设置为“拒绝”，另一个组将