大型前端项目 DevOps 沉思录 —— CI 篇

摘要

DevOps 一词源于 Development 和 Operations 的组合，即将软件交付过程中开发与测试运维的环节通过工具链打通，并通过自动化的测试与监控，减少团队的时间损耗，更加高效稳定地交付制品。

本篇文章将着重探讨 DevOps 在 持续集成阶段需要提供的能力，将对工作流的设计及流水线的优化思路做一个简要讲解。

随着项目规模越来越大，功能特性与维护人员越来越多，特性交付频率与软件质量之间的矛盾日渐尖锐，如何平衡两者成为了目前团队亟需关注的一个重点，于是，落地一个完善的 DevOps工具链便被提上日程。

我们认为，从代码集成、功能测试，到部署发布、基础设施架构管理，每一个环节都应该有全面且完善的自动化监控手段，并尽量避免人工介入。只有这样，软件才能同时兼顾质量与效率，在提高发布频率的情况下保证可靠性。这是每一个成功的大型项目最终一定要实现的目标。

本篇文章将着重探讨 DevOps 在 持续集成阶段 需要提供的能力，将对工作流的设计及流水线的优化思路做一个简要讲解。

当我们在谈论 CI 时，我们在谈论什么

CI(Continuous Integration)，即持续集成，指频繁地（一天多次）将代码集成到主干的行为。

注意，这里既包含持续将代码集成到主干的含义，也包含持续将源码生成可供实际使用的制品的过程。因此，我们需要通过 CI，自动化地保证代码的质量，并对其构建产物转换生成可用制品供下一阶段调用。

因此，在 CI 阶段，我们至少有如下阶段需要实现：

1. 静态代码检查

这其中包括，ESLINT/TSLINT 静态语法检查，验证 git commit message 是否符合规范，提交文件是否有对应 owner 可以 review 等等。这些静态检查不需要编译过程，直接扫描源代码就可以完成。

2. 单元测试/集成测试/E2E 测试

自动化测试这一环节是保障制品质量的关键。测试用例的覆盖率及用例质量直接决定了构建产物的质量，因此，全面且完善的测试用例也是实现持续交付的必备要素。

3. 编译并整理产物

在中小型项目中，这一步通常会被直接省略，直接将构建产物交由部署环节实现。但对于大型项目来说，多次频繁的提交构建会产生数量庞大的构建产物，需要得到妥善的管理。产物到制品的建立我们接下来会有详细讲解。

利于集成的工作流设计

在正式接入 CI 前，我们需要规划好一种新的工作流，以适应项目切换为高频集成后可能带来的问题与难点。这里涉及到的改造层面非常多，除了敦促开发人员习惯的转变以及进行新流程的培训外，我们主要关心的是源码仓库的更新触发持续集成步骤的方式。

流水线的组织形式

我们需要一个合适的组织形式来管理一条 CI 流水线该在什么阶段执行什么任务。

市面上有非常多的 CI 工具可以进行选择，仔细观察就会发现，无论是 Drone 这样的新兴轻量的工具，亦或是老牌的 Jenkins 等，