优维科技解构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是一种强大的软件开发实践,可以帮助团队更快地交付质量更好的软件。

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