研发协同平台持续集成之Jenkins实践
导读
研发协同平台有两个核心目标，一是提高研发效率 ，二是提高研发质量，要实现这两个核心目标，实现持续集成是关键之一。
什么是持续集成
在《持续集成》一书中，对持续集成的定义如下：持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次,也可以多次。每次集成会经过自动构建(包括自动测试)的检验，以尽快发现集成错误。自从在团队中引入这样的实践之后，Martin Fowler发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。
1、集成
集成就是一些孤立的事物或元素通过某种方式集中在一起，产生联系，从而构成一个有机整体的过程。知识经济的社会，集成已经成了很重要的一个名词。各行各业基本都会用到集成。比如汽车行业，那么复杂的一台跑车愣是通过一大堆零件组装起来。对于这些传统行业，它们在研发成功以后，可以通过流水线的方法批量生产进行集成。而在软件行业中，集成并不是一个简单的“搬箱子”的过程。因为软件工业是一个知识生产活动，其内在逻辑非常复杂，需求又很难一次性确定，完成的产品与最初的设计往往相差很远。敏捷宣言中就有一条是说响应变化重于遵循计划。而且由于软件行业的迅猛发展，软件变的越来越复杂，单靠个人是根本无法完成。大型软件为了重用及解耦，往往还需要分成好几个模块，这样集成就成了软件开发中不可或缺的一部分。
2、持续
“持续”并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是：
自动化流程：实现关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及部署。
可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建。
快速迭代：“快速”在这里是个相对术语，但无论软件更新、发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。
3、组成
持续集成一般包括自动编译、自动构建、自动打包、自动部署、自动代码检查、自动化测试
为什么要做持续集成
项目中常见的问题
- 集成时发现系统无法运行
- 不同分之之间合并代码经常出错
- 加班加点改BUG
- 重复进行手工的部署、调试、测试、发布，成本高，风险大
团队文化问题
- 对交付软件的质量意识不足
- 无法做到优先处理失败的构建
- 工程师文化不足
- 团队管理、流程的不足
持续集成的优点
持续集成能提升交付效率和交付软件的质量
- 及时反馈结果，尽早发现问题
- 自动化代替手工，工程师将更多的时间精力放在设计、需求分析、风险预防等方面
- 通过持续集成提高自动化程度来提高效率
持续集成工具选型
市面上的持续工具很多，下面列举了部分
- AnthillPro：商业的构建管理服务器，提供C功能
- Bamboo：商业的CI服务器，对于开源项目免费
- Build Forge：多功能商业构建管理工具，特点：高性能、分布式构建
- Cruise Control：基于java实现的持续集成构建工具
- CruiseControl.NET：基于C#实现的持续集成构建工具
- Jenkins：基于java实现的开源持续集成构建工具，现在最流行和知名度最广泛的持续集成工具
- Lunt build：开源的自动化构建工具
- Para Build：商业的自动化软件构建管理服务器
综合考虑，团队选取了Jenkins作为持续集成工具，主要的选型理由是：
- 开源
- 成熟度活跃度高
- 分布式
- 插件丰富、功能强大
- 团队成员比较熟悉，都或多或少使用过
研发协同平台持续集成工作原理
研发协同持续集成整个工作流程如下
- 开发人员提交代码到代码仓库
- 研发协同控制台触发持续集成任务
- 持续集成主节点进行任务调度，将构建任务分发到构建从节点，将部署任务分发到部署从节点，将质量任务分发到质量从节点
- 构建节点获取代码，按照构建脚本执行，构建，打包
- 部署节点按照部署脚本，将服务部署到容器中
- 质量节点按照相应脚本，进行静态的代码扫描、运行单元测试
- 持续集成主节点通过回调机制，将任务状态实时回传到研发协同控制台
研发协同平台持续集成管道
持续集成管道图
持续集成作业图
- 一个持续集成管道由一系列持续集成作业组成
- 持续集成管道中的作业可以是串行，也可以是并行
- 管道中的作业由一组命令组成
- 命令是持续集成中的最小单元
- 研发协同平台内置了一批命令集
- 不同的命令组合成不同功能的作业
- 不同功能的作业组合成不同功能的管道
- 研发协同平台上不同服务类型的持续集成使用不同的管道
研发协同平台持续集成特性
研发协同平台的持续集成具有如下特性：
- 一键集成： 用户一键完成整个集成过程，无需额外的配置和操作，简单、快捷、方便
- 开箱即用： 研发协同平台内置了公司所有产品持续集成所需要用到的命令、作业、管道，用户无需额外工作，开箱即用
- 灵活配置： 如果已有持续集成过程需要调整，只需调整已有作业的命令集，已有管道的作业即可； 如果有新的服务类型要做持续集成，只需根据命令自由组合新的作业，根据作业自由组合新的管道，即可完成对新服务类型的持续集成支持
- 可扩展：研发协同平台，内置了一批命令集、作业、管道。如果不满足需求，可以很方便的添加新命令，从而组建新的作业和管道，实现功能扩展
- 分布式： 研发协同平台使用持续集成工具Jenkins的主从特性，主节点只做任务的调度和分发，具体作业执行在各个从节点上，实现分布式执行
- 负载平衡： 从节点分为构建节点、部署节点、质量节点三类，每一类都由一组节点组成集群，在主节点将任务分发到从节点时，可根据负载规则分发到集群中的某一个具体节点上执行。当前支持的负载规则有：随机分配、顺序分配、按资源使用情况分配、指定具体节点分配
持续集成工具Jenkins运维
研发协同平台持续集成使用了Jenkins作为持续集成工具，保障Jenkins的安全、性能、高可用，对jenkins的持续运维也是很重要的一部分
安全
安全矩阵
在Jenkins管理-> 安全配置-> 访问控制-> 安全矩阵中，可配置用户的访问权限
安全漏洞
Jenkins是开源软件，安全漏洞爆出的频率较高，易于受到攻击，防止攻击的一个有效手段就是即使升级Jenkins版本，修补漏洞
升级
如何升级，资料很多，这里就不做赘述，但有一些事项需要注意：
- Jenkins主版本升级并不能保证插件的兼容性，升级可能会导致一些插件不可用，要检查正在使用的插件是否需要同步升级
- 有些插件在升级后也不能完全保证兼容，升级后也有可能需要做一些相应的调整和修改，对于在用的插件，在升级前也要做评估
- Jenkins 141之后版本加入了softkill的功能，会导致所有的windows节点执行耗时很长甚至卡死。需要在所有的windows主从节点上的配置文件中添加启动参数 -DSoftKillWaitSeconds=0 来解决此问题。
性能
- 不要在主节点上执行任务，主节点只做任务的调度和分发
- 清理旧数据，在jenkins管理-> 管理旧数据中，可清理旧数据
- 不要保留太多的构建历史记录，可定时清理构建历史。可在在jenkins管理-> 脚本控制台 执行清理脚本来清理构建历史， 下面的示例脚本是保留10条构建历史记录
def numberOfBuildsToKeep = 10
Jenkins.instance.getAllItems(AbstractItem.class).each {
if( it.class.toString() != "class com.cloudbees.hudson.plugins.folder.Folder" && it.class.toString() != "class org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject") {
builds = it.getBuilds()
def j = 0
for(int i = numberOfBuildsToKeep; i < builds.size()-j; i++) {
builds.get(i).delete()
i--
j++
println "Deleted: " + builds.get(i)
}
}
}
- 在Jenkins的启动参数中调整jvm内存大小，默认是512M, 可以根据需要调大一些
高可用与灾备
集群
Jenkins是主从节点，从节点可以做集群、负载，从而实现从节点的高可用，但是主节点是单节点，一旦主节点宕机，会导致Jenkins服务不可用。 Jenkins主节点本身是不支持集群的，需要通过其他变通方式来实现。当前我们也未实现主节点高可用，有计划的是会做主备模式，如果主节点宕机，可快速切换到备用节点，恢复服务
备份
- 安装thinBackup插件
- 在thinBackup插件中，设置定时备份策略，进行定时备份
监控
性能监控
- 安装monitorign插件
- 在Jenkins管理-> Jenkins主节点监控中，可查看监控jenkins主节点性能数据
健康检查
- 接入研发协同的监控服务，检查jenins服务的可用性
写在最后
当前研发协同平台已经能全面支持公司产品各种场景的持续集成，后续会进一步落地持续集成工具jenkins主节点的高可用，进一步探索支持多种持续集成工具的必要性和可行性。
