CI/CD 是什么? 为什么要 CI/CD?
2024年1月29日
CI/CD 是由 CI (Continuous Integration 持续整合) 以及 CD (Continuous Delivery/Deployment 持续交付/部署) 两个字所组成。 虽然现在部分公司都有专门的 DevOps 工程师会负责处理 CI/CD，但许多公司仍是仰赖负责开发的工程师，例如前端、后端、全端工程师来负责处理。
在接下来三篇内容，我们会聊前后端工程师都需要知道的 CI/CD 基础概念。在这一篇文当中，我们会先来聊“为什么要有 CI/CD”。当你能更清楚理解某个技术或工具背后的脉络，会对该技术或工具更有感。
为什么要有 CI/CD
假如从历史的角度来看，CI/CD 是在软体开发史中，相对新的一个词。这个词汇的出现，是因为软体开发模式改变。假如大家还有印象，在以前软体还是用光碟片来安装的时期，软体的更新都是一次大版本的更新。对于开发者来说，是一次把完整的功能都做完、测试完，才会上线交付给使用者。
但是在时代变化下，近年来软体开发有了改变，最有名的是 2001 年时，在软体开发业界有 17 位资深专家，齐聚一堂发布了敏捷宣言(The Agile Manifesto) 倡议，进而衍伸出后来的敏捷开发，而 CI/CD 也可说是这之后出来的词汇。
敏捷宣言十二项原则
- 我们最优先的任务，是透过及早并持续地交付有价值的软体来满足客户需求。
- 竭诚欢迎改变需求，甚至已处开发后期亦然。 敏捷流程掌控变更，以维护客户的竞争优势。
- 经常交付可用的软体， 频率可以从数周到数个月， 以较短时间间隔为佳。
- 业务人员与开发者必须在专案全程中天天一起工作。
- 以积极的个人来建构专案， 给予他们所需的环境与支援， 并信任他们可以完成工作。
- 面对面的沟通是传递资讯给开发团队及团队成员之间效率最高且效果最佳的方法。
- 可用的软体是最主要的进度量测方法。
- 敏捷程序提倡可持续的开发。赞助者、开发者及使用者应当能不断地维持稳定的步调。
- 持续追求优越的技术与优良的设计， 以强化敏捷性。
- 精简 ── 或最大化未完成工作量之技艺 ── 是不可或缺的。
- 最佳的架构、需求与设计皆来自于能自我组织的团队。
- 团队定期自省如何更有效率，并据之适当地调整与修正自己的行为。
可以看到，在这个宣言下，软体开发不再是一次完成一整包后才交付，而是“及早”交付，且开发者需要持续接收回馈，根据持续演进与变化的需求持续地开发。在这个概念下，我们需要一个能够落地的具体方式，而 CI/CD 正是落地的手段之一。
CI/CD 定义
而 CI/CD 可以定义如下：
CI 是持续整合，意思是让多个开发者，能够共同在同个代码库中开发不同的新功能，然后能够持续整合到某个分支上面。之所要持续做这件事，是因为开发不同功能时，代码可能会有冲突，而持续地整合就能及早化解冲突。在 CI 的流程中，也会有自动化测试与建构，来避免等要上线前一次合并才发现有测试跑不过，或者建构有错误。
CD 则是持续交付/部署，在整合完后有自动化的部署流程。最理想的状况，是当开发者把代码合并后，就会开始整合、测试，最终部署，整个流程不需用有人工介入，一切自动化完成，新的功能就会到最端使用者手上。
总的来说，CI/CD 的出现，是软体开发往敏捷发展的脉络下而生的一种手段，透过 CI/CD 我们可以自动化地完成代码整合、交付/部署，让开发者可以专注在开发上。
读到这可能对于具体来说，CI/CD 的整个流程该长什么样子，仍觉得很模糊。我们在下一篇会进一步讨论。
补充说明: CI/CD 与 DevOps 的关系？
可能有读者会问 CI/CD 与 DevOps 的关系。在爬梳这段历史时，看到 DevOps 约是 2008 - 2009 年左右被提出；而 CI/CD 则是更早之前就有，只是后来才逐渐在业界普及。目前 CI/CD 是 DevOps 中的重要元素。可以在 Atlassian 这篇介绍看到，建置 CI/CD 流程是 DevOps 工程师的重要能力之一 连结 ，但要成为 DevOps 工程师，还需要有其他技能。