Rocky Linux 基础设施团队成功解决了开源发行版交付过程中最令人头疼的瓶颈之一。通过彻底改造“构建后暂存同步”（post-compose staging sync）工作流程，开发人员将从构建完成到同步至暂存环境（staging）的总耗时缩短至原来的极小一部分，从而确保用户能以更快的速度获取安全补丁和软件更新。
长期以来，将更新从 Rocky 的主要构建系统 Koji 推送并同步到暂存仓库的过程一直以缓慢著称。
原本理论上仅需简单的文件复制操作，在每次发布周期中却往往演变成长达四到五个小时的漫长煎熬，导致关键更新期间出现令人烦恼的排队积压。
原有的工作流程分为两个截然不同的阶段。首先，团队运行 Pungi 工具，从 Koji 提取最新构建的软件包并将其组织成一个新的“构建集”（compose）。
虽然生成该构建集大约需要一小时，且缩短此耗时需要进行更深层次的架构调整，但真正的瓶颈其实存在于第二阶段——即构建完成后的暂存同步过程。
在同步阶段，新软件包会被复制到存放旧版本软件包的暂存路径中，随后进行完整的元数据重新生成、勘误信息（errata）收集以及 GPG 签名。深入分析发现，利用 `createrepo_c` 重新生成元数据的过程占据了整个三到四小时耗时的大部分时间。即便使用了该工具的 `--update` 标志，程序仍被迫扫描所有仓库中每一个新更新的软件包。
工程团队意识到，既然现有软件包的有效元数据已完整存在于暂存目录树中，那么从零开始重新生成所有元数据完全是多此一举。这解决方案既直观又具有技术挑战性：将新的构建集元数据直接与现有的暂存元数据进行合并。
为此，团队从零编写了自定义库来处理模块化元数据（modularity metadata）的合并，从而绕过了 `mergerepo_c` 等传统工具的局限性。此前，模块化元数据必须手动注入 Git 仓库——这一过程既脆弱又容易出错，也是过去几个月 Rocky Linux 出现大部分模块化相关 Bug 的主要原因。而新的自动化合并代码彻底消除了 Git 仓库带来的额外开销。
此次流水线重构带来的实际性能提升令人惊叹。构建后的 Staging 环境同步耗时从原本的 3–4 小时大幅缩短至仅需 20–25 分钟。
因此，涵盖构建与同步的端到端流水线总耗时也从最长 5 小时降至约 90 分钟，这对发布工程团队而言是一次巨大的胜利。
除了速度上的显著提升，企业系统管理员还获得了一个更加可靠的软件交付渠道。如今，安全更新和点版本（point release）软件包能够以极快的速度完成验证、签名并发布至边缘镜像节点，同时大幅降低了模块化软件包树构建过程中出现人为错误的风险。
展望未来，Rocky Linux 基础设施贡献者们的脚步并未就此停歇。其长期计划包括重构初始构建流程，旨在实现构建耗时与更新软件包总大小之间的线性扩展，从而为未来的企业级版本发布打造更加精简高效的流水线。
