随着 DevOps 理念在中国企业当中的普及和发展，中国企业 DevOps 落地成熟度不断提升，根据中国信通院的数据已有近 6 成企业向全生命周期管理迈进。

而在研发全生命周期管理之中，API 管理的地位愈发显得重要。随着 API 数量的大幅增长，也带来了新的 API 管理需求。

如何在 DevOps 工作流中进行 API 全生命周期管理，对项目研发来说具有重大意义。

Part 1

DevOps 中 API 管理困境

—

在实际的 DevOps 工作流中，API 管理面临着以下 6 大方面的困境：规范、协作、自动化质量、迭代、自动化。

困境一：规范落地执行难

因为团队中的 API 文档质量参差不齐，导致规范很难落地执行。原因在于公司有很多的研发项目和团队，不同的团队有不同的API管理习惯，尤其是常用的 Swagger 方式的管理，很难进行统一的平台化管理。

针对这个困境，可以通过统一的 API 管理平台规范文档的模板，引导编写流程和习惯，也可以通过自动化文档管理工具来简化流程，提高管理效率。

困境二：岗位协作难、信息沟通效率低

在 DevOps 工具链中，每一个工具都会有不同的通知消息，导致重要信息淹没在繁杂的通知中。其次是工作流程环节多、流程长，各岗位角色处理工作节奏不一，导致任务链上下游沟通效率低。

针对这个困境，可以缩短流程环节，多启用自动化流程。同时制定精细化通知规则，根据优先级提供差异化通知样式。最后，再通过每日推送复盘消息，梳理当日工作项和消息通知，防止遗漏。

困境三：自动化测试体系搭建门槛高

传统的自动化接口测试脚本需要用 Python 来编写，门槛高，成本高。又因纯手工编写，开发变动后还须对照文档二次调整接口的所有脚本。另外，自动化测试前期投入时间多，准备工作繁杂。

针对这个困境，可以使用界面化的自动化测试工具，降低脚本编写门槛。还可以通过一站式 API 全生命周期管理平台，免去大量前期工作，提高自动化测试效率。

困境四：API 生产质量和在线异常的发现、跟踪、解决流程过长

当下，在后端的接口自测、前段的 MOCK 测试、冒烟测试、集成测试、异常监控这 5 个环节中都会使用到不同的工具，于是产生了跨工具之间对接复杂、数据隔离，导致 API 生产质量薄弱，以及大量重复工作。

可以通过一体化的 API 管理工具来打通不同环节的工作流，提高研发质量和效能。

困境五：接口文档无法跟踪迭代版本，回溯排查难度大

传统的接口管理工具如 Swagger 没有接口修改记录，缺少版本管理，无法通过日志定位问题，无法进行回滚和历史对比。另外团队也缺少接口迭代计划，导致开发量和影响面分析都难以评估。

接口文档作为研发项目的重要资产，应该对其变更进行盘点，包括提供接口文档的历史记录。可以通过一站式 API 全生命周期管理工具，提供项目级的接口版本管理和接口迭代计划，输出更加优质的接口文档，推进 DevOps 工作流的效率提升。

困境六：DevOps 工作流使用工具多

DevOps 作为宏观层面的研发管理思路，目前并没有大而全的工具，因此带来企业内部工具越积越多，数据流通阻滞，另外，传统接口管理工具功能也很单一。

针对这个问题，可以使用一体化的 API 全生命周期管理工具来实现与接口相关的所有问题，减少对接的工具数量。

Part 2

DevOps 中 API 管理需要什么

—

基于前文对 DevOps 中 API 管理存在的问题，可以梳理出企业 R&D 需要以下六个方面：

规范化：一个可配置规范、可自动根据规范生成 API 文档的 API 规范工具
高协作：一个接口相关状态自动流转、精准通知信息的 API 协作工具
自动化：一个低门槛、智能录入数据的 API 自动化测试工具
高质量：一个一站式接口全流程质量管理的 API 测试工具
迭代快：一个提供从项目级迭代计划，版本管控，到接口级历史记录的 API 管理工具
工具链：一个接口全生命周期且多种对外集成方式的 DevOps 工具

对于满足这些条件的工具，我们定义为 API 全生命周期智能协作平台。在这个一体化平台上，可以从 API 的开发态到发布态到运营态，对 API 进行全生命周期管理。

Part 3

API 全生命周期如何接入 DevOps

—

根据经典的 DevOps 流程图，我们从计划、开发、构建、测试、部署、发布、运维跟监控环节，探讨 API 管理工具对接。

3.1 计划：制定 API 文档规范，搭建层次清晰的 API 仓库

根据公司组织架构和系统服务的分布，组成一个层次清晰的接口仓库。
统一规范制定，把不同团队的规范统一制定成公司的规范。
整理公共材料，把历史文档快捷地导入到 API 仓库里，以及把一些可复用的材料例如经常用的数据结构，API 文档的模板、常用字段描述，都可以存储到 API 仓库，以便于在开发阶段创建新的 API 文档。

3.2 开发：基于代码仓库搭建自动化流程，解决前后端调试和沟通问题

基于代码仓库或 Swagger 或本地研发工具，快速自动生成 API 文档并快速调试，调试没问题后再自动生成 MOCK API和批量接口用例，可以在线分享给前端和测试，文档支持在线评论。最终还可以基于这个 API 文档生成业务代码，协助开发。

3.3 构建：自动打接口版本及自动冒烟测试，支持回滚和减轻测试工程师压力

构建阶段可以基于 CI 触发器自动构建接口版本，方便后续版本回滚，还可基于接口版本做批量测试，以及做版本差异化的对比。

这两个步骤可以让测试对任务进行评估，更好地去减轻测试的压力。目前接口上自动化能测出来的问题，可预先通过 API 测试出来。

3.4 测试：推进自动化测试，降低用例编写成本

在测试阶段我们推荐自动化测试，一体化 API 全生命周期管理工具可以去快速同步前面开发阶段生成的测试用例，然后对这些测试用例进行流程编排，组成自动化测试用例。

也可以基于 API 网关的监控日志做流量回放，自动生成自动化测试用例，识别增量接口并跑模糊测试。可以组成场景案例，做回归测试。模糊测试跟回测试的测试结果发送测试报告，给到对应的测试人员。

3.5 部署：快速测试核心流程，排除环境差异问题

部署之后可以通过 CD 触发器对环境进行预测，试跑核心的测试场景，生成对应的测试报告。可以通过多环境的测试结果进行对比，排查环境差异的问题，也可以在部署好之后进行压力测试。

注：目前 Eolink Apikit 压力测试功能将在年中上线，敬请期待！

3.6 发布：确保对外访问畅通和安全

在发布阶段，主要对接 API 网关，让系统可以正常对外访问，开放接口能力。

3.7 运维：保障服务持续稳定和安全

在运维阶段依然是使用 API 网关，做流量控制、负载均衡或服务治理。在接口开放上可以去做 Open API 调用管控，在线试用跟鉴权。在接口交易上可以去做接口托管、转发跟计算计费以及订单管理。

3.8 监控：实时观察接口运行情况，及时异常告警

可以设置标准的接口监控指标，做更加灵活的监控配置，并对告警进行规则配置预设，当满足这些告警的预设条件时就会发送消息通知，包括手机短信、主流的 IM 工具，以及 Webhook。

在消息通知方面，我们认为不仅仅需要 DevOps 主流程的对接，而是要保证整个 DevOps 信息流的有效和及时传递，因此需要对 API 文档的变更、测试报告、监控告警，进行智能分发。例如进行分级推送、智能归纳、高风险标记等。

【重磅】DevOps 工作流对接 API 全生命周期管理全流程图

Part 4

不同规模团队如何落地实施

—

4.1 大规模团队：全 DevOps 周期的接口自动化

对于大规模团队来说，推荐基于 DevOps 全周期的接口自动化方案，需部署 Eolink Apikit 私有云版本。在这个方案中，可以把 Swagger 的 URL 自动同步到 Eolink Apikit，自动生成文档，进一步基于文档生成业务代码，然后发送到代码仓库，再去触发 CI 流水线，给文档打版本，做模糊测试，并把报告发送给对应的人员。

接下来在 CD 环节部署好服务之后，可以对环境进行预测试，并根据需求做压力测试，并把测试报告发送给对应的相关人员。除了 CICD，还可以集成 Eolink 的网关产品，对 API 进行运维管理。