CI/CD 中的 CI 流程中该包含什么?
2024年3月26日
前篇文章我们提到 CI 是持续整合，意思是让多个开发者，能够共同在同个代码库中开发不同的新功能，然后能够持续整合到某个分支上面。之所要持续做这件事，是因为开发不同功能时，代码可能会有冲突，而持续地整合就能及早化解冲突。
CI 流程会在代码推到远端分支后开始
一般来说，CI 流程会在代码推到远端分支后开始。现代的 CI 工具，会在代码推到远端分支后，由 CI 的伺服器完整跑过整个 CI 流程。而现代软体开发团队的 CI 流程，做的不仅仅是确保代码合并没有冲突。大家可以稍微回想一下，在自己的代码被部署之前，还会做什么?
多数人应该第一直觉会说是 Code Review。而在 Code Review 之前有许多能够自动化被检查的东西，也会被放在 CI 的流程中。举例来说，常见的包含代码格式化检查、代码静态检查。
代码格式化检查
代码格式化检查在做的事情，是统一代码的格式规范，例如 JavaScript 的 Prettier。很多工程师会喜欢用两格缩排，另外有些人喜欢四格，与其在 Code Review 花时间争论要两格还是四格，团队可以直接有规范，然后在 CI 的时候用格式化检查的工具，来扫过代码，确保每个有符合团队设定的格式风格。
静态检查
同样地静态检查工具，会对代码做静态分析，然后扫过代码，确保有符合团队所设立的相关规则，或者有符合程式语言的规则。举例来说，TypeScript 的 TSLint 会帮忙检查代码是否符合 TypeScript 的规则。很多工程师自己没注意到的，很可能在静态检查被找出来，这能避免有问题的代码被合并。
自动化测试
除了上面提到的两项检查，多数团队也会在 CI 流程中，加入自动化测试的环节。包含单元测试、整合测试、E2E 测试，如果新推到远端分支的代码，没有通过任一项测试，CI 工具就会报错，并且推送通知给相关人员。透过这方式，我们能确保代码在合并前，有经过完整的测试，这样能确保代码的正确性与品质有被兼顾到。
顺利被建构
当然除了上面提到的这些各类检测，CI 中的最重要环节之一，是确保代码能够被编译以及建构。为了确保不会浪费运算资源，通常会是在上面这些检测都通过后，才会建构。而要能顺利被建构，代码才能被部署。
在业界，许多软体开发团队会在 CI 当中加入其他更精细的检测，例如针对安全 (security) 做检测，避免写出有潜在漏洞的代码；或者对效能 (performance) 做检测，来确保代码的效能有达到一定的门槛。你可以针对团队的需求，在 CI 中加入各类自动化做的检测，确保团队的工程品质能维持。
而回到 CI 最核心的作用，是透过自动化的方式，让工程师可以在把代码推到远端分支后，不用自己手动，就能完成这些重要的检测，并完成代码的整合。
