1-转转公司devops方案-中小型企业持续集成的快速实现和持续演进-转转-陈秋.pdf

1、转转公司devops方案中小型企业的快速实现和持续演进讲师:转转-陈秋01背景/目标02beetle系统持续集成发布系统持续交付03度量系统效能度量04目录CONCENTS01背景目标背景/目标外部有很多将devops的分享，但是分享如何做，踩过那些坑的并不多。今天这里想和大家分享下，转转在CICD过程中走过的路程踩过的坑，希望能给大家有所借鉴。这就导致，不同公司、不同规模的公司的流程工具可能会有比较大的差异。背景/目标中小型公司特点背景/目标诉求：1，满足对分支管理的要求2，满足串联核心流程的要求3，架构简单，扩展性好，为后续插件留好接口4，要快速实现02beetle系统整体目标方案设计整体

2、分为这三个部分：1，code：使用gitlab2，build：任务调度使用jenkins3，deploy：调用现有环境平台和发布平台的能力进行串联4，自研平台，实现分支的管理和串联能力code代码管理和分支管理build编译脚本管理、编译、任务调度发布发布管理整体构成code-代码管理分支的管理是整个工作流管理的核心之一，不同的场景，不同的要求，则所选择的分支管理方式也不一样。下面我们介绍下我们的选择过程。code-分支管理1.在功能分支完成功能开发2.合并到develop分支，进行集成测试3.拉release分支，最后的测试，版本修改4.合并到master，上线分支管理-gitflow经典模

3、型gitflow经典模型-特点分析适用场景：APP端在发版情况下，一个工程，会多个人同时开发。之后集成测试，非常贴合APP的开发测试流程根据上面模型的特点，我们演化出了适用于我们业务特性的分支管理方式。code-分支管理1.Master分支永远对应线上版本的源码，任何人无修改权限2.个人可拉功能分支，测试完成后合并至发布分支3.发布分支进行集成测试，最终发布4.发布完成后将发布分支对应的tag代码同步至master模型演化-集成分支发布release分支上线：保留集成过程，适用于app开发测试流程。适用于多人协作的项目。系统实现1.Master分支永远对应线上版本的源码，任何人无修改权限2.个

4、人可拉功能分支，测试完成后直接发布3.发布完成后将功能分支对应的tag代码同步至master模型演化-临时分支发布系统实现临时分支上线：分支开发分支上线，要随时集成master上已经上线的代码，每次集成内容都是上线内容。回归量小，用户快速开发。适用于后端以及fe工程开发测试流程分支管理-对比1、统一的源码结构2、统一的编译环境3、统一的编译脚本4、编译检查（非常重要）build-构建管理u前端源码结构未做要求打包后结构规则u后端（RPC/WEB）源码结构规则打包后结构规则约定统一的源码结构统一脚本编译检查拦截build-jenlins使用原则工程类型：FE、java、ios和android编译

5、速度优化速度慢的工程类型：FE、iOS，AndroidApp方案：上M1芯片的macmini效果：提速50%，成本低，见效快工程类型：FE稍稍复杂一些编译速度优化编译时间=npm install+build效果：时间减少50%-70%消灭了编译的极值.方案设计-整体结构总结-第一个版本-开发成本现在我们的系统是什么样子？总结-目前版本防止腐坏系统的度量1，编译时间2，部署时间，包括测试，沙箱，线上3，编译失败恢复4，部署失败恢复通过度量发现系统流程中的问题，不断去迭代本身的效率。通过调研以及和业务的不断交流（互相教育）不断的完善系统的功能。总结-系统度量总结-快速实践基本原则1，限定范围，cr

6、，覆盖率，diff，sonar等2，扩大开发范围，开发测试都可以编写自己的插件，做好把关3，按照预留好的接口进行接入03发布系统最开始的系统很简单，只有一个部署物理机的能力。最开始我们也不知道，发布系统产品要演进到什么程度。最开始的系统设计，物理机启动的agent屏蔽了起停的逻辑。发布系统解耦，对未来保留了充足的扩展空间。持续交付发布系统-体系结构发布系统-云平台 单点：服务中第一台被发布验证的节点 并行度：同一批一起被部署的节点数 上线下线：是否接入流量（nginx或服务治理）终止：发布有一个实例失败，自动终止。