关闭

浅谈软件项目及流程管理

387人阅读 评论(0) 收藏 举报
分类:
敏捷,自动化,持续交付。。。都是时下软件行业的热门词。我们就从头开始说起吧。

源代码,版本库
  软件开发,所谓的头,当然是源代码,无源代码则无软件。借用大牛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)。
repo.png 

  当然,有了源代码后还要做好版本管理,对于每一次提交都给一个唯一的版本号(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不是经常说国家大了人多了不好管嘛),需求的定义和划分要清晰,开发效率要高,并且每一次的代码提交最好都要经过必要的测试以保证质量。


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

process.png 

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


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


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

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:56274次
    • 积分:764
    • 等级:
    • 排名:千里之外
    • 原创:4篇
    • 转载:108篇
    • 译文:0篇
    • 评论:2条
    文章分类
    最新评论