CI 是持续集成，CD 是持续交付。
pipeline 是一个将代码开发、编译、构建、测试、部署等 Ops 活动集成起来并自动化的基础设施。它是 Ops 各种自动化工具的核心，最大的作用是对劳动力的解放。
多层次、不同阶段的测试是保证整个持续集成和持续交付的关键。
既然是自动化流程，如果在流水线上加入太多人工审核节点就失去了它的意义。
工业界和学术界项目最大的不同在于，学校里的项目是为了实现功能，而工作中的项目是为了实现工程。

单元测试

单元测试往往是由开发编写的、发生于编译阶段的测试代码。下面是单元测试的一些问题：

• 执行缓慢，缺乏快速反馈 —— 不要每次都全量跑测试、且每个测试用例时间不宜过长。
• 无法消除依赖 —— 测试用例不应该有过于复杂且依赖外部组件的逻辑，如此很难做到自动化。
• 只追求单元测试覆盖率 —— 单元测试的书写和维护是有成本的，优先覆盖核心逻辑和复杂逻辑的源代码。

集成测试

指的是系统组件之间集成起来后的功能性测试。一般放在持续集成中。

冒烟测试

冒烟测试关心的不是功能的覆盖，而是对重要功能或核心功能的保障。

CICD 的更多挑战

• 代码静态检查 —— 如 eslint 就可以用来提前检查代码问题。不过如果遇到一些无意义的改动其实不必严格遵守。工具永远是为了程序员服务的，而不是反过来。
• 依赖管理 —— 可能会遇到依赖版本冲突。一个好的依赖工具应当要具备一下特性
  • 一个抽象合理、配置简约的 DSL
  • 支持将单独的包组织成集合来简化配置
  • 支持基于版本的递归依赖
  • 支持版本冲突的选择
  • 支持不同环境的不同依赖配置
• 环境监控
  • 多维度、分级别、可视化的数据统计和监控
  • 基于监控信息的自动化操作
  • 上述模块的规则自定义和重用能力