从“每月交付一次”到“每天交付多次”的升级打怪之路

1 .从“每月交付一次”到“每天交付多次” 的升级打怪之路 演讲人：李威 全球敏捷运维峰会 广州站 

2 .李威 JFrog DevOps解决方案架构师 JFrog 架构师，9年开发及运维领域工作 经历，带领团队从零到一打造DevOps 平台，并在大数据、公有云等领域有着 丰富的解决方案及交付经验。目前就职 于JFrog中国，专注于DevOps 解决方案 设计，以及企业 DevOps 转型咨询。 全球敏捷运维峰会 广州站 

3 . 现状 工具链复杂 每个团队耗费大量运维人员，维护自己 多地协同网络传输质量差 的一套工具链 多研发中心模式下，耗费大量时间 成本在远程会议沟通、文件传输上 交付质量标准不一 慢 大量自研及外包团队多地分散管理 需求交付周期长、迭代速度慢 对于代码质量、测试通过率等 没有统一评判标准 安全重视程度不统一 交付流程不统一 没有标准化的交付流程，每个 各个团队对安全问题要求不一 团队有自己的交付方案 致，导致最终上线受影响 全球敏捷运维峰会 广州站 

4 .目前的流程，及改进的方式 全球敏捷运维峰会 广州站 

5 .从0到1的解决方式 集团推广 1，集团推广、打磨平台 形成制度 2，学习最新技术、完善 体系 1，根据项目试点情况， 项目试点 完善制度 2，完善管理方案及组织 1，2个项目试点 架构 平台搭建 2，平台管理团队快速 响应业务需求，收集用 1，成立团队 户反馈 2，集团情况调研、工具引进 3，收集测试项目数据、 3，内训、传递DevOps文化 明确交付效率提升 4，文档完善、制定DevOps 管理方案 全球敏捷运维峰会 广州站 

6 .打造统一的DevOps团队，前期可以为虚拟组，后期打造专属团队 产品经理 运维 负责需求管理、制定规 维护iaas层稳定 范及工具选型，负责整 维护工具链 个DevOps平台建设 监控 开发 安全 技术栈选型 对开发安全负责 测试 运营 测试流程管理 成本把控 工具选型 指标制定 全球敏捷运维峰会 广州站 

7 .DevOps建设的第一步，工具链 • 打造工具链 • 内部适配 • 外包适配 全球敏捷运维峰会 广州站 

8 .多研发中心、多数据中心架构模式 全球敏捷运维峰会 广州站 

9 .建设过程中存在的问题 开发不愿配合 流程不规范，私自 时间投入成本高 绕过质量检查 开发人员不愿接受新的开 开发人员不愿自己代码进 开发人员需要花很多时间 发模式 行质量检查 成本了解复杂的工具链、 编写构建流水线 全球敏捷运维峰会 广州站 

10 .解决问题方法 流水线统一 构建平台统一管理 构建模版统一编写 模版统一收集元数据 由统一部门打造构建平台， 回收权限 由统一部门打造构建模版， 在模版中强制进行必要的扫 无需开发人员介入维护。 开发人员无需自己编写，直 描及测试，并收集所有工具 不允许开发私自更爱流程 接调用即可 链的结果数据作为元数据统 一管理 全球敏捷运维峰会 广州站 

11 .基于Jenkins的最佳实现方式： 使用Jenkins的共享库，统一管理构建流程，收集元数据 全球敏捷运维峰会 广州站 

12 .建议收集的元数据 需求及版本信息 构建信息 对应到需求管理 构建环境 的issus 版本依赖 测试结果 代码静态扫描结果 单元测试 重复率 性能测试 Issus个数 集成测试 扫描报告 接口测试 坏味道 发布&部署信息 安全扫描结果 发布的环境 高危漏洞 部署的结果 开源协议 全球敏捷运维峰会 广州站 

13 .推广方式 试点团队推行 小范围试用 整个集团推广 验证方案可行性 工具链及构建模版 真正实现统一管理 收集更多用户需求 适配所有技术栈 全球敏捷运维峰会 广州站 

14 .多工具链，结果数据孤岛式存储，无法统一 ➢ 所有的软件包加上多样化DevOps各阶段 的信息 ➢ 根据Metadata的信息来实现自动化的快速 发布 ➢ 提高发布产品的自信 ➢ 简化清理策略 全球敏捷运维峰会 广州站 

15 . 各个厂商提供质量合格的零件 集成商使用质量合格的零件整合 三星 富士康 LG 索尼 全球敏捷运维峰会 广州站 

16 .元数据标识软件成熟度 全球敏捷运维峰会 广州站 

17 .交付件分级持续交付模型 –自动选择候选包 全球敏捷运维峰会 广州站 

18 .元数据筛选交付包版本 app-bundle-1.0 UAT -> Pre-Prod->Prod App-pipeline Micro-A-bundle-1.0 weeks Micro-B-bundle-2.0 Metadata: app-1.0.qa.test.result = OK 分级Metadata Micro-A—bundle-1.0 SIT - > UAT -> Pre-Prod->Prod Micro-A-pipeline Front-1.0.tar days Backend-2.0.jar Metadata: micro-a-1.0.qa.test.result = OK 分级Metadata … Local -> Dev Hours Backend-A-pipeline backend-1.0.jar Metadata: qa.test.result = OK qa.code.result = OK … project.revision = ASDASSAC binary.config.path=backend/dev/1.0 deploy.pre-prod.result=OK DevOps 包管理规范 Release History 全球敏捷运维峰会 广州站 

19 .多个服务 – 基于元数据自动化部署 全球敏捷运维峰会 广州站 

20 .与其他项目组约定质量关卡，并将关卡查询语句与源码绑 定，使用者通过关卡文件自动筛选所需版本 全球敏捷运维峰会 广州站 

21 .流水线中通过约定的关卡文件，筛选到最佳版本，替换到 pom文件中 全球敏捷运维峰会 广州站 

22 .安全风险 全球敏捷运维峰会 广州站 

23 .安全交付 全球敏捷运维峰会 广州站 

24 .SECTION ONE 总结 专人专组主导进行devops转型 团队 足够的技术储备 合适的工具链 工具链 从需求、开发、测试、部署、运维等层面要打造一个完整的工具链 合理的规范 规范 对于需求管理、开发管理、测试管理、部署管理、运维管理等都有明确的规范，过程数据、 资产数据统一管理 执行力 推广力度 DevOps团队需要有足够的话语权 24 全球敏捷运维峰会 广州站 24 

25 . THANK YOU！ 全球敏捷运维峰会 广州站