优维科技解构CI/CD本质：很强大但并不万能

CI/CD是什么?它如何帮助我们更快地迁移、部署?它值得我们这么兴师动众吗?本文将一探究竟。

CI/CD的全称是Continuous Integration and Continuous  Delivery,意思是持续集成和持续交付,它自动化了从最初的代码提交,一直到部署的开发过程,消除了大部分的人工干预成本。

CI/CD流程负责构建、测试和部署新代码到生产环境。Prometheus曾经这样评价:它使软件团队能够更快地部署质量更好的软件。听起来很美好,但它在真实环境中有效吗?答案是取决于系统本身的复杂性。

让我们将CI/CD拆解出来并分别讨论。CI的争议较小且更为常见。简而言之,它是使用自动化使团队能够高效、频繁地将代码更改合并到共享存储库的一种做法。每个提交都会在CI服务器上触发一个自动化工作流,该工作流运行一系列任务以确保提交可以安全地合并到主分支中。一个好的CI流程依赖于一组好的测试。维护一组具有足够覆盖率且不脆弱的测试并非易事,高测试覆盖率通常需要更长的时间才能运行,这会影响开发人员的生产力。

这是一个艰难的平衡操作,但值得付出正确的努力。

CI中常用的工具有哪些呢?一个好的源代码管理系统是一切的基础。

Github是一个非常流行的例子,它拥有构建软件所需要的一切,包括源代码、测试脚本和构建软件应用程序的脚本。

有许多工具可以管理CI流程本身。GithubActions和BuildKite是当今常见的案例,Jenkins、CircleCI和TravisCI也很普遍,这些工具主要用于管理构建和测试任务。

有许多用于编写和运行测试的测试工具,这些工具通常是特定于语言和生态系统的。

例如对于JavaScript而言,Jest是单元测试框架,而playwright和cypress则是常见的web应用程序集成测试框架。

构建工具则更加的多样化且依赖于特定的生态系统。

比如Greadle就是一款强大的Java构建工具。JavaScript构建的生态系统非常碎片化,很难跟踪。webpack是一款标准化的工具,有很多新的构建工具声称要快得多,但它们的可扩展性其实还不如webpack。

接下来我们看一下CI/CD中CD的部分。

CD就是持续部署。老实说,真正的持续部署是很难的,它确实存在,但在实践中并不具备CI那样的普遍性。

许多团队只在最基本的系统类型上练习CD。这些系统通常不会过时,例如API或Web服务器层,通过良好的生产监控,这些系统可以以最小的风险实现持续部署,不仅不会过时,而且回滚通常也非常的安全高效。将新功能包装在功能标志中,使得代码部署与功能激活分开也是一种常见的做法。它能帮助团队在新功能引发任何问题时都能快速关闭,而且无需完全回滚。大家或许都知道,对于拥有数亿用户的产品,金丝雀部署也是常见的做法。

在大规模部署新代码之前,先部署到一小部分高级用户和员工中,他们在期待新功能的同时又愿意承担风险以帮助发现bug。这允许团队在真实环境中测试新代码,同时在出现问题时限制爆炸半径。这些技术适用于简单的无状态系统。

另一方面,很少有团队有资源或信念在复杂的主要系统如数据库后端集群或其他类型的主要系统如websocket集群上实施真正的连续切换部署。

相反,这些系统通常采用固定的部署节奏,部署过程是手动的,有风险且耗时长,它们需要一个专门的团队来维护,很少看到这些系统完全连续和自动部署。

那么现在有哪些用于CD的工具呢?

我们前面提到的 Github Actions、BuildKite和Jenkins等工具通常都是用于处理 CD任务的。

还有一些特定于基础架构的工具可以使 CD更易于维护,例如在Kubernetes上,ArgoCD就很受欢迎。

总之,CI/CD是一种强大的软件开发实践,可以帮助团队更快地交付质量更好的软件。

但是,它并不是一个放之四海皆准的万能解决方案,其实现程度会因为系统的复杂性而呈现不同效果。