基于Visual Studio的软件生命周期管理和持续交付 (二) 采用成熟度
visual studio是微软系开发人员最常用的开发工具,但是它不仅仅是开发工具;VS就像是浮在水面上的冰,下面还藏着很多好东西;
从采用成熟度来分,从低到高有以下几种方式: (本文只描述了一部分的优势和劣势，而且只代表个人观点）
（并不是用的越多越好，选择适合你的）
1.只用Visual Studio
只使用visual studio作为开发工具(只是开发工具哦) 在一个人做开发的情况特别常见， 偶尔在非常不正规的软件作坊中也会见到
不可否认,VS是一个非常有生产力的工具
备注：Visual Studio有很多很强的插件，例如说增加开发效率的resharper
2.引入TFS 作为源代码管理器
大部分公司都引入了源代码服务器,只是用的方案不一样,有的用SVN有的用TFS或者是别的什么
相比于其他源码管理工具,TFS和Visual Studio的集成是最为紧密的，而且和接下来要谈到的很多微软系的软件也是集成非常紧密的。
作为微软的软件，升级和维护，还有搜索资料一般也都来的方便。
单纯作为源码管理软件而言，我个人觉得TFS的性能还是挺不错，功能方面比其他的源码强很多 （当然 这是因为TFS它不仅仅是一个源码管理软件。。。）
常用功能使用也很方便，个人印象比较深的是TFS的自动合并还是挺好用的
3.引入TFS作为开发标准和软件生命周期管理
3.1使用TFS Build Service作为编译和每日构建
这是我个人很喜欢的一个功能，这东西是现在很流行的“持续交付”/“持续集成”的一个实现
通过配置TFS Build Service，我们可以设置每次签入代码前后的动作，包括但不仅限于：
- 不允许签入无法编译通过的代码
- 每次签入的时候自动执行编译和测试，如果有问题就发邮件给相关人员
- 每天执行一次完整的编译和完整测试，如果有问题就发邮件或者通过其他方式给别人给相关人员
- 每次有代码改变的时候自动分析并执行需要测试。
这样能较好的保证，源代码库中的代码是可用的，也可以避免团队其他程序获取最新版本以后无法编译通过的问题；我个人已经无数次遇到过，从源码服务器上直接拉下来的代码是不能跑的，要找原作者过来帮忙配置环境，修改引用什么的
（想象一下，你早上来获取最新版本的代码以后，编译报错，而这又是别人的代码。。。他又正好请假了。。。这真是纠结的事情啊。。如果团队里面有很多人。。。那这种事情发生的概率就很高了）
3.2使用VS作为测试工具 (单元测试,自动化测试等..)
你们做测试了吗？在敏捷开发中，开发人员和测试人员的界限已经较为模糊了，很多测试都是由开发人员完成的。
即使是在传统的软件开发流程中，开发人员自己开发出来的东西自己总要试试吧～
单元测试的优势和劣势，已经有很多文档描述了，这里就不废话了
VS中内置的单元测试工具，第一点的优势就是内置，这样别人获取你的代码以后不需要额外的环境和引用就可以直接执行了
其次，作为mstest.exe兼容的测试，他与微软的Test Manager 等配套软件集成的很好，而且也可以很方便的放在3.1的过程中执行
功能方面。。。一般般吧。。。。
对了Coded UI还算是一个不错的可以做end-to-end的测试，可以较好的模拟用户的行为，并且支持的平台也比较多
备注：Pex是VS的一个插件 可以很方便的自动测试和生成测试代码
3.3使用VS和相关插件作为开发标准
Visual Studio本身就有一些代码规范检查标准， 同时我们还可以通过FxCop等扩展出一些自己的标准来，这样，我们可以通过自动化的代码检查来规范代码，提高代码质量
其次，在TFS中签入代码的时候可以制定规则，只允许符合规范的代码签入，可以实现强制标准
3.4使用VS管理软件生命周期
TFS内置了 Task， Test Case， Bug还有开发流程规范等东西，基本上可以覆盖中小型软件公司９０％的需求了。。。
当然，用不用，怎么用，用到什么程度，需要结合公司情况考虑一下
对了 这东西有基于Sharepoint的web版本，没有安装VS也是可以使用的。
这东西用好了对软件生命周期的进度和控制能力会有所改进
3.5报表
基于SQL Server Reporing service的报表功能，可以很紧密的和Visual Studio, Sharepoint 还有Excel Project等软件结合起来
作为管理层，往往比较关心报表
4.使用Test Manager进行测试
在很多公司，测试都不怎么受重视。。。唉。。。也间接说明了在这些企业对于软件质量要求并不高。。
不管怎么说，测试还是保证软件质量的重要环节
Test Manager和TFS集成在一起，允许你建立测试计划，Test Suite，并且关联到Test Case。
并且，之前我们做的单元测试，或者是任何一种mstest.exe兼容的测试代码，都可以关联到Test Case，这样就拥有了自动化执行一系列测试的可能
对了，在Visual Studio中本身也是有Test explorer的，不过没有集成测试计划管理和配置功能，只能本地测试下
5.lab environment
想象一个场景：开发了一个web应用，自然的我想在IE 789，chrome等浏览器下测试一遍，那么你会怎么做呢？
原始的做法是:在不同的机器上开不同的浏览器各测试一次。。。。
现在的做法是: 写一段测试代码，然后告诉Test Manager，我要运行在环境ABC上。 然后等一会儿来看各个环境的测试结果
在这一套方案中：
Hyper-V 实现了虚拟机的功能
System Center Virtual Machine Manager 实现了虚拟机的模板和管理功能
Lab Manager 将测试计划和TFS和虚拟机关联起来，
那么当你通过Test Manager 执行一次测试的时候， 就可以选择一个测试环境，从而将测试计划到远程机器上执行
最终的测试数据和信息将保持到TFS中，作为以后查看和报表的工具
自动化测试有如下优势：
- 测试成本低 （开发成本可能较高）
- 可以很频繁的执行
- 执行时间可以很短
- 减少人工操作（人工操作比较容易犯错）
- 可以很方便的在多个环境中执行测试
- 知识积累（对于有开发能力的人来说，有的时候代码比文档更容易看懂；并且不会像人工一样忘记测试某个功能，自动化测试可以在软件的每个版本中都完全的执行，）
最后回顾一下架构图
