博客详情页
  • 下载
  • 开发
  • 文档
  • 学习
  • 支持
  • 社区
  • 动态
Repositories
EN
Repositories
EN
商业实践 | openUBMC社区开发流水线使能长江计算高质量交付

商业实践 | openUBMC社区开发流水线使能长江计算高质量交付

实践案例

2025/07/26
易重辉

商业实践 | openUBMC社区开发流水线使能长江计算高质量交付

一、引言

在软件开发流程中,构建环节至关重要,它直接影响着开发效率与软件质量。为保证openUBMC的本地化部署并提升开发效率,长江计算提出了一套面向企业开发者的构建方案与流水线构建方案。这一套基于离线部署的方案,涵盖了基础设施配置、构建方案设计等方面,有助于深入理解openUBMC构建体系的搭建与优化。

二、基础设施配置

(一) 基础设施与资源更新总览

images
基础设施结构与资源更新方法

如同大多数公司一致,长江计算的开发活动主要位于纯内网环境,因此如何将社区的基础设施与公司常用的基础设施兼容是拥抱社区的一大难题。基于常用场景,长江计算设计了一套技术解决方案,将openUBMC社区的相关开发资源,经过外网-非涉密内网-涉密内网的单向数据流形式,部署到基础设施。这样的网络架构旨在保障数据安全与开发环境的稳定性。

因安全性而引入的额外部署流程,需要通过自动化提升效率。因此,在长江计算的部署流程中,源码和Conan组件的跨网络传输均支持脚本化的方式自动化运行。

(二)基础设施配置简介

images

长江计算为 openUBMC 的本地化部署配置的基础设施具备功能完整性、易用性和安全性,为自研openUBMC商用发行版提供了坚实的技术支撑,有力地推动了BMC软件开发流程的规范化和高效化,对于其他企业开发者在构建类似的开发环境和流程方面具有一定的参考价值和借鉴意义。

三、开发者构建方案

images
构建镜像在开发者构建中的配置与使用

构建Docker镜像是开发者构建和流水线构建的基础。构建Docker镜像上传到编译服务器可直接为开发者构建服务;而上传到容器镜像仓则是为流水线构建服务。

在编译服务器上,为每位开发者创建独立编译容器,这样的设计保障了每位开发者的开发环境相对独立,避免相互干扰。

开发者可以通过SSH连接到编译容器,在容器内进行开发工作。实际场景中,开发者可以在涉密台式机环境下,借助预处理好的编译容器,专注于代码编写与调试,无需过多关注环境配置等复杂问题,从而提高开发效率。

另外,长江计算的编译容器支持个人数据持久化,同时也拥有只读公共目录。这样的设计便于后期维护时升级编译环境和开发材料传递。

四、流水线构建方案

(一)流水线需求分析

images

代码门禁需求:

  • 组件门禁流水线: 当组件代码合入时,触发门禁检查,包括静态代码检查、单元测试以及单元测试覆盖率计算等,只有通过这些检查,代码才能顺利合入,确保组件代码的质量。
  • 产品门禁流水线: 产品版本因组件版本变化时,需要进行门禁检查,主要验证是否能构建出产品包,保障产品版本的完整性和可用性。

版本构建发布需求:

  • 组件版本发布时,需构建出二进制并归档,方便后续的使用与管理。
  • 产品转测版本发布时,要构建出 hpm 包并归档,同时触发冒烟测试,初步验证产品版本的基本功能是否正常。

(二)组件流水线设计总览

images

组件仓Merge合入时,会触发组件门禁流水线,此时会拉取组件代码,执行合入门禁检查,包括 静态代码检查、单元测试和组件出包校验,将检查结果反馈给开发人员。门禁检查结果将作为是否合入的标准。

images

当涉及组件版本发布时,需要定时或者手动触发组件构建流水线,此时会拉取组件代码,进行版本构建,将组件版本发布到 Conan 仓库,实现组件的更新与共享。

(三)产品流水线设计总览

images

manifest仓代码Merge合入时,会触发产品门禁流水线,拉取组件代码,执行合入门禁检查,同时进行产品出包校验,确保能生成完整的产品包,之后可触发签名请求,保障产品安全性。

images

当涉及产品版本发布时,需要定时或者手动触发产品构建流水线,拉取组件代码,执行版本构建,发布产品版本,并进行冒烟测试,全面验证产品性能与功能

(四)流水线在软件开发过程中的模拟运用

为说明4种流水线的作用和机制,本文使用箭头表示各种类型的流水线来模拟三个组件(A、B、C)与产品的构建与发布过程。其中蓝色向下的箭头是门禁流水线,青色向右是构建流水线;黑色边框为组件流水线,红色边框是产品流水线。

images

由上图过程可知:此流水线的设计能深度贴合软件工程过程。

  • 一般多次特性合入才会发布版本: 不管是组件还是产品,历经多次门禁流水线再通过一次构建流水线来发布版本。
  • 保证产品仓一定能正常构建出版本: 只有当组件完成构建流水线发布之后,通过修改manifest仓库并合入来触发的产品门禁流水线才能成功。反之,如果组件未经过构建,那么产品门禁流水线一定会因为缺对应组件而失败报错;
  • 多组件依赖的产品版本更新: 涉及到多组件依赖的需求时,多个组件的版本更新可以在产品的一次合入请求中实现。
  • 产品仓的版本发布与组件版本发布分离: 组件通过构建流水线发布版本后,并不一定要立即合入到产品仓,完全按组件和产品自身的开发节奏进行发布和版本搭配。

通过组件门禁流水线、产品门禁流水线、组件构建流水线以及产品构建流水线的协同工作,全方位保障软件开发过程的质量与效率。门禁流水线对代码合入进行严格检查,构建流水线则负责版本的构建与发布,使得软件开发能按照既定的流程和标准顺利推进。

五、场景交流

部署场景 :企业自建 Conan 仓,需要将社区 Conan 二进制迁移到企业自己的开发环境中去。

images

images
方案一的仓库数据更新方式

方案一 :通过仓库级联,将社区 Conan 仓接入到企业本地 Conan 仓库。理论上能下载到社区所有二进制,这种方法适用于实时能和社区仓库沟通的场景,操作相对简便,但可能存在网络稳定性以及权限控制等问题。

images
方案二的仓库数据更新方式

方案二 :通过 conan download 下载,再上传到企业本地 conan 仓库。理论上也能下载到社区所有二进制。

images
方案三的仓库数据更新方式

方案三 :通过 bingo 构建来下载,再上传到本地 Conan 仓库。这种方式只能下载某个组件、产品版本依赖的二进制,针对性较强,但无法获取社区全部二进制,不过它在处理特定依赖关系时较为实用。

总之,如果能够访问到openUBMC社区的官方Conan远端,那么选择方案一做级联;如果想做离线部署,则选择方案二;如果只是需要打包特定某个组件、产品依赖的二进制,则选择方案三。

六、总结

长江计算基于 openUBMC 的开发者构建与流水线构建实践展示了完整且系统的构建流程搭建。从基础设施的合理配置到开发者构建的便捷实现,再到流水线构建的精细化设计,以及对Conan远端本地化部署的有效应对策略,都给予了openUBMC社区开发者诸多启示。在实际开发过程中,开发者可以借鉴这些实践经验,结合自身项目特点,不断优化构建体系,提升开发效率,保障软件质量,从而在激烈的市场竞争中占据有利地位,加速软件产品的交付与迭代,更好地满足用户需求与市场变化。

【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发,欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。

【免责声明】本文仅代表作者本人观点,与本网站无关。本网站对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考,由此产生的所有法律责任均由读者本人承担。

关于作者

易重辉

武汉长江计算科技有限公司BMC软件开发工程师,专注openUBMC软件开发领域,在BMC构建方面有较深入的研究与丰富的实践经验,对开发流程优化有独到见解