公司内推广svn总结

       最早接触到SVN还是去年5.1黄金周了，黄金周头两天北京到处是人只好家里呆着，上网乱逛的时候突然看到有位兄弟的blog的文章中提到svn已经能够比较稳定的使用了，我终于踏上SVN之路。实际上，那位兄弟的blog中介绍版本管理的文章在更早的时间就看过，只是那时候他说SVN还没有达到一个稳定状态我就没敢去尝试。
         当时项目组里进行版本管理的工具是CVS，更早使用的是VSS。但是vss的并行开发功能实在不敢恭维，项目经理从公司另外一个部门的同事那里搞来了CVS开始在项目组内推广，因为CVSNT客户端用起来不够方便，CVS基本上就是个摆设，开发团队对CVS有强烈的抵触情绪——也包括我，因此版本管理的工作实际上并没有真正做起来。后来发现一个有个同事的机器上装了三四种CVS的客户端，其中有TortoiseCVS，我觉用起来很方便，但是他说经常会出现一些小毛病，我没在意他说问题就直接装上去把CVSNT替换了。TortoiseCVS集成在右键菜单里，而且本地工作副本有特别的图标个标示，原来对CVS的抵触情绪一下就没有了，也开安始主动地研究CVS的版本控制功能，接下来成功的劝说剩下的几个团队成员开始使用TortoiseCVS，就连原来最倔的那个同事也转变了想法开始正常的使用CVS版本控制系统了。
         现在再回顾这段经历，让我深深地体会到了推广版本控制系统时选择一个简单、实用的工具是版本管理工作的基础。
         知道SVN达到稳定版本的消息，在黄金周结束的第一天我就开始了SVN的“忽悠”工作（经过我不懈的忽悠工作，部门里的开发人员80%的都采纳了我所推荐的辅助开发工具）。版本管理是个至上而下型的工作，于是我向项目经理开始推广，但因为没有现成的经验他没敢立即更换到SVN。正巧这时候我和另外一个团队中的同事要独立开发一个子系统，于是把他拉上进行SVN的实验（实际上他是被我逼迫使用的），试验的结果使他也觉得SVN比CVS更好。接下来的推广就很容易了，加上期间CVS的版本回溯出现了一次比较严重的问题，造成了比较大的损失，SVN很快就成为了项目组的专用版本管理工具。

      项目组使用了几个月后积累了一些使用经验，自认为对SVN比较熟悉了，于是开始向其他项目进行推广。刚开始，频繁的向各个项目组经理推荐SVN，向他们介绍SVN的好处，并跟他们展示本项目使用的情况，这样推荐了一段时间后发现大家虽然对SVN比较满意，也觉得上SVN有必要，但是就是没人实际的使用，看来是需要动用上层的力量了。这时候自己也已经成为一个项目负责人了，需要经常直接跟部门领导接触了，于是开始向部门领导开始推荐SVN。向本部门领导和技术质量部领导（负责整个公司软件产品质量工作）推荐的策略就得改一改了,   着重强调版本管理的重要性、版本管理工具统一的必要性 、SVN系统的实用性和低成本性。同时在公司论坛和部门展板（有点像上学时教室后面的板报）上写文章开始推介SVN。很快，版本管理成为了公司层面的一个工作。
        公司还找来汉星公司的人员来介绍汉星的产品。汉星的产品确实不错，但是价格过于高昂，而且汉星产品有一些自己独创的概念（实际上都是开源软件中的功能，只不过那些开源软件不够知名）跟流行的版本控制工具有些差别，我不是很喜欢，尤其是汉星的那个所谓营销总监王婆卖瓜式的宣传方式让我无法接受，我问他汉星与SVN、VSS8.0 、Team Foundation 相比有什么优势时，他竟然一无所知。这样公司的版本管理工具选型工作实际上已经成为了汉星与SVN的较量，对于汉星公司内没有人是专家也没有实际的使用经验，而SVN有一个项目组的成功经验和一个推广人，加上公司正好开始“开源节流”运动，汉星产品对比SVN没有大的功能优势，最终汉星暂时出局了。汉星是个不错产品，如果能真正发挥它的作用对公司的软件开发工作肯定有很大的促进作用，但是在目前绝大多数项目团队没有足够的版本管理思想的基础上就仓促上数十万元的软件过于冒险，于是我对公司的建议是先用低成本的开源软件培养大家的版本管理思想和习惯，然后决定是否上商用（汉星）软件。不过有句话说得好“上贼船容易下贼船难”，商用软件是否还有必要考虑本身可能就是个问题了。
        版本管理工具选型工作结束后，首先在本部门内推广SVN系统。做为SVN推广公司的源头，我和原来的那位项目经理一起制定部门版本管理的规则和方案，为此专门组织了几次部门级的培训由我来为大家讲解SVN系统的使用。这算是SVN推广工作的一个里程碑性质的胜利。

         在本部门运行了半年之后，SVN 系统再次成功占领了两个部门。
        因为老乡的关系跟技术质量部的一个MM比较熟悉，而她的工作正好需要使用版本控制软件，于是SVN系统成了不二选择，加上之前就向技术质量部领导推荐过SVN系统，这样SVN成功占领了技术质量部。
       软件产品部门（我自己所属的部门主要是做项目的）的产品需要经过技术质量部的测试，于是产品部有一次开始接触SVN。在此之前产品部就上过SVN系统，但是当时没有大规模使用仅仅用来管理一些文档，而且当时使用的那个同事后来辞职了，SVN的使用就此中止。这次产品部门重新接触SVN已经转变成为自发的行为，认识到了SV的必要性。推广相对来说就容易多了，利用国庆黄金周的时间我整理出了一份针对产品部开发工作的SVN系统培训材料（整理过程中自己也把平时不常用的功能学习了一下），接着节后又进行了一次较大规模的推广培训讲座，就这样SVN系统的又占领了一个部门。
 
        经过一年的推广，目前SVN系统已经占领了四个技术部门中的三个（剩下的一个业务比较特别无法做到部门级的统一管理），绝大多数的技术人员已经能够理解版本管理的思想和熟练使用SVN辅助日常的开发工作，自己也深感欣慰，这也是工作五六年来自认为最大的成功。

       总结SVN的推广历程有下面几点值得推荐给大家：
  1.版本管理是个至上而下型的工作，尽量多的依靠官方的力量进行推广；
  2.版本管理的工作选型要特别注意工具的易用型；
  3.版本管理要渐进式的推广，即先要培养出一个试验团队和专家，然后依据这个成功团队的经验扩大规模；
  4.及时总结经验，制定出针对开发流程的版本管理方案。