Zadig面向开发者的云原生持续交付平台实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. - 李倩 K o d e R o ve r 创始人

4. 软件交付挑战：开发模式演进过程研发阶段需求阶段想法运行阶段单体：需求设计｜代码编写｜构建 | 测试 | 部署 | 发布用户角色：产品/架构开发测试运维运维/开发技术支持事件需求设计拆任务、写代码写测试用例数据变更部署/灰度上线服务、工单管理架构设计代码集成系统验证代码变更监控/告警事件、缺陷管理单元测试验证自动化测试配置变更版本归档代码扫描性能测试部署测试环境交付追踪自测、联调安全测试部署预发环境数据度量集成验证部署生产环境

5. 软件交付挑战：开发 5 分钟,上线 2 小时研发阶段需求阶段服务一：设计服务二：设计服务三：设计想法代码编写代码编写代码编写构建构建构建运行阶段测试测试测试角色：产品/架构开发测试运维事件需求设计拆任务、写代码写测试用例数据变更部署部署部署发布发布发布运维/开发用户技术支持服务、工单管理架构设计事件、缺陷管理监控/告警

6. 软件交付的核心驱动力软件交付 1.0 流程驱动 •像 IBM 早期 IPD 流程工具集，国外像 CA，electric cloud；以流程串工具和人，大部分以平台形式存在。软件交付 2.0 工具驱动 •基于单点工具提升交付能力，比如过去几年交付领域 Artifacts 管理厂商 Jfrog、CI/CD 工具 Jenkins、面向运维侧的 Tekton/Argo 等；以解决交付链条中某个环节的效率为主。软件交付 3.0 业务驱动 •把业务作为整体，进入了以的 3.0 时代。主要利用云原生的能力，赋能于开发者，软件交付才能真正地变快变稳，从而推动以数字形态为主的产品交付。

7. 面向业务交付  面向大体量微服务，以应用为交付单元，充分运用 K8s 能力，释放重视开发者体验  幸福的开发者才能更好地创新，写出有灵魂的代码。工具的打造必须重视 GitHub.com/KodeRover/Zadig

8. 云原生核心交付思路以前：面向代码片段的串行交付代码一：代码编写 | 构建 | 部署 | 测试代码二：代码编写 | 构建 | 部署 | 测试代码三：代码编写 | 构建 | 部署 | 测试 | 发布 | 发布 | 发布特点：  重复流程自动化  边开发、边验证  服务全生命周期而非只关注代码  每天多次提交提早验证现在：面向多个服务编排的产品级自动化并行交付服务一：服务定义 ➡ 构建 ➡ 部署 ➡ 测试 ➡ 发布服务二：服务定义 ➡ 构建 ➡ 部署 ➡ 测试 ➡ 发布服务三：服务定义 ➡ 构建 ➡ 部署 ➡ 测试 ➡ 发布

9. 云原生软件交付：开发 5 小时,上线 2 分钟研发阶段需求阶段想法运维阶段服务一：设计 ➡ 代码编写 ➡ 构建 ➡ 测试 ➡ 部署 ➡ 发布服务二：设计 ➡ 代码编写 ➡ 构建 ➡ 测试 ➡ 部署 ➡ 发布服务三：设计 ➡ 代码编写 ➡ 构建 ➡ 测试 ➡ 部署 ➡ 发布用户角色：产品/架构开发测试运维运维/开发技术支持事件需求设计拆任务、写代码写测试用例数据变更部署/灰度上线服务、工单管理架构设计代码集成系统验证代码变更监控/告警事件、缺陷管理单元测试验证自动化测试配置变更版本归档代码扫描性能测试部署测试环境交付追踪自测、联调安全测试部署预发环境数据度量集成验证开发模式：代码验证方式：客户服务效率：部署生产环境瀑布式串行小马路单车道大爆炸集中验证数月一次响应客户 ➡ ➡ ➡ 多服务并行持续交付高速公路边开发、边验证每天多次、按需发布

10. 新的交付模式下组织架构的演进 • 小分队->全栈组合 • 分工协作->目标对齐 • 持续交付支撑->步调一致

11. Zadig 业务架构

12. Zadig 系统架构 Zadig V1.7.0 新版预计 11.15 发布

13. Zadig 设计核心 Zadig 用云原生的视角整体来看软件产品上线所需的过程，借助云原生的能力，拉起环境，捋清产品构成中微服务启停顺序、依赖关系，实现高效验证及上线，是更适用于基于微服务架构的 End-To-End 产品级交付方式。希望的脏活累活，比如服务部署、找环境，服务编排这些 Infra 的事情。

14. 开源 Zadig 企业落地实践

15. 开源 Zadig 企业落地实践案例与方案第一部分：Zadig 开箱即用典型案例实践 • 字节跳动飞书用 Gerrit/GitLab + Zadig 实现主干开发、主干发布 • 新零售独角兽“非码”用 Zadig + GitLab 实现周发布 7 次第二部分： Zadig 开源共建案例实践效能提升场景实践 • 2K+ 微服务、多语言、Helm 模版、K8s 多个集群环境治理场景实践 • 数千开发者、5 条业务线、多分支多环境协作生态开发场景实践 • 打通内外开发者工具流程，开放企业 APaaS 能力 GitHub.com/KodeRover/Zadig

16. Zadig 开箱即用的典型案例一 “Zadig 解决方案面向，可用性极高，通用性场景适配性强，重复利用度高。市面上的其他产品基本没办法解决微服务联调的问题 … 大家一般进入统一的环境里自测，但通常只会测试能想到的点， KodeRover 用自动化的方式让大家测得更全面，把事情做的质量提高，提升了测试的覆盖度。 ” 字节跳动 - 飞书 SRE 工程师

17. 字节跳动 - 飞书主干开发主干发布方案一：Gerrit + Zadig 方案二：Gitlab + Zadig 非核心服务：采用单分支模型 master发版。核心服务：采用双分支模型： master发版测试环境和 online发版生产环境。

18.

19. 字节跳动 - 飞书 G e r r i t + Z a d i g 方案工具链： • 飞书 + Gerrit + Zadig + 内部发布平台技术栈： • Go +git（yml）+多集群 K8s 分支策略： • 单分支 master 开发环境策略： • 4 套同构环境动态分配测试管理： • 500 API+E2E cases

20. “ 没有 Zadig, 我们的自动化测试不可能做起来 ” 非码测试总监 “Zadig 让运维在业务量倍增的情况下仍能轻松应对 ” 非码 DevOps 负责人

21. “ 各产品线的研发测试部署的对接都在 Zadig 上，实现对整个开发和测试的生命周期的自动化管理 ” - 七牛技术专家

22. 第二部分：Zadig + 战略伙伴开源共建案例实践效能提升场景： • 2K+ 微服务、多语言、Helm 模版、K8s 多个集群环境治理场景 • 数千开发者、5 条业务线、多分支多环境协作生态开发场景 • 打通内外开发者工具流程，开放企业 APaaS 能力

23. 效能提升场景：2K+微服务、多语言、Helm、K8s 多集群现状 1. 一堆复杂的脚本 2. Rancher 上手动替换版本 3. 测试环境不透明，总出问题 4. 每一次部署都需要产生一个 Chart 版本

24. 现状：基于 GitLab + Helm Chart 模版 + 多套 values 1. 开发流程工具链：提交代码到 Feature 分支 -> GitLab-CI 自动构建打包 Chart • GitLab （源码 + 服务 Chart 配置）（写一堆复杂的脚本）-> -> Rancher 上手动替换 Helm Chart • Rancher 部署版本 -> 调试（使用 kubectl/日志系统）分支策略： 2. 测试流程 • 合并到 develop -> GitLab-CI 自动构建打包 Chart （还是那堆复 feature -> develop/release -> master 杂的脚本）-> -> Rancher 上手动替换 Helm Chart 版本 -> 自动化/手工测试环境策略： • 3. 上线流程合并 master -> GitLab-CI 自动构建打包 Chart -> Rancher 上手动替换 Helm Chart 版本三套环境（dev、qa、prod）

25. 现状的痛点分析 1. 一堆复杂的脚本 2. Rancher 上手动替换版本 3. 测试环境不透明，总出问题 4. 每一次部署都需要产生一个 Chart 版本 1. 维护成本高 2. 交付效率大大受到影响 3. Chart 版本管理混乱

26. 效能提升场景：2K+微服务、多语言、Helm、K8s 多集群 Zadig – Helm 部署项目（Chart 模板） 1. Chart 模板库，服务配置统一化管理 2. 自动构建部署 3. 环境公开透明 4. 按需一键拉起一套测试环境

27. 效能提升场景：2K+微服务、多语言、Helm、K8s 多集群工程师体验现状 Zadig Helm 方案管理员 1. 上线服务，每个环境都配置一份服务 1. 从模板创建服务->修改少量配置更新到所有环境 values 文件 2. 创建环境，配置和环境相关少量配置 2. 创建新环境，准备所有服务 values 文件开发测试 1. Rancher 手动更新服务 1. Zadig 工作流自动更新服务 2. 调试更新配置需要打一个 Chart 包 2. Zadig 集成环境更新服务配置 3. 使用 kubectl 登入服务 3. Zadig GUI 查看实时日志、调试 1. 测试因为环境不稳定经常受影响 1. 测试自助运行，测试被管理、执行分析 2. 挂接到开发工作流中，实现开发自动化验证

28. 环境治理场景：数千开发者、5 条业务线、多分支多环境协作服务通过云厂商上了云，而配套设施并没有使用云原生方式 1. ci/cd 工具不是云原生的 2. 系统架构不是云原生的 3. 工程师缺乏云原生的技能 4. ……

29. 环境治理场景：数千开发者、5 条业务线、多分支多环境协作一系列问题（来自社区的声音）： • 数千微服务已经上了 K8s，没有业务边界，环境不稳定出了问题，所有人吃大锅饭 • 开发无法本地联调自测，集成测试环境 “脏，乱，差”极不稳定，总被其他人干扰 • 测试同时验证多个分支，集成合并冲突不断，自动化测试遥遥无期，测试全靠人工验证 • 运维无脑排障、重启、删节点，沦为工具人……

30. 环境治理场景：数千开发者、5 条业务线、多分支多环境协作 Zadig – 托管项目方案 1. 业务边界清晰 2. 权限得到控制 3. 环境公开透明 4. 更新过程可追溯演示->

31. 生态开发场景：打通内外开发者流程，开放企业 APaaS 能力零售科技公司，客户业务有定制化开发需求。所以 ISV 软件开发商和内部开发者提供开发者平台，方便内外开发者日常迭代。场景特点： 1. 一个大客户一个项目 2. 每个项目仅有两三个服务（JAVA 应用+小程序） 3. 一个 Story 一个 feature 分支，多个 feature 分支同时开发

32. 生态开发场景：打通内外开发者流程，开放企业 APaaS 能力现状及痛点描述：因为只有一个测试环境，所有的 feature 都合到 release 分支才能测试，发版期间需要把计划发布的分支合到 master 准备发布。 1. 测试的分支代码和发布是的 master 代码不一致，导致可能合到 master 后出现问题 2. 线上只能发 master，如果计划不发了，就要摘出来，会出现 master 分支被污染的问题 -> 还是环境的问题

33. 为什么要与企业做开源共建？短期“三赢” • 企业通过使用 Zadig 实现业务增长 • 开发者与开放技术链接成为开源贡献者 • Zadig 通过复杂业务场景迭代更强竞争力关于长期思考：云原生领域太大了，只有真实的业务场景才能打磨真正解决问题的好产品所以 Zadig 面向开发者 100% 开放立在打造下一代云原生时代社会化基础设施为之后商业化打下坚实基础。

34. 开源 Zadig 走进企业 - ： Zadig 负责人与企业对口人初步沟通，分析企业痛点诉求： Zadig 技术团队走进企业，与研发团队做业务场景研讨： Zadig 协助企业对口人定义开源共建目标 :Zadig 专家制定开源共建客户成功方案，成立推进小组： Zadig 专人工程师全程追踪方案实施与落地细节：定期复盘同步，安排技术交流，针对难点排障： Zadig 社区与企业共同输出开源共建成功案例

35. Zadig RoadMap 接入：安装10分钟以内，成功率达 90% 1.5 个月核心重构集成环境：支持开发者 Remote debug/ IDE 插件 65% 功能实现开源工作流：效率和性能、开发者体验提升 7月 2021年5月 1 个月功能改造 90% 功能实现开源技术社区雏形搭建建立产品发展委员会贡献者流程进一步优化稳定支撑3-5个优质开源社区开发者环境 6月 3-5 个行业领域敏感型场景 8月 10月 12月 3-5 个技术方向敏感型场景生态伙伴工具 + Zadig 贡献者流程优化 Zadig 企业交付案例场景深化

36.

37. 如何参与 Zadig 贡献 1、代码贡献（贡献指南） 2、文档贡献产品文档：https://docs.koderover.com/ 教程： https://www.koderover.com/tutorials/ 3、社区问题回答 4、场景贡献