持续集成平台的构建调度提升与实践

「这是我参与2022首次更文挑战的第2天，活动详情查看：2022首次更文挑战」

概述

在过去的一年时间里，我们公司打造了适合于自身特色的持续集成平台，并实现了持续集成与持续部署的全自动化。随着公司的业务的飞速发展，尤其是各种小程序业务的拓展，日平均构建部署量直线上升。随着构建部署规模的迅速增长，构建调度成为了这一环节的核心优化点。本文将会基于持续集成的现状，详细讲解实现构建调度的原因和方式。

构建部署现状

随着业务的发展，构建部署规模的增长，持续集成平台遭遇了一些痛点问题，主要有以下几点：

1. 由于过度依赖于jenkins，采用jenkins的自动分配机制，导致构建任务堵塞，耗时过长；

2. 早期设计考虑不够完善，预检任务不断触发，导致资源的过度占用与浪费；

3. 构建部署分为测试、Q1、灰度、线上，由于没有权重的概念，导致线上构建任务排在后面，无法快速上线。尤其是在紧急修复线上bug的时候，这个问题尤其难受；

4. 资源利用不均匀，导致部分机器占用率高，部分机器占用率低。

构建调度选型

鉴于以上种种问题，我们经过可行性分析之后，决定采用服务端调度的方式来替代jenkins自动分配的方式，将队列机制和分配机制放到服务端进行管控，这样就可以在合理利用资源，提升构建效率的同时，实现优先构建通道。

构建调度设计方案

1. 核心队列

• 创建统一的任务调度中心，只负责进行构建任务的推入和推出。

• 在做任务的推入的时候需要做去重处理

• 优先使用利用率低的构建节点

• 正常情况下是采用新的构建任务覆盖旧的构建任务，特殊情况下（带有独有标记），采用两者并存的方式，不做去重处理。

2. 巡检任务

为了保证任务调度的稳定性和准确性，我们使用了巡检任务来守护构建调度。通过巡检任务将意外的构建任务清除，保证任务的流畅。

• 动态更新节点信息，节点离线异常告警，获取节点的动态增减

• 清理异常构建任务

• 主动触发任务调度，清理构建队列

未来规划

目前，只是构建调度的初级版本，我们后期会进一步优化，主要有以下几点：

• 优化队列权重，不同环境的构建部署在不同条件下赋予不同的权重

• 利用缓存，提高构建任务利用率，提升性能

• 添加构建错误告警机制，达到阈值终止任务的构建并告警