本文作者：成龙腾讯前端开发工程师，负责腾讯文档前端开发与研发效能提升，AlloyTeam成员。 导语 本篇文章将着重探讨 DevOps 在持续集成阶段需要提供的能力，将对工作流的设计及流水线的优化思路做一个简要讲解。 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》一书中提到，版本发布模式有三要素：交付时间、特性数量以及交付质量。 这三者是相互制衡的。在开发人力与资源相对固定的情况下，我们只能对其中的两个要素进行保证。 传统的项目制发布模式是牺牲了交付时间，等待所有特性全部开发完成并经历完整人工测试后才发布一次新版本。但这样会使得交付周期变长，并且由于特性数量较多，在开发过程中的不可控风险变高，可能会导致版本无法按时交付。不符合一个成熟的大型项目对于持续交付的要求。 对于持续集成的思想来说，当我们的集成频率足够高，自动化测试足够成熟且稳定时，完全可以不用一股脑地将特性全堆在一次发布中。每开发完成一个特性就自动进行测试，完成后合入等待发布。接下来只需要在特定的时间周期节点自动将已经稳定的等待中的特性发布出去即可。这对于发布频率越来越高，发布周期越来越短的现代大型项目中无疑是一个最优解。 3. 分支策略 与大部分团队一样，我们原有的开发模式也是分支开发，主干发布的思想，分支策略采用业界最成熟也是最完善的 Git-Flow 模式。 可以看出，该模式在特性开发，bug 修复，版本发布，甚至是 hotfix 方面都已经考虑到位了，是一个能应用在生产环境中的工作流。但整体的结构也因此变得极为复杂，不便管理。例如进行一次 hotfix 的操作流程是：从最新发布前使用的主干分支拉出 hotfix 分支，修复后合入到 develop 分支中，等待下一次版本发布时拉出到 release 分支中，发布完成后才能合回主干。 此外，对于 Git-Flow 的每一个特性分支来说，并没有一个严格的合入时间，因此对于较大需求来说可能合入时间间隔会很长，这样在合入主干时可能会有大量的冲突需要解决，导致项目工期无端延长。对此，做大型改造与重构的同学应该深有体会。 针对这一点，我们决定大胆采用主干开发，主干发布的分支策略。 我们要求，开发团队的成员尽量每天都将自己分支的代码提交到主干。在到达发布条件时，从主干直接拉出发布分支用于发布。若发现缺陷，直接在主干上修复，并根据需要 cherry pick 到对应版本的发布分支。 这样一来，对于开发人员来说需要的分支就只有主干和自己 working 的分支两条，只需要 push 与 merge 两条 git 命令就能完成所有分支操作。同时，由于合入频率的提高，平均每人需要解决的冲突量大大减少，这无疑解决了很多开发人员的痛点。 需要说明的是，分支策略与版本发布模式没有银弹。我们采用的策略可能并不适合所有团队的项目。提高合入频率尽快能让产品快速迭代，但无疑会让新开发的特性很难得到充分的手工测试及验证。 为了解决这一矛盾点，这背后需要有强大的基础设施及长期的习惯培养做支持。这里将难点分为如下几个类型，大家可以针对这些难点做一些考量，来确定是否有必要采用主干开发的方式。 1）完善且快速的自动化测试。只有在单元测试、集成测试、E2E 测试覆盖率极高，且通过变异测试得出的测试用例质量较高的情况下，才能对项目质量有一个整体的保证。但这需要团队内所有开发人员习惯 TDD（测试驱动开发）的开发方式，这是一个相当漫长的工程文化培养过程。 2）Owner 责任制的 Code Review 机制。让开发人员具有 Owner 意识，对自己负责的模块进行逐行审查，可以在代码修改时规避许多设计架构上的破坏性修改与坑点。本质上难点其实还是开发人员的习惯培养。 3）大量的基础设施投入。高频的自动化测试其实是一个相当消耗资源的操作，尤其是 E2E 测试，每一个测试用例都需要启动一个无头浏览器来支撑。另外，为了提升测试的效率，需要多核的机器来并行执行。这里的每一项都是较大的资源投入。 4）快速稳定的回滚能力和精准的线上及灰度监控等等。只有在高度自动化的全链路监控下，才能保证该机制下发布的新版本能够稳定运行。这里的建设我会在之后的文章里详细介绍。 大型项目中产物-