scrum gathering 2012 shanghai 精益与持续改进分会场演讲话题:...

22
大型企业CI平台建设和实施分享 腾讯 陈小光

Upload: letagilefly

Post on 21-May-2015

1.215 views

Category:

Technology


2 download

DESCRIPTION

大型企业CI平台建设和实施分享 腾讯 陈小光 Agenda .现状&挑战 .实践分享-平台建设 .实践分享-实施推广 .总结 .Q&A .7年研发管理和优化经验,跨越银行、互联网等行业 .目前腾讯持续交付、持续集成实践者 .爱好广泛包括且不限敏捷实践,音乐,数学 .微博 @v陈小光v .Mail [email protected] 现状&挑战-现状 .工程师>500 .同时进行的项目>20 .开发语言覆盖c,c++,php,java,以及手机平台等 .项目之间依赖复杂,涉及到多层循环 现状&挑战-挑战-平台 .同时存在CI平台五套,各自为政,平台不一,资源浪费,是否要整合? .当项目代码量超过百万时,如何提升构建效率?如何管理复杂构建依赖? .CI集群30台,如何能及时有效的更新工具和软件以及配置到相关环境里面? .如何保证从开发->测试->上线三个步骤的源码和二进制包版本一致性? .如果处理来自不同团队的对CI平台的需求? 现状&挑战-挑战-实施 .BU老大们对CI理解不一,如何获取他们的支持? .开发对持续构建的失败漠不关心怎么办? .如何让不到五人的CI团队,高满意度的支持大于五百人团队实施CI? .如何提高开发编写单元测试的积极性? .底层代码随意变更提交,影响到上层代码怎么办? 解决方案-平台-设计思想 .平台设计思想: .统一平台和运维,减少维护成本和机器资源,成果共享 .环境保证绝对权威,跟线上、测试、开发保持一致 .提升易用性,减少用户学习成本 .统一测试和上线的包出口 .工具尽量使用开源 .Jenkins .Subversion .Testlink 解决方案-平台-拓扑结构 new.jpg 解决方案-平台-高效构建系统 . 基于开源scons自研的一套分布式统一构建系统 .支持c++,java,probuf,swig等多种语言 .代码变更后可以自动分析依赖关系 .集构建,测试,静态代码检查,高亮错误显示等功能 .支持增量和分布式编译和测试 . 解决了构建效率和依赖管理问题 .其他提升构建速度方法: . 使用tmpfs,IO效率基本为0,需要大内存机器 . 使用cache机制,比如ccache . 分布式编译,比如distcc . 源码分层:抽离基础库代码专人维护,包括common和thirdparty 解决方案-构建分级 构建类型 .NightlyBuild:夜间,全量测试和构建,重建cache .CheckInBuild:CheckInSvn,增量ut,增量构建, 基于cache .HandleBuild:按需,全量构建和测试,为了打包 解决方案-平台-统一接入脚本 概述:统一某种类型的项目或代码的公共动作(比如编译,执行ut,静态检查,包上传等)到一 个脚本或工具里面,用户只需要输入路径配置即可完成CI的配置,减少用户学习和使用 成本

TRANSCRIPT

大型企业CI平台建设和实施分享

腾讯 陈小光

Agenda

现状&挑战

实践分享-平台建设

实践分享-实施推广

总结

Q&A

7年研发管理和优化经验,跨越银行、互联网等行业

目前腾讯持续交付、持续集成实践者

爱好广泛包括且不限敏捷实践,音乐,数学

微博 @v陈小光v

Mail [email protected]

现状&挑战-现状

工程师>500 同时进行的项目>20 开发语言覆盖c,c++,php,java,以及手机平台等 项目之间依赖复杂,涉及到多层循环

现状&挑战-挑战-平台

同时存在CI平台五套,各自为政,平台不一,资源浪费,是否要整合? 当项目代码量超过百万时,如何提升构建效率?如何管理复杂构建依赖?

CI集群30台,如何能及时有效的更新工具和软件以及配置到相关环境里面?

如何保证从开发->测试->上线三个步骤的源码和二进制包版本一致性?

如果处理来自不同团队的对CI平台的需求?

现状&挑战-挑战-实施

BU老大们对CI理解不一,如何获取他们的支持? 开发对持续构建的失败漠不关心怎么办?

如何让不到五人的CI团队,高满意度的支持大于五百人团队实施CI?

如何提高开发编写单元测试的积极性?

底层代码随意变更提交,影响到上层代码怎么办?

解决方案-平台-设计思想

平台设计思想: 统一平台和运维,减少维护成本和机器资源,成果共享 环境保证绝对权威,跟线上、测试、开发保持一致 提升易用性,减少用户学习成本 统一测试和上线的包出口

工具尽量使用开源 Jenkins Subversion Testlink

解决方案-平台-拓扑结构

解决方案-平台-高效构建系统

基于开源scons自研的一套分布式统一构建系统

支持c++,java,probuf,swig等多种语言 代码变更后可以自动分析依赖关系 集构建,测试,静态代码检查,高亮错误显示等功能 支持增量和分布式编译和测试

解决了构建效率和依赖管理问题 其他提升构建速度方法:

使用tmpfs,IO效率基本为0,需要大内存机器 使用cache机制,比如ccache 分布式编译,比如distcc 源码分层:抽离基础库代码专人维护,包括common和thirdparty

解决方案-构建分级

构建类型 NightlyBuild:夜间,全量测试和构建,重建cache

CheckInBuild:CheckInSvn,增量ut,增量构建,基于cache

HandleBuild:按需,全量构建和测试,为了打包

解决方案-平台-统一接入脚本

概述:统一某种类型的项目或代码的公共动作(比如编译,执行ut,静态检查,包上传等)到一个脚本或工具里面,用户只需要输入路径配置即可完成CI的配置,减少用户学习和使用成本。 C++: 写好脚本ci_exec compile_dir=$dir1 ut_dir=$dir2 st_dir=$dir3

Java(ant为例):

解决方案-平台-统一环境管理-puppet管理环境

使用puppet做构建环境统一管理更新

管理如下配置: Hosts配置 构建脚本 构建软件 Slave初始化脚本

Slave上puppet初始化用rpm包实现。

Subversion

Puppet

master

Puppet

slave1

Puppet

slave1 …

WorkSpace

CheckIn

亦可通过CI本身功能来管理环境 Jenkins提供多Slave配置功能

解决方案-平台-统一环境管理-Jenkins管理环节

通过Jenkins本身管理构建环境,slave正在以后即可做。

通过Jenkins多Slave配置完成: 规划好SVN里面目录Conf bin等 在Slave机器上配置bin目录到$PATH

优点: 使用方便,测试通过以后直接提交到SVN即可更新 Jenkins直接辐射到各个Slave,更新方便

缺点: 没有整体视图

Subversion

Jenkins

master

Jenkins

slave1

Jenkins

slave1 …

修改工作区

CheckIn

解决方案-平台-presubmit方案-client模式

Dev工作区

Subversion CheckSvnService

Upload.py专用提交脚本

Check.py 检查:提交的注释里面是否有指定加密串 通知:通过对应人

Upload.py: 1.检查是否被模块owner Codereview且被Approved 2.在内存文件系统tmpfs中快速run编译和ut 3.做CodeStyle检查以及静态检查 4.成功则自动提交,在注视里面加标记 5.失败给予提示 upload.py –i 33896 –I 后为codereview id 目的:把问题扼杀在提交到代码库之前,减少影响

Dev工作区

Source

Control

System

CheckSvnService

presubmit.py脚本 检查、信息搜集、打diff、上传

Check.py 检查:提交的注释是否有指定加密串 通知:通过对应人

两种Presubmit模式-Client/Server模式

Presubmit服务器

验证、提交

解决方案-平台-包服务器媒介

包服务器

CI

Test Rel

IDC Test

1 2

3

4

包服务器两分支 Test:用来存放从CI发过来的包,待测试 Rel:用来存放从已测的包,待发布 包服务器跟电子流串通

1 CI里面执行手工打包,到包服务器test分支

2 测试从包服务器取包部署测试测试环境

3 得到测试通过信号后,被测通过的包自动转到rel分支

4 发布系统从rel分支拉取测通过的包上线

解决方案-平台-报表平台

jenkins构建的报表平台 保存如下数据 构建成功率 构建时长 测试覆盖率 接入率等

有开源插件可支持数据报表展现!

解决方案-实施-先试点

试点项目选择: 交付压力小的重点项目 成立联合虚拟项目组运作 做好评估:缺陷率,代码质量等

试点目标目标: 摸索经验 平台建立 树立标杆 建立影响 透明效果 取得重视

解决方案-实施-制度化

接口人制度: 1.需要实施CI部门指定接口人 2.每个部门对应CI实施责任人 3.对CI实施接口人进行training

CI平台需求管理流程: 1.把CI平台当做“产品”来做 2.明确需求管理流程 3.排期实现,可视化进度

沉淀制度 1.把CI实施框架和FAQ沉淀到wiki 2.每周专人值班辅助接口人 3.常见问题沉淀到wiki

合作,而非推广

解决方案-实施-可视化 周报:部门周报 月报:整个事业部周报 显示器:质量情况,放置门口

总结

平台 总体架构:统一平台,包服务器,统一出口

构建平台:构建平台,管理依赖,支持分布,增量编译

公用脚本:封装复杂操作,减少dev学习和使用成本

环境管理:puppet,利用CI平台管理构建环境

Presubmit机制:presubmit,codereview确保质量

实施 试点先行:摸索经验,建立平台,树立标杆,扩大影响

推广策略:沉淀wiki,职责明确,值班制度,合作态度

报告和奖励机制:数据可视化

Q&A