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是一种强大的软件开发实践，可以帮助团队更快地交付质量更好的软件。
但是，它并不是一个放之四海皆准的万 能解决方案，其实现程度会因为系统的复杂性而呈现不同效果。
（推广）
