前言

相信大家对 DevOps 和 CI、CD 的概念非常熟悉，因为网上有很多文章介绍，但是介绍其具体实现方案的文章非常少。接下来本文将主要介绍互联网持续集成解决方案在云集的具体实践，干货满满哦，如有问题欢迎直接公众号留言。好了闲话不多说了，下面开始正文吧。

在云集，由于研发中心基础设施不够完善，造成工程规范不统一，流程规范不统一，可视化程度不高，在系统越来越庞大的情况下，非常影响交付效率，交付质量，以及沟通成本过高。

为了更好的支持业务的高速发展，快速实现，这时我们提出打造一个持续集成平台来解决这一问题。

• 为了不影响业务的正常运行，不能在解决问题的同时带来新的成本
• 我们需要做到兼容历史问题，平滑过渡，推进工程标准化落地
• 减少大家对概念认知的不统一
• 我们需要做到用户体验极致精简，高效，减少理解成本
• 提高推广进度，减少沟通成本
• 我们需要做到价值驱动，选取部分测试、运维、开发、PMO共同建设，优化流程，提高效率

一. 当前遇到的问题

1. 流水线管理问题

• 代码扫描工具没有统一管理，造成开发代码存在硬编码，常规漏洞以及编码规范不统一
• 开发单元测试没有统一管理，很难推进落地以及监督，造成自测不充分，提测质量差
• 存在的测试自动化代码由于没有很好的和被测工程代码关联，以至于没有很好的利用起来，造成落地效果不明显
• 几乎没有完整流水线，Jenkins运行节点维护成本过高

2. 环境问题

• 多套环境应用、数据库、配置中心的同步问题，造成环境维护成本高
• 资源占用不清晰问题、以及不能有效控制成本
• 工程标准不统一，没有统一的应用资源配置中心
• 环境不能灵活扩展问题

3. 协作问题

• 项目进度不透明，信息不对等（产品、开发、测试），无法做到随时跟踪
• 协作流程线下化，流程复杂及链路长，沟通成本高
• 各阶段关键节点无报告或报告输出成本高
• 分支管理不规范

二. 解决以上问题

由于出现以上问题，我们急需打造一个从项目开始开发到上线之间的整个研发测试流程自动化与可视化平台

项目流程实现CI、CD和敏捷开发模式的集成，达到提高交付效率和质量

CICD.png我们最终的目标是实现配置标准化，流程自动化，敏捷平台化，落地可视化，由于实现这个目标是一个长期不断进化的过程，需要整合很多基础组件以及其他方面的配合，故把平台命名为 DARWIN

三. 实现方案

1. 流水线管理

• 流水线（代码扫描、单元测试、打包与镜像、环境部署、自动化测试）平台化统一管理
• 一键创建流水线，各节点自动集成，代码提交自动构建、推动代码扫描、单测、自动化落地

2. 环境管理

• 应用基础信息、环境配置信息统一管理
• 代码包、镜像包、环境统一管理，所有信息可查，环境平滑迁移
• 环境监控、环境同步（镜像同步，数据库同步，Diamond配置同步）
• 各环境资源可视化

3. 协作管理

• 支持项目提测、测试报告、需求管理、迭代管理，状态自动流转，推进项目流程规范落地
• 自动收集自动化测试、单元测试、代码规范扫描、部署情况等信息，以及项目协管信息，为质量运营平台提供数据源，分析研发过程指标
• 代码提交流水线自动触发、与需求自动关联，分支自动创建等，减少开发测试工作量

四. 功能概括图

功能概括图

五. 总体设计方案

总体设计方案

六. 流水线主要采用了 Jenkins2.0 Pipeline as Code

Pipeline：简单来说，就是一套运行于Jenkins上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂发布流程

Pipeline## 功能特点

• 持久性
  在jenkins的master按计划和非计划的重启后，pipeline的job仍然能够工作，不受影响。
• 更灵活的并行执行，更强的依赖控制
  通过groovy脚本可以实现step，stage间的并行执行，和更复杂的相互依赖关系。
• 可扩展性
  通过groovy的编程更容易的扩展插件。
• As Code
  集中管理CI脚本、用代码库来管理脚本、从代码库直接读取脚本，从而可以将项目CI迅速拉起来！

七. 流水线节点实现方案

流水线节点# 八. 多套环境演进方案

多套环境演进方案## 阶段一

实现多套环境的方式是每套环境都采用全量应用，存储可以使用多套或一套。

优点：

• （1）不需要开发侧或基础架构配合即可实现

缺点：

• （1）很明显，就是很浪费资源

阶段二

实现多套环境的方式是首先搭建一套基线全量应用环境和存储，扩展环境时只需要扩展被测应用到入口应用之前的所有应用。

优点：

• （1）相对阶段一方案节省了一些资源

缺点：

• （1）有改造 zookeeper 的成本，由于云集采用的主要服务都是dubbo服务，zookeeper 分布式服务框架作为注册中心，要想分支环境环境访问主干环境，需要 zookeeper 支持级联（即应用C1先在本 zookeeper 查找服务D1，如果找不到就去主 zookeeper 中查找D），需要对 zookeeper 注册中心作一定的改造。
• （2）请求在当前环境不能形成闭环，一旦从分支环境访问到主干环境，就只能在主干环境了，回不来了

阶段三

实现多套环境的方式是首先搭建一套基线全量应用环境和存储，扩展环境时只需要部署实际被测应用即可。

优点：

• （1）相对上面阶段是最节省资源的，真正做到了按需部署，随时拉起自己的服务，可以做到每人一套测试环境，互不干扰
• （2）请求在当前环境形成闭环
• （3）由于带了环节标识，不止只用于功能测试，还采用相同方案实现全链路压测
• （4）如果改造好了，是一劳永逸的事情，大大提升了系统的可测试性

缺点：

• （1）改造成本非常高，需要改造所有基础组件和中间件，如zk、mq、diamond、dubbo、http通用工具，redis、mysql等，因为如果不改造增加环境标识，请求还是回不到指定环境形成闭环的；当然如果业务完全配合修改，也能实现，但是改成成本就更高了，后续维护成本也会大大的增加，故还是只改基础组件最好

九. 一键切换测试环境实现方案

1. 客户端一键切换测试环境实现方案

相信大家都遇到过随着容器化环境越来越多，就给客户端测试带来了很多不便，如何让客户端非常方便的访问被测环境就是急需解决的问题了，针对在这个问题，我们提出了三个解决方案：

• 方案一、客户端切换环境时，在**webview上配置不同代理的方式**实现，经过预研由于android9.0版本以上不支持，但现在主流android机型都高于这个版本了，故行不通
• 方案二、统一不同环境域名规则，所有域名前增加环境标识，客户端切换环境时，根据域名规则替换域名，但是这样就给开发带来了成本，配置文件和配置中心存在域名的地方都需要改造，由于k8s容器空间本来就做到了环境隔离，故大家都使用同一个域名，同一个配置文件，是最方便开发和运维的，也不存在对现有的前端、H5、客户端做改造，故为了降低维护成本和开发成本，也不采用这个方案
• 方案三、客户端切换环境时，通过**User-Agent中增加环境标识，nginx拦截User-Agent**信息解析转发，故在nginx域名解析侧实现不同容器环境的切换与访问，这样业务开发侧就都不需要改造，只有客户端支持下即可完成

综上所述，我们最终采用方案三实现，极大的提高了开发和测试效率，效果图如下：

## 2. WEB端一键切换测试环境实现方案

相信大家已经想到了上面客户端实现方案一样可以用在WEB端使用，只需要使用google浏览器安装User-Agent Switcher 插件就能实现了，是不是so easy，效果图如下：

# 十. 新老工作方式对比

1. 常见场景工作方式对比

## 2. 研发流程工作方式对比

从以上工作方式对比可以看到我们把很多繁琐操作都变成了系统自动完成，从而极大的提高了工作效率

十一. 效果展示图

流水线管理示例图协作管理示例图数据汇总示例图访问概括示例图# 十二. 遇到的挑战

在解决问题的同时，我们也遇到了很多挑战

• 首先就是兼容问题，为了能顺利推广并解决问题，我们需要做到兼容所有工程不统一和流程不规范问题，最终让大家平滑过渡，推进工程标准化落地。
• 其次就是用户体验问题，由于公司刚刚引入DevOps的思想，很多一线开发测试人员对流水线和容器化的技术手段比较排斥，认为耽误了他们的效率，我们需要做到极致精简（接入简单、操作简单、理解简单）、以及可视化程度高、运行效率高（代码扫描、单元测试、打包与镜像并行运行、以及并行编译等方法）、系统稳定，遇到问题快速修复，及时响应、梳理问题，不断优化，几乎所有问题，我们都会在分钟级别内修复，相信大家可以体会到这些对于一个内部使用的技术系统是非常有挑战的。
• 最后就是运营问题，相信大家都清楚通过技术手段解决问题容易，但是在互联网公司技术部门推广新技术的全面落地是非常困难的，如何让大家都愿意接受并使用是需要挑战的，我们采用了价值驱动、选取试点优化容错，最主要的手段就是跨部门合作，拉上测试、运维、**PMO、开发**一起共建，最终达到顺利推广的目的。

以上这些问题都是我们需要不断重点突破和进步的挑战，从而不断进化。