为您的开发团队找个好管家

【已发表于《程序员》2006年第11期，全名《为您的开发团队找个好管家——Visual Studio 2005 Team Foundation Version Control解析》】

《大宅门》里有位胡总管，精明能干、平易近人又忠厚仁义，协助白二奶奶将白家上上下下打点得井井有条，连最不安分的白景琦也敬他三分。如果将百草厅看作是一个软件开发团队，将白二奶奶看作是这个团队的领导人，那么谁来当这个“胡管家”呢？换句话说，谁能保证真正做到毫无私心，刚正不阿又精明能干地帮助您管好开发团队这个“家”呢？

我想或许一下子会冒出许多候选人来竞争上岗，比如Visual SourceSafe V6.0、CVS、Subversion等等优秀的版本控制软件。而在我心目当中，已经有了一个更好的选择，那就是Visual Studio 2005 Team Foundation Version Control（TFVC）。

或许在过去，不少人对Visual SourceSafe V6.0的印象并不太好；或许不少人选用了其它的版本控制软件；甚至我曾经参加过一个团队，竟然没有用到任何版本控制……当然这一切已成为过去，时代的步伐总是在前进的，TFVC的推出，很大程度上改进了过去在版本控制上存在的缺陷和不足，使得开发团队可以更加紧密、高效地工作。

数据存储与安全级别

过去VSS采用文件系统作为后台数据存储，而TFVC则采用Microsoft SQL Server 2005。由此不难看出，TFVC具备更快更强的数据存储能力和更高更完善的安全级别，同时也更加可靠和容易升级。TFVC提供了一个安全系统，赋予您更加细致的文件操作权限。

安全级别	注释
读取	允许读取一项
签入	允许签入一项
标注	允许标注一项
锁定	允许锁定一项
修改其他用户的更改	用户可以修改注释、工作项集合或者关于尚未建立的装置的记录
解锁其他用户的更改	该用户可以解锁另一个用户锁定的项
撤销其他用户的更改	可以在一个有另一个用户签出的项上取消尚未决定的更改
管理标注	允许用户标注更感以及更改标注
操作安全设置	指定用户拥有更改项的安全性的许可
签入其他用户的更改	允许用户签入由其他用户签出的项

 

 

 

 

 

 

 

 

 

表1，Team Foundation Version Control提供的安全级别

TFVC不仅具备细致的安全级别，同时还包括完善的审核能力与报告能力，这些能力可以有效地节省使用者的时间。

通信结构

Team Foundation Version Control采用的通信结构是靠HTTP通过标准的Web服务来完成每一件事情。这就是的一个由分散在世界各地的开发小组所组成的开发团队也能够协同工作并且通过Internet访问中心知识库。为了更好地完成这项工作，Microsoft还建立了一个TFVC代理服务器在后台处理同步数据并且允许开发人员就近访问最新版本的代码。
通常来讲，一个中型或者大型的IT公司都具有数十甚至上百个大大小小的开发团队，这些开发团队不可能都挤在一栋大楼里面工作而是分布在各个地区的分公司里。而在过去，可能每一个团队都需要安装一套版本控制软件，并且建立和管理自己的知识库。因此从本质上讲，这依然是零散的。根据前面提到的TFVC在这方面的改进，就可以很好地改变以往的局面，它可以使得管理层能够对它的开发团队进行集中控制——不要怀疑它的能力，一套TFVC能够支持大约550名处于活动状态的开发人员以及按TB计算的数据，而它将此集中于一点并仅由一名管理员进行管理即可。

平台无关性

既然开发团队越来越大，使用的开发环境越来越多，那么平台的无关性也就显得至关重要了。集成开发环境与版本控制软件“能一起工作”和“能很好地一起工作”可以说是两个概念，而这二者之间的差别往往会弄得开发人员相当头疼。正如同样是赵五爷和秦二爷作伴，白景琦和白敬业的两次买药就完全是两种经历和结局。是什么导致的差别呢？兼容性应该占很大一部分。TFVC采用HTTP和Web服务作为通信媒介，也就有潜力提供很好的平台无关性。是的，TFVC的开发团队将这样的潜力发挥得很好，目前，一些开源或者闭源项目以及应用程序都能够很好地与Team Foundation Server集成在一起，这就意味着不管是什么平台，您都可以拥有一个公共的、易用的、企业级的版本控制系统。

易用性

既然拥有这么多令人心动的特性，那么易用性是否会变得很糟糕呢？一般来说，庞大的软件往往都显得比较专业，那么我就通过几个实际的操作来向您展示，TFVC其实像胡总管一样“平易近人”。

图1，签出代码

安全性加强了，提供了更为丰富的签出策略，但是在操作上并未增加多少步骤。这些策略可以在开发人员试图签入代码时提醒他们这样做违反了某些规定的策略。这些策略可以由管理员来定义并且包含如下的规则：
●    源代码必须被高级开发人员检查；
●    单元测试必须覆盖超过80%的代码；
●    没有与公共命名规范相违背；

更加高级的是，开发人员在签入代码的时候，可以将源代码与工作项相关联。代码在签入的同时会报告给Team Foundation Server，这时系统会生成关于跟踪Code Churn、Bugs的报告以及项目完成的进度。

您可以制定一个签入策略以确保签入版本控制系统的每一项代码文件都可以与一个具体的工作项相关联。这样做的好处在于使得项目经理、架构师以及其他一些参与者都可以通过报告来了解项目的进展程度，即使这个项目是由分布在不同地区的多个小组共同来完成的。


图2，签入代码

要将签入项与工作项相关联，您可以先选择一个您想要签入的文件，然后点击“Work Items”按钮来选择需要关联的工作项（见图3），


图3，选择与签入项关联的工作项

通过关联签入项与代码项，可以使得项目的进度能够得到更紧密地跟踪，并且这也使得开发人员可以更加容易地找到对应于系统某个特定的功能的代码。

当然，您也可能会同时将多个工作项关联到一个特定的签入项上。事实上在很多情况下您可能将一个代码文件或者一个架构图关联到3、4个或者更多不同的工作项上。比如说，您的代码是用来解决某个被查出的bug的，因此它就需要被关联到关于bug的这个工作项上。另外，代码也可能是跟应用程序的某个特性有关，或者是服务质量需求等等，因此它需要被关联到不同的工作项上去。最后您完成了由Team Foundation Build自动生成的bug修复任务，因此您需要将您的签入项与该工作项进行关联以报告该任务已纪完成。

另外，我们在项目开发过程中常常会遇到一些暂时无法解决的问题，有些可能会推到下一个版本去实现，有些则只是需要等待其它工作完成之后即可实现，无论情况怎样，我们都不能将这些需要暂缓解决的任务弃之不管。那么在TFVC中是如何来搁置（Shelve）和取消搁置这些任务的呢？

如果您需要搁置您的代码，您只需要在版本控制资源浏览器窗口中选中它并且点击“Shelve”按钮，然后给搁置的代码提供一个搁置器的名称以便于将来取消它的搁置状态。完成这些之后您就已经将您的代码搁置起来了。


图4，版本控制资源浏览器

如果您需要取消代码的搁置状态，仅需要点击“Unshelve”按钮并且选择您想要取消搁置的搁置器即可。


图5，取消代码搁置

当您在取消代码搁置的时候可能会与本地修改过的代码引起冲突，因为被搁置的代码并不限制您直接编辑被搁置的文件（这是的您可以搁置同样代码的多个版本）。当这种情况发生时，您将被告知引起了冲突并且面对解决冲突的选项。


图6，解决冲突

搁置和取消搁置开创了一些新的开发代码的可能性。如果用户不知道该选择哪一种用户界面，这是开发人员就能够提出多个不同版本的窗口或者页面，每一个都具有不同的外观和用户体验。每一个版本都能够单独地被搁置起来，当面对用户的时候，这些版本能够一次取消搁置状态并且展示出来。

搁置的另一个用途是当您正在开发一个新的特性时解决一个必须要修复的bug。有了搁置机制，您正在开发的特性可以直接被搁置起来，将您的代码停留在开发这项新特性之前的状，然后回头转来修复那个bug。当这个bug被解决掉后，再把取消代码的搁置状态然后继续开发。

这样看来，代码搁置的机制甚至可以被看作是一个救生员。因为关于新特性的代码实际上并没有完成也不能通过签入策略，但是您却可以将它放在一边开始另外的工作，甚至也可以将搁置的代码发给别的开发人员去检查，从而腾出手来专心去修复急待解决的bug。

总结

Team Foundation Server和Team Foundation Version Control提供了很多利大于弊的新特性，合理地利用这些特性，将会给您的项目开发工作带来很多便捷与高效，同时也可以提升项目的管理质量，降低失败的风险。

当然，Team Foundation Version Control并不是万能的，我在这里仅仅是为您引荐一位精明能干的新管家，希望能助您一臂之力！