摘要
DevOps 一词源于 Development 和 Operations 的组合,即将软件交付过程中开发与测试运维的环节通过工具链打通,并通过自动化的测试与监控,减少团队的时间损耗,更加高效稳定地交付制品。
本篇文章将着重探讨 DevOps 在 持续集成阶段需要提供的能力,将对工作流的设计及流水线的优化思路做一个简要讲解。
随着项目规模越来越大,功能特性与维护人员越来越多,特性交付频率与软件质量之间的矛盾日渐尖锐,如何平衡两者成为了目前团队亟需关注的一个重点,于是,落地一个完善的 DevOps
工具链便被提上日程。
我们认为,从代码集成、功能测试,到部署发布、基础设施架构管理,每一个环节都应该有全面且完善的自动化监控手段,并尽量避免人工介入。只有这样,软件才能同时兼顾质量与效率,在提高发布频率的情况下保证可靠性。这是每一个成功的大型项目最终一定要实现的目标。
本篇文章将着重探讨 DevOps
在 持续集成阶段
需要提供的能力,将对工作流的设计及流水线的优化思路做一个简要讲解。
当我们在谈论 CI 时,我们在谈论什么
CI(Continuous Integration),即持续集成,指频繁地(一天多次)将代码集成到主干的行为。
注意,这里既包含持续将代码集成到主干的含义,也包含持续将源码生成可供实际使用的制品的过程。因此,我们需要通过 CI,自动化地保证代码的质量,并对其构建产物转换生成可用制品供下一阶段调用。
因此,在 CI 阶段,我们至少有如下阶段需要实现:
- 静态代码检查
这其中包括,ESLINT/TSLINT 静态语法检查,验证 git commit message 是否符合规范,提交文件是否有对应 owner 可以 review 等等。这些静态检查不需要编译过程,直接扫描源代码就可以完成。
- 单元测试/集成测试/E2E 测试
自动化测试这一环节是保障制品质量的关键。测试用例的覆盖率及用例质量直接决定了构建产物的质量,因此,全面且完善的测试用例也是实现持续交付的必备要素。
- 编译并整理产物
在中小型项目中,这一步通常会被直接省略,直接将构建产物交由部署环节实现。但对于大型项目来说,多次频繁的提交构建会产生数量庞大的构建产物,需要得到妥善的管理。产物到制品的建立我们接下来会有详细讲解。
利于集成的工作流设计
在正式接入 CI 前,我们需要规划好一种新的工作流,以适应项目切换为高频集成后可能带来的问题与难点。这里涉及到的改造层面非常多,除了敦促开发人员习惯的转变以及进行新流程的培训外,我们主要关心的是源码仓库的更新触发持续集成步骤的方式。
流水线的组织形式
我们需要一个合适的组织形式来管理一条 CI 流水线该在什么阶段执行什么任务。
市面上有非常多的 CI 工具可以进行选择,仔细观察就会发现,无论是 Drone 这样的新兴轻量的工具,亦或是老牌的 Jenkins 等,