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

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

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

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

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

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

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

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

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

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