摘要： DevOps 一词源于 Development 和 Operations 的组合，即将软件交付过程中开发与测试运维的环节通过工具链打通，并通过自动化的测试与监控，减少团队的时间损耗...

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

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

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

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

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

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

1. 静态代码检查

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

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

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

3. 编译并整理产物

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

利于集成的工作流设计

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

1. 流水线的组织形式

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

市面上有非常多的 CI 工具可以进行选择，仔细观察就会发现，无论是 Drone 这样的新兴轻量的工具，亦或是老牌的 Jenkins 等，都原生或通过插件方式支持了这样一个特性：Configuration as Code，即使用配置文件管理流水线。

这样做的好处是相当大的。首先，它不再需要一个 web 页面专门用于流水线管理，这对于平台方来说无疑减少了维护成本。其次对于使用方来说，将流水线配置集成在源码仓库中，享受与源码同步升级的方式，使得 CI 流程也能使用 git 的版本管理进行规范与审计溯源。

确立了流水线的组织形式后，我们还需要考虑版本的发布模式以及源码仓库的分支策略，这直接决定了我们该以什么样的方式规划流水线进行代码集成。

2. 版本发布模式的取舍

在《持续交付 2.0》一书中提到，版本发布模式有三要素：交付时间、特性数量以及交付质量。