浅谈软件项目及流程管理

敏捷，自动化，持续交付。。。都是时下软件行业的热门词。我们就从头开始说起吧。

源代码，版本库
  软件开发，所谓的头，当然是源代码，无源代码则无软件。借用大牛Linus的一句话“show me the f**king source codes!  ”
  OK，既然有了源代码，我们就要管理这些源代码。随着软件规模的逐渐增大，源代码也变得越来越庞大越来越臃肿。而且因为业务的需求，同一个产品往往会有好几个版本同时推进。于是乎，管理好源代码就显得更加重要了。幸好，我们有很多版本库工具可以用，早期大名鼎鼎的CVS，小公司经常用的盗版VSS，现如今风风火火的SVN和linus大牛亲自操刀的GIT，亦或是名不见经传的HG，再或者是高富帅专属的ClearCase。。。总之我们有很多的版本库工具可以用（PS：以上提到的6种楼猪都用过，在一家公司里用过其中的3种，在另一家公司里用过剩下的3种，可谓眼花缭乱  ）。
  作为一名码农，最主要的工作当然就是搬砖，砖往哪搬？当然是工地（版本库，repository）啊。从版本库下载代码那叫check out，更新代码那叫update，提交代码那叫commit（check in）。
 

  当然，有了源代码后还要做好版本管理，对于每一次提交都给一个唯一的版本号（git是没有全局版本号的），如果发现刚刚提交的代码有问题，也可以回退到之前的某个版本（revision）。按照敏捷的原则，每一次的代码提交都要保证能生出一个可运行的软件，所以每次commit都应该是纯洁有效的，这也是软件持续交付的理论基础。正因为每一次的提交都是有效的并且可运行的，所以我们才能把每一次的提交都deliver出去，这就是持续交付。

软件构建
  有了源代码，就需要把源代码编译成可运行的软件，要用到编译器啦。无论是你在windows下开发还是linux下开发或者是要交叉编译，都需要编译器。但是我们在提交代码之前经常需要内部做一些测试，以确保无误再提交到版本库，所以就希望编译能尽可能快一点。电信行业的软件往往规模都不小，如果用自己的PC来编会很慢，所以啦就要想一些加速的办法，比如找个16core的服务器专门用来做编译，比如分布式编译。windows下可以用incredibuild,linux下可以用distcc，或者你要是高富帅的话可以向第三方厂商买BMW来加速，比如electric accelerator。

  对于那许许多多的源代码文件，总是让人感觉纷繁杂乱。如何管理这些源文件的结构和依赖关系？历史悠久且大名鼎鼎的make，大家肯定不会陌生。近年来，随着软件工程的发展，很多新的工具也被开发了出来，比如针对C语言的依赖管理工具scons, JAVA社区红得发紫的ant和maven。后者不但强大，而且可以很好的和开源社区很多工具进行集成，比如hudson/jenkins。

软件测试
  对于构建好的软件，我们当然要确保其功能和性能。这就需要对软件进行测试。测试种类也很多，从单元到模块到系统（UT MT ST），从功能到性能（functional test，performance test）。你可以搭好环境，然后人工进行测试，当然也可以利用计算机进行自动化测试。
  说起自动化测试，NSN有个业内很有名的工具--robot framework。开源软件，并且有很多公司在用，赞一下。robot的设计理念很不错，基于python开发（当然，也可以运行在JAVA虚拟机JVM上），case以关键字驱动，如果想要对该测试框架进行扩展也很方便，只要在python库里增加自己的库文件就行了。 此外，该框架除了能做功能测试之外也能做性能测试， 某全球最大的交互式网络会议厂商就在用该框架结合 Selenium 模拟测试多方视频会议。你也可以用该框架进行分布式并行测试，然后将测试结果合并，结合jenkins的multi-configuration job，做持续集成非常好用。


项目和流程--agile，scrum，CI
  好啦，有了源代码和构建工具，我们已经可以把软件做出来了；然后软件又经过了测试，应该可以交付出去了吧！
  嗯，是可以交付出去了，but这是上个世纪的软件项目流程，现在是21世纪了，新世纪当然有新世纪的方式。

  随着整个IT行业进入快鱼吃慢鱼的时代，软件项目的方式也随之改变了。大公司不再那么美好，瀑布也不再那么美妙。一夜之间，小而美成为了主角。所谓小，需求要细分，开发的粒度应该细分，一个开发周期不能太长；所谓美，“架构之美”，“测试之美”到处都是。

  为了应对新形势，人们提出了敏捷。所谓敏捷，就是要抛弃一口吃成个大胖子的观念，取而代之以少量多餐的方式，将软件项目的粒度细化，并且少量多次的持续交付。再说白一点，就是将一个大feature分割成若干个小feature，每次交付一个小feature，持续不断的交付，以便更好的控制质量和风险。 因此，项目组不能太大（我D不是经常说国家大了人多了不好管嘛），需求的定义和划分要清晰，开发效率要高，并且每一次的代码提交最好都要经过必要的测试以保证质量。


  前面我们已经说过， 按照敏捷的原则，每一次的代码提交都应该是有效的， 每一次的代码提交都要保证能诞生出一个稳定可运行的软件，因此，我们需要在每一次代码提交的时候（提交前和提交后）进行相应的测试以保证提交质量。
  因此，我们可以规定如下流程：代码提交前，各位码农要对自己写的代码进行单元测试，测试通过了才能提交。提交上去之后，随即对该次提交进行模块测试和系统测试，如果问题尽快通知提交者，越早发现问题则解决问题的成本越低。当然，现实中我们可能无法做到对每次提交都进行相应的测试，但是我们可以对每几次提交进行相应的测试，再或者至少每天都对该天的提交进行一次构建和测试，把风险降到最低。

 

  这样每天持续不断的对提交进行构建，我们称之为持续构建，也叫持续集成（ Continuous integration，CI ）；再然后源源不断地将构建成功的可用的软件交付出去，叫持续交付。显然，持续集成是持续交付的一个子集。持续构建最著名的框架，当属jenkins，以前叫hudson，和纽约哈德逊河同名，后来因为甲骨文注册了hudson商标，故而改名jenkins。该框架还有一堆的插件可以帮你做持续集成，从源代码到构建打包到测试，啥都能干。


  从软件的构建到测试，全都可以在持续集成的框架里自动化执行，包括测试环境的自动化配置，软件包的自动化更新等等。比如linux环境，可以构建yum repo进行软件包的自动安装和更新，并且利用puppet进行环境的自动化配置。


  关于敏捷，楼猪想说一句：敏捷是一种态度，敏捷怎么做，可以自己取舍，但是持续集成，你值得拥有！