海南众乐邦网络科技有限公司成立于 2020 年，是国内领先的灵活用工交易鉴证平台，以财税服务视角切入灵活用工场景，连接企业、灵活就业者和监管三方，开创“灵活用工+财税管理”模式，助力灵活用工实现“人、财、税”合规高效协同。
众乐邦为企业和灵活就业者提供用工衔接、酬劳结算、交易鉴证、纳税规范等一体化服务，持续助力企业实现用工成本优化、用工模式转型升级和组织管理效率提升，也帮助灵活就业者实现效能提升并合规完税。
现状
众乐邦技术团队是由一群年轻有想法的人组成，在项目成立之初，为了达到快速交付的能力，采用Kubesphere 的 DevOps 功能，主要依托 Jenkins 加 Helm 来实现应用的发版以及部署，Kubesphere 来进行统一管控。但随着环境越来越多，项目越来越多，在创建新环境都需要在 Kubesphere 上重新配置，时间和人力成本都很高。
痛点
- 多环境管理成本高
团队目前环境包括 DEV、QA、UAT、PRE、PROD，分布在 IDC 机房和公有云上，KS 在做多集群管理的时候需要在主集群和成员集群安装 KS，成本较高。
2. 新环境配置复杂
如果现在需要新开一个环境或者临时需要一个全新的环境，在 KS 上需要先创建工程，在挨个配置流水线，无法实现快速复制。
3. 管理复杂
KS 的 DevOps 我们目前使用的底座是 Jenkins，而我们使用的方式也是 Jenkins + Helm Chart 的方式。这就需要管理员同时维护 Jenkinsfile、JenkinsLibrary、Helm Chart，维护成本比较高，管理比较复杂。
4. Jenkins 本身问题
Jenkins 本身存在一些问题，比如：
- 编排引擎不稳定：Jenkins 是 JAVA 开发的，在大规模构建时，STW（Stop The World）会导致Jenkins 无法处理新的请求。
- 大量构建卡顿：Jenkins 使用磁盘文件存储数据，每条流水线、每次构建都会占用一个文件目录，产生大量文件。通常流水线数量有限，但在构建达到 10000+ 级别时，会感受到 IO 对 Jenkins 的影响。
- 并发性能差：由于 Jenkins 本身的限制，在 Kubernetes 上无法运行多个副本。基于 Kubernetes 的 Jenkins 并发量，构建并发量最多达到 400 左右时会出现明显瓶颈，继续提升需要架构层面的较大优化升级。
当然，在使用 KS 中也发现了很多优点，比如界面比较清爽，操作比较简单，门槛相对较低（毕竟Jenkins 在企业中的使用度是非常高的）。
机缘
在试用 Zadig 之前，我们尝试过其他 DevOps 工具，比如评价较高的 Gitlab-CI，更云原生的 Tekton等，在试用过程中发现都无法满足需求。
在机缘巧合下，认识了 Zadig 这个产品，而且开发总监对这个产品赞誉有加，所以决定尝试一下。
大概花了半天的时间把 Zadig 的文档看了一遍，给我最直接的感受就是： Zadig 把复杂的事情简单化了，不搞高大上的名词，也不扯虚头巴脑的流程，旨在让你以 最简单、最直接、最快速的方式投入使用。
而且能恰好解决我们的痛点：
- 多环境接入成本低，只需要在被接入环境执行一条命令即可。
- 新环境配置成本低，创建新环境可以同步创建应用，可以达到一键创建的目的。
- 不需要再单独维护 Jenkinsfile 和 JenkinsLibrary，只需要维护 Helm Chart，大大降低了维护成本。
落地
项目组是在 5 月 30 号才真正投入使用，在之前的时间里大多都是运维同学在测试、迁移，这其中也走了一些弯路。
- 刚开始把 Zadig 搭建在内网环境，在做多集群管理的时候，由于 Agent 是通过 WebSocket 的方式给Zadig 发送信息，在公有云环境的 K8s 集群由于网络问题无法发送，不得已又在公有云环境搭建新的Zadig。
- 虽然在 KS 上是采用的 Jenkins + Helm 的方式进行部署，但是有一些项目并不是，比如有一个 PHP 项目就是直接采用的 YAML 清单的方式，为了统一管理，就需要将这类项目全部改造成使用 Helm Chart 方式发布，这里占用的时间成本比较高。
好在一切都在向好的方向发展，项目组也开始投入使用 Zadig。
构建和部署效能也在不断转好。
期望
目前是处于 Zadig 使用的初期阶段，未来会将自动化测试完全接入进来，让开发->测试->运维能通过Zadig 这个平台完成闭环。
而且也会随
着 Zadig 社区不断的迭代而尝试新的功能， 年轻就要醒着拼，年轻就要勇于尝试。
期望 Zadig 越来越好， 用最简单的方式解决最复杂的问题。
