|
大型复杂软件产品持续集成的实践与反思持续集成作为一种敏捷软件开发实践,已经被越来越多的开发者所接受。持续集成倡导开发团队频繁地进行系统集成。 持续集成作为一种敏捷软件开发实践,已经被越来越多的开发者所接受。持续集成倡导开发团队频繁地进行系统集成——通常一天一次到数次,每次集成都能被自动编译和测试验证,从而能在最短的时间内发现问题,缩短开发周期,提高软件质量。 笔者面对的是具有十多年开发维护历史,的5个相互依赖产品,每个产品均超过百万行代码的复杂系统。集成本身涉及很多烦琐的手工操作,很难实现过程自动化。在实施过程中,受困于软件系统的历史遗留问题,而通常市面上的持续集成工具又不能满足系统的需求,让我们不得不着手开发自己的集成系统。经过近一年的持续努力,终于完成了系统集成的自动化,将集成频度从数周甚至数月集成提高到日集成,大大提高了生产效率。 集成的困境 OSS系统是我们一个具有十多年生命历程的复杂系统,多年来一直处于不断的开发和维护中,子产品的数目和系统的代码量也随着时间日益增长,集成的周期、发布周期也随之逐渐增长。OSS系统包含有5个需要集成的产品:ComLIB 、DB-Com、Data Broker、DataGen、DataAgent,每个产品均有上百万行源代码和庞大的测试用例,产品可以单独构建,但运行时有相互依赖关系。OSS产品栈如图1所示,上层产品对下层产品具有依赖,部分产品栈亦可以组成一个应用系统,如DataGen+CommonLib可以组成一个应用系统,DataBroker+ DBCom+CommonLib也可以组成一个应用系统。
图1 OSS产品栈 同时,OSS的每个产品又包含不同的发布单元,用于运行于不同功能服务器上:Control Server、SITE、PAP、Workstation、Application Server和不同的操作系统环境中,产品在不同的服务器上安装单元如表1所示。 表1 OSS产品在不同服务器上的安装单元
传统手工集成需要完成如下事情: 1.从代码库取出产品栈中每个产品需要集成的代码; 2.在Build server上对每个产品进行编译,单元测试(每个产品编译需要2~3小时,单元测试需要4~5小时); 3.在Package server上对编译好的产品进行打包(每个产品打包需要约1小时); 4.在Lab中卸载旧的产品; 5.在不同的服务器上(Control Server、Site、Workstation、APP Server)安装产品中相应的产品的相应部件,需要按照产品依赖关系进行安装 (2~3小时); 6.检查每个产品的每个部件在Lab环境中的安装情况,确认安装成功; 7.运行功能测试脚本做回归测试(10~12小时); 8.检查测试结果(3小时); 9.对系统进行卸载测试,检查卸载结果 (1~2小时)。 如果在此过程中,一旦遇到问题,则需要花费更长的时间。如此昂贵的集成代价使得OSS系统通常数周甚至更长的时间才艰难地进行一次集成。而自动化还要解决多产品、多平台、多种安装和运行环境、多个操作需要人工干预的难题。 集成目标 持续集成需与自动化结合才能发挥其威力,为给OSS系统瘦身,我们设定了如下自动化持续集成目标: 1.在集成服务器上配置cron job,每天晚上进行集成,第二天早上发布结果; 2.在集成服务器上配置集成方案,指定所需要的产品栈或子栈,指定所需产品的版本或分支,指定需要进行卸载、安装测试,功能测试的Lab以及Lab里的服务器; 3.只需修改少量参数配置,即可以实现不同的持续集成方案。 责编:赵新娜 微信扫一扫实时了解行业动态 微信扫一扫分享本文给好友 著作权声明:kaiyun体育官方人口
文章著作权分属kaiyun体育官方人口
、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。 |
|
|