关闭

【软件工程】持续集成:如何建立百万行级代码的版本构建系统

标签: 软件工程管理
1533人阅读 评论(0) 收藏 举报
分类:

工作经历:

本人华为工作6年,做过开发、维护、一线支撑等大量技术工作。

因为加班吃不消进入中软,目前为高级项目经理,主导CI(持续集成)方向,中软应该是职业生涯的中间一站。

本文主要涉及多个项目组间同步、版本配套、编译、打包的自动化,持续集成包括验证、部署、发布的自动化,笔者接触较少,不献丑了。

本文只介绍基本框架,不涉及细节,细节部分后续逐渐补充。

一、百万行级代码模块及项目组配合


(图片丢了:本软件产品整体结构分为3层,每层5~15个项目组,到顶层项目可以无限拓展。最底层OS为改造开源Linux;中间层分为P、M等模块,各约10万行,华为自主研发;上层为具体应用,对应xxx产品线x个产品)

上述图片只是一个示例,由于涉及到部分信息机密,所有模块都简略了名称。

OS:外购或者开源(vxWorks/Linux),再底层是硬件

P和M:基于OS的二次开发,管理屏蔽硬件细节,对不同的产品提供通用操作接口

G、U、C:具体产品,打包发布后用来给H的设备升级,提升性能、解决BUG、新特性等

上述每个模块是一个部门在做,平均每人每年开发5000~8000行代码,多个版本并行

各个部门发布版本的周期不同,类似P部门发布5个版本,同期M部门发布1个版本,而OS保持稳定没有新发版本

二、git库和svn库


(图片丢了:SVN库保存较大并且更新频率较低的模块例如OS;GIT库保存P、M等所有模块的所有版本,同时增加一个版本配套关系表)

参考上图,软件产品关系例如P v2 + M vz + ... = Release CxxxRxxxVxxx

Release产品是哪几个模块的哪几个版本,维护在版本配套关系表中。

上述所有的模块加上关系表,都保存在GIT库中。

svn库没有描述出来,svn主要是保存发布版本而非源代码。

上图中描述的是所有部门的配套关系,每个部门中有不同的项目组负责小一点的模块,那么同样需要部门的git库,原则上和上述git库相同,只是发布周期等有差异。

三、分布式构建系统


(图片丢了:一个M主控,一个C管理资源,N个A服务器做编译、静态检查、打包等)

上图是一个最简单的分布式构建系统,由M服务器接收任务,C管理资源,多个A组成资源池执行分布式编译、打包的任务。

构建系统因为不同的问题会演化得非常复杂,具体等下篇博客详细讨论。

四、其它待解决问题

1、构建系统的前台页面,可以由所有的开发用户访问,启动编译、打包、代码检查等流程。

2、构建系统需要多种启动方式,除了个人选择版本分支进行验证外,凌晨的版本是一天工作的集合,一定要定时器来触发。

3、版本的地址、版本形态、组件的裁剪等,需要配置,所以对应工程需要配置文件。

4、构建系统同其他代码相对独立,但是也需要验证,也需要上git库。

5、构建系统本身代码的验证,需要一个独立环境,可以将上述的最小化系统独立建立一套来验证构建系统代码,流程OK以后再同步到正式环境。

6、SVN更新代码需要同步时,对网络带宽占用较大,可以使用一台服务器先下到局域网,之后使用同步工具拷贝到A。

7、FTP、HTTP server搭建。

8、构建系统自身要有关键点的日志,出现异常后可以及时反馈。每日版本构建失败是研发的事故,连编译都无法通过的代码必须当天解决问题。

9、构建系统一定要稳定,本身失败的概率要低于10%;效率要高,一般不超过1小时,每天可以给项目组更多的轮次验证。

10、构建系统随着需求增加会有很多扩容需求,一定要可以根据配置自动安装。

11、构建系统需要的服务器较多,百万行级代码需要50台服务器以上,建议使用虚拟机,便于扩容、复制等。

12、各个项目组验证、上库、合入代码等操作,都需要严格规定,不能任意打乱主干代码!

。。。。。。。。。

本人QQ 280775561,微信JohnLee790608,有同路人可以一起探讨。

0
0

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