Zadig 完成 100% 开源：开启软件交付 3.0 时代

经历过流程驱动的 1.0 时代，工具驱动的 2.0 时代的，软件开发已经进入到数字业务驱动的 3.0 时代，成为企业生存的命脉。“要想富，先修路” 。开源云原生软件交付产品 Zadig，就是要把路修到企业的门口，让软件工程师不再做修「高速公路」的脏活累活，而是专注自己最擅长的事情：打造业务的数字化「跑车」！阅读 KodeRover 原文

自 7 月初 V1.2.0 版本发布，Zadig 产品完成了 100% 开源，Zadig 能帮我做什么？Zadig 是如何帮助工程师走出 “开发 5 分钟，上线 2 小时” 的窘境？Zadig 的设计原理又是什么、好在哪里、适合你吗？

两位创始人 Landy 和 Grant Zadig 出镜，为您解析 Zadig

今天，软件交付需要新的思路

我的合伙人 Grant 是个 90 年代中期的老程序员，那个年代他们做像三国演义、西游记这样的 PDA 手游, 1 个开发，1 个 QA, 1 个美工，1 个月搞定，代码封版后烧到 IC 卡里插入 PDA 只能自己玩。而今天手游是上百人经年累月共同开发的结果，复杂度指数级上升。不仅仅游戏，线上化已经在各行各业发生；试想，软件的复杂度指数级提高了，可大多数企业还在沿用 20 年前的开发模式？怎么快？

今天的软件，已经广泛采用微服务架构；微服务让写代码更高效，但验证代码的复杂度也随之变高，实际上，按大多数企业目前的方式，开发的一半时间都花在了写代码之外的事务上。这就好像要_特斯拉不仅造最好的电动车，还要连带修路_，是不是很匪夷所思？

现实开发中，把代码发上线就有大量类似修路的脏活累活，比如服务调试、服务间的联调、集成验证、环境准备、发布测试等；其中尤其测试环境不稳定且不够用，大家要互相等待，软件无法稳定、快速迭代。

验证软件需要新的思路，我们是这样思考的：

新技术带来什么新机遇？比如，随着容器技术成熟，K8s NS 能支持一键环境拉起，并行构建、自动部署发布服务。
微服务架构能给软件交付的系统性设计带来什么新想法？目前大多数企业沿用的工具原先只是服务于代码上线流程中的某一个小环节（Jenkins 之于构建；GitLab 之于代码仓，等等），而微服务盛行的今天，为什么不能从软件产品交付的全局过程入手，设计出更适用于基于微服务架构的、产品级的交付方式呢？

正是这些云原生时代的新生事物，让我们 KodeRover 研发团队看到了软件交付新的未来！

今天，你需要属于云原生时代的软件交付框架

Zadig 是 KodeRover 团队基于 K8s 技术自主研发的 CI/CD 产品，是面向微服务产品全局交付的企业级云原生解决方案。我们专注解决一个问题：如何彻底消除软件验证难的痛点。通过在头条、腾讯、七牛云、非码等企业的多年上千次迭代，今天的 Zadig 已经成为微服务架构的最佳软件交付方案，帮助企业一步到位拥有强大的软件工程交付基建，让你的软件团队不再疲于奔命，一举成为企业的明星，核心，盈利中心！

Zadig 把验证软件的脏活累活都给干了

今天，软件开发最脏最累的活是准备环境验证代码，也正是 Zadig 特别擅长的地方。Zadig 面向的用户是开发、测试、运维工程师。通过使用 Zadig 提供的云原生验证基建，开发工程师写完代码后可以做服务的自动构建、部署、Debug 自测、服务联调等；测试工程师可以做自动化测试管理、运行、分析，提供自动化验证工作流，把微服务的测试验证提前；运维工程师可以给整个研发团队提供微服务管理、服务编排和环境治理能力。

在头条、腾讯、七牛云、非码等企业的长期实践显示，用上 Zadig 后，工程师开始在开发中引入自动化能力，在不延长工作日的情况下，有效开发时间成倍增长、软件产品的 Bug 率显著下降、稳定性提升、迭代加速明显，大家也更开心了。

在今天的数字时代，数字业务快速增长、创新盈利没那么难：工程师开心，软件迭代效率高、质量好，这就是秘籍了。

Zadig 设计思路：以开发者为中心，用新技术、新视角

工具的设计，出发点很重要。Zadig 设计之初，我们从大家在做微服务交付时的痛点出发，让工程师全面聚焦业务软件的创新迭代，不再在上线操作的脏活累活上花废时间，比如服务部署、找环境，服务编排这些 Infra 的事情。Zadig 用云原生的视角整体来看软件产品上线所需的过程，借助云原生的能力，拉起环境，捋清产品构成中微服务起停顺序、依赖关系，实现高效验证及上线。Zadig 设计是更适用于基于微服务架构的 End-To-End 产品级交付方式。

相比之下

Jenkins, GitLab 等相关工具起源于解决开发过程中某一环节的效率问题，基于这些工具做交付，主要是在 Jenkins / Gitlab 产品上做扩展，工程师实际上仍要在 infra 相关的事情上花大量时间。
云厂商们大多数从流程和管理工具上入手，做大一统平台，提供全家桶服务，对企业来讲，流程改造负担会比较重，同时也存在一定的厂商锁定风险。
开源社区当下也有很多优秀的面向单点的通用工具或者框架，比如云原生领域的 Tekton/Argo、OAM/kubvela，不过这些主要还是面向从运维和基础设施视角出发的，灵活性强，但需要大量的二次开发，学习成本还是比较高的。

今天，Zadig 是唯一无需工程师们做 Infra 相关的脏活累活，面向微服务产品全局交付的企业级云原生解决方案。

Zadig 的几大特色

Zadig 是以产品为交付单元：产品是由很多微服务组成，微服务的代码和配置可以来自不同的代码仓和项目，Zadig 能够基于 Kubernetes NS 一键复制环境，处理服务启停顺序，服务共享、微服务依赖处理等，其他方案完全无法解决这些痛点。
Zadig 对于工程师更轻松友好：直接面向一线开发者，没有额外使用学习负担，无需理解 CI/CD 概念，其中环境一键拉起和微服务联调、自动验证是亮点。
Zadig 面向生态友好，广泛集成优秀工具：我们相信开放的力量，社区有大量的优秀工具正被开发者使用，Zadig 不企图解决所有问题，只做最擅长的交付部分，广泛对接生态伙伴，比如需求工具 Jira、构建工具像 Jenkins/GitLab CI、部署工具 Helm、一些压测服务 tekin、安全工具等。Zadig 希望做好软件交付的连接者，帮助业务快速迭代的同时，服务好开发者。
还有一点很重要：Zadig 经过标杆客户像字节、七牛、非码、腾讯等快速发展优秀企业的成功验证，是一款企业级的、可行性被验证的成熟方案。

Zadig 是怎么工作的呢？业务架构图如下

使用 Zadig 的迁移成本高吗？

要把 Zadig 用起来，十分简单：几乎是免迁移无缝对接，Zadig 原生支持现在主流的工具 Jenkins/GitHub/GitLab 和众多云厂商，且我们系统本身不定义任何范式，实现真正的云原生不绑定，换句话来说，用户觉得不好用随时可以离开，工程师用起来其实是无感的，不用关注系统的存在，在 IDE/代码仓级别就能自动构建、部署、验证。当然企业现有环境复杂多样，我们也非常乐意走进企业做技术交流来丰富我们的理解。

Zadig：软件交付 3.0 时代的迭代利器

通观整个软件交付历史，我们的观察和总结，把软件交付分为三个时代：

1.0 流程驱动时代：像 IBM 早期 IPD 流程推的工具，国外像 ca，electric cloud；以流程串工具和人，大部分以平台形式存在。
2.0 工具驱动时代：基于单点工具提升交付能力，比如过去几年交付领域 Artifacts 管理厂商 Jfrog、CI 工具 Jenkins、面向运维侧的 Tekton/Argo 等，交付链条中某个环节的效率为主。
3.0 数字业务驱动时代：伴随 2017 年以来容器技术蓬勃发展和微服务架构的广泛应用，如今的企业，数字化业务占比越来越高，软件交付也进入了以_交付数字业务、重视开发者体验_为驱动力的 3.0 时代。新的工具只有被开发者原生地接受并热爱，软件交付才能真正地变快变稳，推动以数字形态为主的产品交付。

弯道超车迈入软件交付 3.0 时代：Zadig 邀请您开源共建

Zadig 的出现并非偶然。当年，我们调研了大量开源工具，发现国内外都没有成熟的方案来解决我们急迫的迭代问题；Zadig 初具雏形后，又经过在典型的标杆企业例如七牛、字节飞书、非码多年的成功验证，才让我们今天能推到开源社区给大家使用。到目前为止 Zadig 已经完成了 100% 开源。放眼全球，软件交付正在经历方法和工具的全面升级换代，而我们观察到中国的互联网企业具备全球最复杂的业务场景和迭代速度，今天，我们邀请您，中国企业的开发者，管理者，积极参与到软件交付 3.0 开源共建，共同打造出自中国，领先世界的云原生交付产品。

关于 Zadig

通过在包括头条、腾讯、七牛云、非码等企业的多年上千次迭代，今天的 Zadig 已经成为微服务 + Kubernetes 技术栈团队的最佳研发交付方案，同时无缝兼容任何研发团队现有交付工具链和研发流程，无缝集成 GitHub/GitLab、Jenkins、多家云厂商，帮助团队一步到位打造强大的 DevOps 和 CI/CD 工程基建能力，变云原生为生产力。

Zadig 本身是基于 Kubernetes 设计、研发的开源分布式持续交付 (Continues Delivery) 产品，为开发者提供云原生运行环境，支持开发者本地联调、微服务并行构建和部署、集成测试等。Zadig 内置了面向 Kubernetes、Helm、云主机、大体量微服务等复杂业务场景的最佳实践，为工程师一键生成自动化工作流。