[{"data":1,"prerenderedAt":821},["ShallowReactive",2],{"\u002Fzh\u002Fblogs\u002F20250726":3,"content-doc-\u002Fen\u002Fblogs\u002F20250726":423,"surround-\u002Fen\u002Fblogs\u002F20250726":819},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"date":10,"category":11,"author":12,"body":16,"_type":415,"_id":416,"_source":417,"_file":418,"_stem":419,"_extension":420,"coverImage":59,"plainText":421,"authorNames":422},"\u002Fzh\u002Fblogs\u002F20250726","blogs",false,"","商业实践 | openUBMC社区开发流水线使能长江计算高质量交付","在软件开发流程中，构建环节至关重要，它直接影响着开发效率与软件质量。为保证openUBMC的本地化部署并提升开发效率，长江计算提出了一套面向企业开发者的构建方案与流水线构建方案。这一套基于离线部署的方案，涵盖了基础设施配置、构建方案设计等方面，有助于深入理解openUBMC构建体系的搭建与优化。","2025\u002F07\u002F26","case",[13],{"name":14,"description":15},"易重辉","武汉长江计算科技有限公司BMC软件开发工程师，专注openUBMC软件开发领域，在BMC构建方面有较深入的研究与丰富的实践经验，对开发流程优化有独到见解",{"type":17,"children":18,"toc":396},"root",[19,27,34,39,45,52,62,67,72,78,85,90,96,104,109,114,119,124,130,136,143,148,174,179,192,198,205,210,217,222,228,235,240,247,252,258,263,270,275,318,323,329,334,341,349,354,362,367,375,380,385,391],{"type":20,"tag":21,"props":22,"children":24},"element","h1",{"id":23},"商业实践-openubmc社区开发流水线使能长江计算高质量交付",[25],{"type":26,"value":8},"text",{"type":20,"tag":28,"props":29,"children":31},"h2",{"id":30},"一引言",[32],{"type":26,"value":33},"一、引言",{"type":20,"tag":35,"props":36,"children":37},"p",{},[38],{"type":26,"value":9},{"type":20,"tag":28,"props":40,"children":42},{"id":41},"二基础设施配置",[43],{"type":26,"value":44},"二、基础设施配置",{"type":20,"tag":46,"props":47,"children":49},"h3",{"id":48},"一-基础设施与资源更新总览",[50],{"type":26,"value":51},"（一） 基础设施与资源更新总览",{"type":20,"tag":35,"props":53,"children":54},{},[55],{"type":20,"tag":56,"props":57,"children":61},"img",{"alt":58,"src":59,"title":60},"images","\u002Fcategory\u002Fblog\u002F20250726\u002Fimg01.webp","基础设施结构与资源更新方法",[],{"type":20,"tag":35,"props":63,"children":64},{},[65],{"type":26,"value":66},"如同大多数公司一致，长江计算的开发活动主要位于纯内网环境，因此如何将社区的基础设施与公司常用的基础设施兼容是拥抱社区的一大难题。基于常用场景，长江计算设计了一套技术解决方案，将openUBMC社区的相关开发资源，经过外网-非涉密内网-涉密内网的单向数据流形式，部署到基础设施。这样的网络架构旨在保障数据安全与开发环境的稳定性。",{"type":20,"tag":35,"props":68,"children":69},{},[70],{"type":26,"value":71},"因安全性而引入的额外部署流程，需要通过自动化提升效率。因此，在长江计算的部署流程中，源码和Conan组件的跨网络传输均支持脚本化的方式自动化运行。",{"type":20,"tag":46,"props":73,"children":75},{"id":74},"二基础设施配置简介",[76],{"type":26,"value":77},"（二）基础设施配置简介",{"type":20,"tag":35,"props":79,"children":80},{},[81],{"type":20,"tag":56,"props":82,"children":84},{"alt":58,"src":83},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg02.webp",[],{"type":20,"tag":35,"props":86,"children":87},{},[88],{"type":26,"value":89},"长江计算为 openUBMC 的本地化部署配置的基础设施具备功能完整性、易用性和安全性，为自研openUBMC商用发行版提供了坚实的技术支撑，有力地推动了BMC软件开发流程的规范化和高效化，对于其他企业开发者在构建类似的开发环境和流程方面具有一定的参考价值和借鉴意义。",{"type":20,"tag":28,"props":91,"children":93},{"id":92},"三开发者构建方案",[94],{"type":26,"value":95},"三、开发者构建方案",{"type":20,"tag":35,"props":97,"children":98},{},[99],{"type":20,"tag":56,"props":100,"children":103},{"alt":58,"src":101,"title":102},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg03.webp","构建镜像在开发者构建中的配置与使用",[],{"type":20,"tag":35,"props":105,"children":106},{},[107],{"type":26,"value":108},"构建Docker镜像是开发者构建和流水线构建的基础。构建Docker镜像上传到编译服务器可直接为开发者构建服务；而上传到容器镜像仓则是为流水线构建服务。",{"type":20,"tag":35,"props":110,"children":111},{},[112],{"type":26,"value":113},"在编译服务器上，为每位开发者创建独立编译容器，这样的设计保障了每位开发者的开发环境相对独立，避免相互干扰。",{"type":20,"tag":35,"props":115,"children":116},{},[117],{"type":26,"value":118},"开发者可以通过SSH连接到编译容器，在容器内进行开发工作。实际场景中，开发者可以在涉密台式机环境下，借助预处理好的编译容器，专注于代码编写与调试，无需过多关注环境配置等复杂问题，从而提高开发效率。",{"type":20,"tag":35,"props":120,"children":121},{},[122],{"type":26,"value":123},"另外，长江计算的编译容器支持个人数据持久化，同时也拥有只读公共目录。这样的设计便于后期维护时升级编译环境和开发材料传递。",{"type":20,"tag":28,"props":125,"children":127},{"id":126},"四流水线构建方案",[128],{"type":26,"value":129},"四、流水线构建方案",{"type":20,"tag":46,"props":131,"children":133},{"id":132},"一流水线需求分析",[134],{"type":26,"value":135},"（一）流水线需求分析",{"type":20,"tag":35,"props":137,"children":138},{},[139],{"type":20,"tag":56,"props":140,"children":142},{"alt":58,"src":141},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg04.webp",[],{"type":20,"tag":35,"props":144,"children":145},{},[146],{"type":26,"value":147},"代码门禁需求：",{"type":20,"tag":149,"props":150,"children":151},"ul",{},[152,164],{"type":20,"tag":153,"props":154,"children":155},"li",{},[156,162],{"type":20,"tag":157,"props":158,"children":159},"strong",{},[160],{"type":26,"value":161},"组件门禁流水线：",{"type":26,"value":163}," 当组件代码合入时，触发门禁检查，包括静态代码检查、单元测试以及单元测试覆盖率计算等，只有通过这些检查，代码才能顺利合入，确保组件代码的质量。",{"type":20,"tag":153,"props":165,"children":166},{},[167,172],{"type":20,"tag":157,"props":168,"children":169},{},[170],{"type":26,"value":171},"产品门禁流水线：",{"type":26,"value":173}," 产品版本因组件版本变化时，需要进行门禁检查，主要验证是否能构建出产品包，保障产品版本的完整性和可用性。",{"type":20,"tag":35,"props":175,"children":176},{},[177],{"type":26,"value":178},"版本构建发布需求：",{"type":20,"tag":149,"props":180,"children":181},{},[182,187],{"type":20,"tag":153,"props":183,"children":184},{},[185],{"type":26,"value":186},"组件版本发布时，需构建出二进制并归档，方便后续的使用与管理。",{"type":20,"tag":153,"props":188,"children":189},{},[190],{"type":26,"value":191},"产品转测版本发布时，要构建出 hpm 包并归档，同时触发冒烟测试，初步验证产品版本的基本功能是否正常。",{"type":20,"tag":46,"props":193,"children":195},{"id":194},"二组件流水线设计总览",[196],{"type":26,"value":197},"（二）组件流水线设计总览",{"type":20,"tag":35,"props":199,"children":200},{},[201],{"type":20,"tag":56,"props":202,"children":204},{"alt":58,"src":203},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg05.webp",[],{"type":20,"tag":35,"props":206,"children":207},{},[208],{"type":26,"value":209},"组件仓Merge合入时，会触发组件门禁流水线，此时会拉取组件代码，执行合入门禁检查，包括 静态代码检查、单元测试和组件出包校验，将检查结果反馈给开发人员。门禁检查结果将作为是否合入的标准。",{"type":20,"tag":35,"props":211,"children":212},{},[213],{"type":20,"tag":56,"props":214,"children":216},{"alt":58,"src":215},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg06.webp",[],{"type":20,"tag":35,"props":218,"children":219},{},[220],{"type":26,"value":221},"当涉及组件版本发布时，需要定时或者手动触发组件构建流水线，此时会拉取组件代码，进行版本构建，将组件版本发布到 Conan 仓库，实现组件的更新与共享。",{"type":20,"tag":46,"props":223,"children":225},{"id":224},"三产品流水线设计总览",[226],{"type":26,"value":227},"（三）产品流水线设计总览",{"type":20,"tag":35,"props":229,"children":230},{},[231],{"type":20,"tag":56,"props":232,"children":234},{"alt":58,"src":233},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg07.webp",[],{"type":20,"tag":35,"props":236,"children":237},{},[238],{"type":26,"value":239},"manifest仓代码Merge合入时，会触发产品门禁流水线，拉取组件代码，执行合入门禁检查，同时进行产品出包校验，确保能生成完整的产品包，之后可触发签名请求，保障产品安全性。",{"type":20,"tag":35,"props":241,"children":242},{},[243],{"type":20,"tag":56,"props":244,"children":246},{"alt":58,"src":245},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg08.webp",[],{"type":20,"tag":35,"props":248,"children":249},{},[250],{"type":26,"value":251},"当涉及产品版本发布时，需要定时或者手动触发产品构建流水线，拉取组件代码，执行版本构建，发布产品版本，并进行冒烟测试，全面验证产品性能与功能",{"type":20,"tag":46,"props":253,"children":255},{"id":254},"四流水线在软件开发过程中的模拟运用",[256],{"type":26,"value":257},"（四）流水线在软件开发过程中的模拟运用",{"type":20,"tag":35,"props":259,"children":260},{},[261],{"type":26,"value":262},"为说明4种流水线的作用和机制，本文使用箭头表示各种类型的流水线来模拟三个组件（A、B、C）与产品的构建与发布过程。其中蓝色向下的箭头是门禁流水线，青色向右是构建流水线；黑色边框为组件流水线，红色边框是产品流水线。",{"type":20,"tag":35,"props":264,"children":265},{},[266],{"type":20,"tag":56,"props":267,"children":269},{"alt":58,"src":268},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg09.webp",[],{"type":20,"tag":35,"props":271,"children":272},{},[273],{"type":26,"value":274},"由上图过程可知：此流水线的设计能深度贴合软件工程过程。",{"type":20,"tag":149,"props":276,"children":277},{},[278,288,298,308],{"type":20,"tag":153,"props":279,"children":280},{},[281,286],{"type":20,"tag":157,"props":282,"children":283},{},[284],{"type":26,"value":285},"一般多次特性合入才会发布版本：",{"type":26,"value":287}," 不管是组件还是产品，历经多次门禁流水线再通过一次构建流水线来发布版本。",{"type":20,"tag":153,"props":289,"children":290},{},[291,296],{"type":20,"tag":157,"props":292,"children":293},{},[294],{"type":26,"value":295},"保证产品仓一定能正常构建出版本：",{"type":26,"value":297}," 只有当组件完成构建流水线发布之后，通过修改manifest仓库并合入来触发的产品门禁流水线才能成功。反之，如果组件未经过构建，那么产品门禁流水线一定会因为缺对应组件而失败报错；",{"type":20,"tag":153,"props":299,"children":300},{},[301,306],{"type":20,"tag":157,"props":302,"children":303},{},[304],{"type":26,"value":305},"多组件依赖的产品版本更新：",{"type":26,"value":307}," 涉及到多组件依赖的需求时，多个组件的版本更新可以在产品的一次合入请求中实现。",{"type":20,"tag":153,"props":309,"children":310},{},[311,316],{"type":20,"tag":157,"props":312,"children":313},{},[314],{"type":26,"value":315},"产品仓的版本发布与组件版本发布分离：",{"type":26,"value":317}," 组件通过构建流水线发布版本后，并不一定要立即合入到产品仓，完全按组件和产品自身的开发节奏进行发布和版本搭配。",{"type":20,"tag":35,"props":319,"children":320},{},[321],{"type":26,"value":322},"通过组件门禁流水线、产品门禁流水线、组件构建流水线以及产品构建流水线的协同工作，全方位保障软件开发过程的质量与效率。门禁流水线对代码合入进行严格检查，构建流水线则负责版本的构建与发布，使得软件开发能按照既定的流程和标准顺利推进。",{"type":20,"tag":28,"props":324,"children":326},{"id":325},"五场景交流",[327],{"type":26,"value":328},"五、场景交流",{"type":20,"tag":35,"props":330,"children":331},{},[332],{"type":26,"value":333},"部署场景 ：企业自建 Conan 仓，需要将社区 Conan 二进制迁移到企业自己的开发环境中去。",{"type":20,"tag":35,"props":335,"children":336},{},[337],{"type":20,"tag":56,"props":338,"children":340},{"alt":58,"src":339},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg10.webp",[],{"type":20,"tag":35,"props":342,"children":343},{},[344],{"type":20,"tag":56,"props":345,"children":348},{"alt":58,"src":346,"title":347},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg11.webp","方案一的仓库数据更新方式",[],{"type":20,"tag":35,"props":350,"children":351},{},[352],{"type":26,"value":353},"方案一 ：通过仓库级联，将社区 Conan 仓接入到企业本地 Conan 仓库。理论上能下载到社区所有二进制，这种方法适用于实时能和社区仓库沟通的场景，操作相对简便，但可能存在网络稳定性以及权限控制等问题。",{"type":20,"tag":35,"props":355,"children":356},{},[357],{"type":20,"tag":56,"props":358,"children":361},{"alt":58,"src":359,"title":360},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg12.webp","方案二的仓库数据更新方式",[],{"type":20,"tag":35,"props":363,"children":364},{},[365],{"type":26,"value":366},"方案二 ：通过 conan download 下载，再上传到企业本地 conan 仓库。理论上也能下载到社区所有二进制。",{"type":20,"tag":35,"props":368,"children":369},{},[370],{"type":20,"tag":56,"props":371,"children":374},{"alt":58,"src":372,"title":373},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg13.webp","方案三的仓库数据更新方式",[],{"type":20,"tag":35,"props":376,"children":377},{},[378],{"type":26,"value":379},"方案三 ：通过 bingo 构建来下载，再上传到本地 Conan 仓库。这种方式只能下载某个组件、产品版本依赖的二进制，针对性较强，但无法获取社区全部二进制，不过它在处理特定依赖关系时较为实用。",{"type":20,"tag":35,"props":381,"children":382},{},[383],{"type":26,"value":384},"总之，如果能够访问到openUBMC社区的官方Conan远端，那么选择方案一做级联；如果想做离线部署，则选择方案二；如果只是需要打包特定某个组件、产品依赖的二进制，则选择方案三。",{"type":20,"tag":28,"props":386,"children":388},{"id":387},"六总结",[389],{"type":26,"value":390},"六、总结",{"type":20,"tag":35,"props":392,"children":393},{},[394],{"type":26,"value":395},"长江计算基于 openUBMC 的开发者构建与流水线构建实践展示了完整且系统的构建流程搭建。从基础设施的合理配置到开发者构建的便捷实现，再到流水线构建的精细化设计，以及对Conan远端本地化部署的有效应对策略，都给予了openUBMC社区开发者诸多启示。在实际开发过程中，开发者可以借鉴这些实践经验，结合自身项目特点，不断优化构建体系，提升开发效率，保障软件质量，从而在激烈的市场竞争中占据有利地位，加速软件产品的交付与迭代，更好地满足用户需求与市场变化。",{"title":7,"searchDepth":397,"depth":397,"links":398},4,[399,401,406,407,413,414],{"id":30,"depth":400,"text":33},2,{"id":41,"depth":400,"text":44,"children":402},[403,405],{"id":48,"depth":404,"text":51},3,{"id":74,"depth":404,"text":77},{"id":92,"depth":400,"text":95},{"id":126,"depth":400,"text":129,"children":408},[409,410,411,412],{"id":132,"depth":404,"text":135},{"id":194,"depth":404,"text":197},{"id":224,"depth":404,"text":227},{"id":254,"depth":404,"text":257},{"id":325,"depth":400,"text":328},{"id":387,"depth":400,"text":390},"markdown","content:zh:blogs:20250726.md","content","zh\u002Fblogs\u002F20250726.md","zh\u002Fblogs\u002F20250726","md","商业实践 | openUBMC社区开发流水线使能长江计算高质量交付 一、引言 在软件开发流程中，构建环节至关重要，它直接影响着开发效率与软件质量。为保证openUBMC的本地化部署并提升开发效率，长江计算提出了一套面向企业开发者的构建方案与流水线构建方案。这一套基于离线部署的方案，涵盖了基础设施配置、构建方案设计等方面，有助于深入理解openUBMC构建体系的搭建与优化。 二、基础设施配置 （一） 基础设施与资源更新总览  如同大多数公司一致，长江计算的开发活动主要位于纯内网环境，因此如何将社区的基础设施与公司常用的基础设施兼容是拥抱社区的一大难题。基于常用场景，长江计算设计了一套技术解决方案，将openUBMC社区的相关开发资源，经过外网-非涉密内网-涉密内网的单向数据流形式，部署到基础设施。这样的网络架构旨在保障数据安全与开发环境的稳定性。 因安全性而引入的额外部署流程，需要通过自动化提升效率。因此，在长江计算的部署流程中，源码和Conan组件的跨网络传输均支持脚本化的方式自动化运行。 （二）基础设施配置简介  长江计算为 openUBMC 的本地化部署配置的基础设施具备功能完整性、易用性和安全性，为自研openUBMC商用发行版提供了坚实的技术支撑，有力地推动了BMC软件开发流程的规范化和高效化，对于其他企业开发者在构建类似的开发环境和流程方面具有一定的参考价值和借鉴意义。 三、开发者构建方案  构建Docker镜像是开发者构建和流水线构建的基础。构建Docker镜像上传到编译服务器可直接为开发者构建服务；而上传到容器镜像仓则是为流水线构建服务。 在编译服务器上，为每位开发者创建独立编译容器，这样的设计保障了每位开发者的开发环境相对独立，避免相互干扰。 开发者可以通过SSH连接到编译容器，在容器内进行开发工作。实际场景中，开发者可以在涉密台式机环境下，借助预处理好的编译容器，专注于代码编写与调试，无需过多关注环境配置等复杂问题，从而提高开发效率。 另外，长江计算的编译容器支持个人数据持久化，同时也拥有只读公共目录。这样的设计便于后期维护时升级编译环境和开发材料传递。 四、流水线构建方案 （一）流水线需求分析  代码门禁需求： 组件门禁流水线：  当组件代码合入时，触发门禁检查，包括静态代码检查、单元测试以及单元测试覆盖率计算等，只有通过这些检查，代码才能顺利合入，确保组件代码的质量。 产品门禁流水线：  产品版本因组件版本变化时，需要进行门禁检查，主要验证是否能构建出产品包，保障产品版本的完整性和可用性。 版本构建发布需求： 组件版本发布时，需构建出二进制并归档，方便后续的使用与管理。 产品转测版本发布时，要构建出 hpm 包并归档，同时触发冒烟测试，初步验证产品版本的基本功能是否正常。 （二）组件流水线设计总览  组件仓Merge合入时，会触发组件门禁流水线，此时会拉取组件代码，执行合入门禁检查，包括 静态代码检查、单元测试和组件出包校验，将检查结果反馈给开发人员。门禁检查结果将作为是否合入的标准。  当涉及组件版本发布时，需要定时或者手动触发组件构建流水线，此时会拉取组件代码，进行版本构建，将组件版本发布到 Conan 仓库，实现组件的更新与共享。 （三）产品流水线设计总览  manifest仓代码Merge合入时，会触发产品门禁流水线，拉取组件代码，执行合入门禁检查，同时进行产品出包校验，确保能生成完整的产品包，之后可触发签名请求，保障产品安全性。  当涉及产品版本发布时，需要定时或者手动触发产品构建流水线，拉取组件代码，执行版本构建，发布产品版本，并进行冒烟测试，全面验证产品性能与功能 （四）流水线在软件开发过程中的模拟运用 为说明4种流水线的作用和机制，本文使用箭头表示各种类型的流水线来模拟三个组件（A、B、C）与产品的构建与发布过程。其中蓝色向下的箭头是门禁流水线，青色向右是构建流水线；黑色边框为组件流水线，红色边框是产品流水线。  由上图过程可知：此流水线的设计能深度贴合软件工程过程。 一般多次特性合入才会发布版本：  不管是组件还是产品，历经多次门禁流水线再通过一次构建流水线来发布版本。 保证产品仓一定能正常构建出版本：  只有当组件完成构建流水线发布之后，通过修改manifest仓库并合入来触发的产品门禁流水线才能成功。反之，如果组件未经过构建，那么产品门禁流水线一定会因为缺对应组件而失败报错； 多组件依赖的产品版本更新：  涉及到多组件依赖的需求时，多个组件的版本更新可以在产品的一次合入请求中实现。 产品仓的版本发布与组件版本发布分离：  组件通过构建流水线发布版本后，并不一定要立即合入到产品仓，完全按组件和产品自身的开发节奏进行发布和版本搭配。 通过组件门禁流水线、产品门禁流水线、组件构建流水线以及产品构建流水线的协同工作，全方位保障软件开发过程的质量与效率。门禁流水线对代码合入进行严格检查，构建流水线则负责版本的构建与发布，使得软件开发能按照既定的流程和标准顺利推进。 五、场景交流 部署场景 ：企业自建 Conan 仓，需要将社区 Conan 二进制迁移到企业自己的开发环境中去。   方案一 ：通过仓库级联，将社区 Conan 仓接入到企业本地 Conan 仓库。理论上能下载到社区所有二进制，这种方法适用于实时能和社区仓库沟通的场景，操作相对简便，但可能存在网络稳定性以及权限控制等问题。  方案二 ：通过 conan download 下载，再上传到企业本地 conan 仓库。理论上也能下载到社区所有二进制。  方案三 ：通过 bingo 构建来下载，再上传到本地 Conan 仓库。这种方式只能下载某个组件、产品版本依赖的二进制，针对性较强，但无法获取社区全部二进制，不过它在处理特定依赖关系时较为实用。 总之，如果能够访问到openUBMC社区的官方Conan远端，那么选择方案一做级联；如果想做离线部署，则选择方案二；如果只是需要打包特定某个组件、产品依赖的二进制，则选择方案三。 六、总结 长江计算基于 openUBMC 的开发者构建与流水线构建实践展示了完整且系统的构建流程搭建。从基础设施的合理配置到开发者构建的便捷实现，再到流水线构建的精细化设计，以及对Conan远端本地化部署的有效应对策略，都给予了openUBMC社区开发者诸多启示。在实际开发过程中，开发者可以借鉴这些实践经验，结合自身项目特点，不断优化构建体系，提升开发效率，保障软件质量，从而在激烈的市场竞争中占据有利地位，加速软件产品的交付与迭代，更好地满足用户需求与市场变化。",[14],{"_path":424,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":425,"description":426,"date":10,"category":11,"author":427,"body":430,"_type":415,"_id":814,"_source":417,"_file":815,"_stem":816,"_extension":420,"coverImage":464,"plainText":817,"authorNames":818},"\u002Fen\u002Fblogs\u002F20250726","Business Practice | How the openUBMC Community Development Pipeline Drives High-Quality Delivery for Yangtze Computing","In software development, the build phase is critical because it directly impacts development efficiency and software quality. To support local deployment of openUBMC and improve development efficiency within the enterprise, Yangtze Computing has introduced a developer build solution and a pipeline build solution. The offline deployment–based solutions cover infrastructure configuration and build system design, helping gain a deep understanding of how to construct and optimize the openUBMC build system.",[428],{"name":14,"description":429},"BMC software development engineer at Wuhan Yangtze Computing Technology Co., Ltd., who is dedicated to openUBMC software development and has extensive expertise in BMC build and valuable insights for optimizing development processes.",{"type":17,"children":431,"toc":798},[432,437,443,447,453,459,467,472,477,483,490,495,501,509,514,519,524,529,535,541,548,553,576,581,594,600,607,612,619,624,630,637,642,649,654,660,665,672,677,720,725,731,736,743,751,756,764,769,777,782,787,793],{"type":20,"tag":21,"props":433,"children":435},{"id":434},"business-practice-how-the-openubmc-community-development-pipeline-drives-high-quality-delivery-for-yangtze-computing",[436],{"type":26,"value":425},{"type":20,"tag":28,"props":438,"children":440},{"id":439},"introduction",[441],{"type":26,"value":442},"Introduction",{"type":20,"tag":35,"props":444,"children":445},{},[446],{"type":26,"value":426},{"type":20,"tag":28,"props":448,"children":450},{"id":449},"infrastructure-configuration",[451],{"type":26,"value":452},"Infrastructure Configuration",{"type":20,"tag":46,"props":454,"children":456},{"id":455},"_1-infrastructure-and-resource-update-overview",[457],{"type":26,"value":458},"(1) Infrastructure and Resource Update Overview",{"type":20,"tag":35,"props":460,"children":461},{},[462],{"type":20,"tag":56,"props":463,"children":466},{"alt":58,"src":464,"title":465},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg01-en.png","Infrastructure and resource update method",[],{"type":20,"tag":35,"props":468,"children":469},{},[470],{"type":26,"value":471},"Like many companies, Yangtze Computing conducts most of its development in a pure intranet environment. A key challenge is making community infrastructure compatible with the enterprise's internal systems. To address this, Yangtze Computing has designed a technical solution that deploys openUBMC community resources through unidirectional data flows. Data moves from the Internet to the non-confidential intranet and then to the confidential intranet. This network design ensures both data security and development environment stability.",{"type":20,"tag":35,"props":473,"children":474},{},[475],{"type":26,"value":476},"Due to security requirements, additional deployment procedures have been introduced. To improve efficiency, automation is essential. Therefore, in Yangtze Computing's deployment process, the cross-network transfer of source code and Conan is fully automated via scripting.",{"type":20,"tag":46,"props":478,"children":480},{"id":479},"_2-infrastructure-configuration",[481],{"type":26,"value":482},"(2) Infrastructure Configuration",{"type":20,"tag":35,"props":484,"children":485},{},[486],{"type":20,"tag":56,"props":487,"children":489},{"alt":58,"src":488},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg02-en.png",[],{"type":20,"tag":35,"props":491,"children":492},{},[493],{"type":26,"value":494},"The infrastructure Yangtze Computing sets up for the localized openUBMC deployment is complete, user-friendly, and secure. It provides strong technical support for their commercial release of openUBMC and helps streamline the BMC software development process. It also provides guidance for other enterprise developers building similar development environments and workflows.",{"type":20,"tag":28,"props":496,"children":498},{"id":497},"_3-developer-build-solution",[499],{"type":26,"value":500},"3 Developer Build Solution",{"type":20,"tag":35,"props":502,"children":503},{},[504],{"type":20,"tag":56,"props":505,"children":508},{"alt":58,"src":506,"title":507},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg03-en.png","Configuring and using build images",[],{"type":20,"tag":35,"props":510,"children":511},{},[512],{"type":26,"value":513},"Docker images form the foundation for both manual developer builds and automated pipeline builds. Uploading Docker images to a compile server allows developers to directly build services. Uploading Docker images to a container image repository enables pipelines to build services automatically.",{"type":20,"tag":35,"props":515,"children":516},{},[517],{"type":26,"value":518},"On a compile server, an independent compile container is created for each developer. This design isolates each developer's environment to prevent cross-interference.",{"type":20,"tag":35,"props":520,"children":521},{},[522],{"type":26,"value":523},"Developers can connect to the compile containers through SSH and carry out development. In practice, they can use pre-configured compile containers in a secure desktop environment, allowing them to focus on coding and debugging without worrying about environment setup.",{"type":20,"tag":35,"props":525,"children":526},{},[527],{"type":26,"value":528},"In addition, Yangtze Computing's compile containers support personal data persistence and include a read-only public directory. This design simplifies upgrades to the compilation environment and the transfer of development materials during maintenance.",{"type":20,"tag":28,"props":530,"children":532},{"id":531},"_4-pipeline-build-solution",[533],{"type":26,"value":534},"4 Pipeline Build Solution",{"type":20,"tag":46,"props":536,"children":538},{"id":537},"_1-pipeline-requirement-analysis",[539],{"type":26,"value":540},"(1) Pipeline Requirement Analysis",{"type":20,"tag":35,"props":542,"children":543},{},[544],{"type":20,"tag":56,"props":545,"children":547},{"alt":58,"src":546},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg04-en.png",[],{"type":20,"tag":35,"props":549,"children":550},{},[551],{"type":26,"value":552},"Code gated check-in requirements:",{"type":20,"tag":149,"props":554,"children":555},{},[556,566],{"type":20,"tag":153,"props":557,"children":558},{},[559,564],{"type":20,"tag":157,"props":560,"children":561},{},[562],{"type":26,"value":563},"Component gated check-in pipeline",{"type":26,"value":565},": When component code is merged, the gated check-in pipeline is triggered, performing static code analysis, unit tests, and unit test coverage calculation. Code can be successfully merged only after passing these checks, ensuring high code quality.",{"type":20,"tag":153,"props":567,"children":568},{},[569,574],{"type":20,"tag":157,"props":570,"children":571},{},[572],{"type":26,"value":573},"Product gated check-in pipeline",{"type":26,"value":575},": When a product version changes due to component updates, a gated check-in is performed to verify that the product package can be built, ensuring the integrity and availability of the product version.",{"type":20,"tag":35,"props":577,"children":578},{},[579],{"type":26,"value":580},"Version build and release requirements:",{"type":20,"tag":149,"props":582,"children":583},{},[584,589],{"type":20,"tag":153,"props":585,"children":586},{},[587],{"type":26,"value":588},"When a component version is released, its binary files must be built and archived to support subsequent use and management.",{"type":20,"tag":153,"props":590,"children":591},{},[592],{"type":26,"value":593},"When a test version is released, an HPM package must be built and archived. Additionally, a smoke test is triggered to preliminarily verify that the basic product functions are working correctly.",{"type":20,"tag":46,"props":595,"children":597},{"id":596},"_2-component-pipeline-design-overview",[598],{"type":26,"value":599},"(2) Component Pipeline Design Overview",{"type":20,"tag":35,"props":601,"children":602},{},[603],{"type":20,"tag":56,"props":604,"children":606},{"alt":58,"src":605},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg05-en.png",[],{"type":20,"tag":35,"props":608,"children":609},{},[610],{"type":26,"value":611},"When code is merged into the component repository, the component gated check-in pipeline is triggered. The component code is pulled and subjected to checks, including static code analysis, unit tests, and component package verification. The results are sent to the development team, and the gated check-in outcome determines whether the code can be merged.",{"type":20,"tag":35,"props":613,"children":614},{},[615],{"type":20,"tag":56,"props":616,"children":618},{"alt":58,"src":617},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg06-en.png",[],{"type":20,"tag":35,"props":620,"children":621},{},[622],{"type":26,"value":623},"When a component version is ready for release, the component build pipeline is triggered either periodically or manually. The component code is pulled for version building, and the resulting version is released in the Conan repository to enable component updates and sharing.",{"type":20,"tag":46,"props":625,"children":627},{"id":626},"_3-product-pipeline-design-overview",[628],{"type":26,"value":629},"(3) Product Pipeline Design Overview",{"type":20,"tag":35,"props":631,"children":632},{},[633],{"type":20,"tag":56,"props":634,"children":636},{"alt":58,"src":635},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg07-en.png",[],{"type":20,"tag":35,"props":638,"children":639},{},[640],{"type":26,"value":641},"When code is merged into the Manifest repository, the product gated check-in pipeline is triggered. It pulls the component code, verifies whether the code can be merged, and checks the packaging conditions to ensure that a complete package can be generated. Subsequently, a signature request can be triggered to ensure product security.",{"type":20,"tag":35,"props":643,"children":644},{},[645],{"type":20,"tag":56,"props":646,"children":648},{"alt":58,"src":647},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg08-en.png",[],{"type":20,"tag":35,"props":650,"children":651},{},[652],{"type":26,"value":653},"When a product version is released, the product build pipeline is triggered either periodically or manually. It pulls the component code, builds and releases the version, and performs smoke tests to verify product performance and functionality.",{"type":20,"tag":46,"props":655,"children":657},{"id":656},"_4-simulation-of-pipelines-in-software-development",[658],{"type":26,"value":659},"(4) Simulation of Pipelines in Software Development",{"type":20,"tag":35,"props":661,"children":662},{},[663],{"type":26,"value":664},"To illustrate the functions and mechanisms of the four pipelines, this blog uses arrows to represent each pipeline type, simulating the build and release processes for three components (A, B, and C) and their associated products. Specifically, the blue downward arrow represents the gated check-in pipeline, the cyan rightward arrow represents the build pipeline, the arrow with black border represents the component pipeline, and the arrow with red border represents the product pipeline.",{"type":20,"tag":35,"props":666,"children":667},{},[668],{"type":20,"tag":56,"props":669,"children":671},{"alt":58,"src":670},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg09-en.png",[],{"type":20,"tag":35,"props":673,"children":674},{},[675],{"type":26,"value":676},"As shown in the preceding figure, the pipeline design closely aligns with the software engineering process.",{"type":20,"tag":149,"props":678,"children":679},{},[680,690,700,710],{"type":20,"tag":153,"props":681,"children":682},{},[683,688],{"type":20,"tag":157,"props":684,"children":685},{},[686],{"type":26,"value":687},"Version release after multiple iterations of feature integration",{"type":26,"value":689},": For both components and products, a version is released through a build pipeline after passing several gates.",{"type":20,"tag":153,"props":691,"children":692},{},[693,698],{"type":20,"tag":157,"props":694,"children":695},{},[696],{"type":26,"value":697},"Assurance of versions built from the product repository",{"type":26,"value":699},": The product gated check-in pipeline succeeds only after the components have been released through the build pipeline and the changes have been merged into the Manifest repository. If the components are not built, the product gated check-in pipeline will fail and an error is reported indicating the missing components.",{"type":20,"tag":153,"props":701,"children":702},{},[703,708],{"type":20,"tag":157,"props":704,"children":705},{},[706],{"type":26,"value":707},"Update of multiple component dependencies",{"type":26,"value":709},": When a requirement involves several component dependencies, their version updates can be incorporated in a single merge request.",{"type":20,"tag":153,"props":711,"children":712},{},[713,718],{"type":20,"tag":157,"props":714,"children":715},{},[716],{"type":26,"value":717},"Separation between product and component version releases",{"type":26,"value":719},": After a component version is released through the build pipeline, it does not need to be immediately merged into the product repository. Instead, the version can be released and aligned according to the respective development pace of the component and the product.",{"type":20,"tag":35,"props":721,"children":722},{},[723],{"type":26,"value":724},"The component gated check-in pipeline, product gated check-in pipeline, component build pipeline, and product build pipeline work together to ensure the quality and efficiency of software development. The gated check-in pipelines strictly control code merging, while the build pipelines handle building and releasing versions. Together, they ensure that software development proceeds smoothly in accordance with the defined processes and standards.",{"type":20,"tag":28,"props":726,"children":728},{"id":727},"_5-scenario-specific-solutions",[729],{"type":26,"value":730},"5 Scenario-specific Solutions",{"type":20,"tag":35,"props":732,"children":733},{},[734],{"type":26,"value":735},"Deployment scenario: An enterprise builds a Conan repository and plans to migrate Conan binary files from the community repository to its own development environment.",{"type":20,"tag":35,"props":737,"children":738},{},[739],{"type":20,"tag":56,"props":740,"children":742},{"alt":58,"src":741},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg10-en.png",[],{"type":20,"tag":35,"props":744,"children":745},{},[746],{"type":20,"tag":56,"props":747,"children":750},{"alt":58,"src":748,"title":749},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg11-en.png","Repository data update in solution 1",[],{"type":20,"tag":35,"props":752,"children":753},{},[754],{"type":26,"value":755},"Solution 1: Establish a connection between the community Conan repository and the enterprise's local Conan repository using repository cascading. Theoretically, all binary files can be downloaded from the community repository. This approach works in scenarios where real-time communication with the community repository is possible. While the process is straightforward, it may be impacted by network stability and permission controls.",{"type":20,"tag":35,"props":757,"children":758},{},[759],{"type":20,"tag":56,"props":760,"children":763},{"alt":58,"src":761,"title":762},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg12-en.png","Repository data update in solution 2",[],{"type":20,"tag":35,"props":765,"children":766},{},[767],{"type":26,"value":768},"Solution 2: Run Conan download to download the files and upload them to the enterprise's local Conan repository. Theoretically, all binary files can be downloaded from the community repository.",{"type":20,"tag":35,"props":770,"children":771},{},[772],{"type":20,"tag":56,"props":773,"children":776},{"alt":58,"src":774,"title":775},"\u002Fcategory\u002Fblog\u002F20250726\u002Fimg13-en.png","Repository data update in solution 3",[],{"type":20,"tag":35,"props":778,"children":779},{},[780],{"type":26,"value":781},"Solution 3: Use bingo to download the files and upload them to the local Conan repository. In this approach, only the binary files required by a specific component or product version can be downloaded, limiting access to all other binaries in the community. However, this approach is practical for handling specific dependencies.",{"type":20,"tag":35,"props":783,"children":784},{},[785],{"type":26,"value":786},"In short, if you have access to the official Conan repository of the openUBMC community, choose Solution 1 for cascading. For offline deployment, opt for Solution 2. If you only need to package the binary files required by a specific component or product, go with Solution 3.",{"type":20,"tag":28,"props":788,"children":790},{"id":789},"_6-summary",[791],{"type":26,"value":792},"6 Summary",{"type":20,"tag":35,"props":794,"children":795},{},[796],{"type":26,"value":797},"The openUBMC-based developer build and pipeline build practices at Yangtze Computing showcase a comprehensive and systematic build process. Developers within the openUBMC community have drawn significant inspiration from well-structured infrastructure configuration, seamless developer build implementation, a well-designed pipeline build, and efficient approaches to Conan's remote-local deployment. Throughout the development process, developers can leverage this experience and project-specific insights to continually optimize the build system, enhance development efficiency, and maintain high software quality. As a result, developers are better positioned to succeed in the competitive market, speed up software delivery and iteration, and better address user needs and market demands.",{"title":7,"searchDepth":397,"depth":397,"links":799},[800,801,805,806,812,813],{"id":439,"depth":400,"text":442},{"id":449,"depth":400,"text":452,"children":802},[803,804],{"id":455,"depth":404,"text":458},{"id":479,"depth":404,"text":482},{"id":497,"depth":400,"text":500},{"id":531,"depth":400,"text":534,"children":807},[808,809,810,811],{"id":537,"depth":404,"text":540},{"id":596,"depth":404,"text":599},{"id":626,"depth":404,"text":629},{"id":656,"depth":404,"text":659},{"id":727,"depth":400,"text":730},{"id":789,"depth":400,"text":792},"content:en:blogs:20250726.md","en\u002Fblogs\u002F20250726.md","en\u002Fblogs\u002F20250726","Business Practice | How the openUBMC Community Development Pipeline Drives High-Quality Delivery for Yangtze Computing Introduction In software development, the build phase is critical because it directly impacts development efficiency and software quality. To support local deployment of openUBMC and improve development efficiency within the enterprise, Yangtze Computing has introduced a developer build solution and a pipeline build solution. The offline deployment–based solutions cover infrastructure configuration and build system design, helping gain a deep understanding of how to construct and optimize the openUBMC build system. Infrastructure Configuration (1) Infrastructure and Resource Update Overview  Like many companies, Yangtze Computing conducts most of its development in a pure intranet environment. A key challenge is making community infrastructure compatible with the enterprise's internal systems. To address this, Yangtze Computing has designed a technical solution that deploys openUBMC community resources through unidirectional data flows. Data moves from the Internet to the non-confidential intranet and then to the confidential intranet. This network design ensures both data security and development environment stability. Due to security requirements, additional deployment procedures have been introduced. To improve efficiency, automation is essential. Therefore, in Yangtze Computing's deployment process, the cross-network transfer of source code and Conan is fully automated via scripting. (2) Infrastructure Configuration  The infrastructure Yangtze Computing sets up for the localized openUBMC deployment is complete, user-friendly, and secure. It provides strong technical support for their commercial release of openUBMC and helps streamline the BMC software development process. It also provides guidance for other enterprise developers building similar development environments and workflows. 3 Developer Build Solution  Docker images form the foundation for both manual developer builds and automated pipeline builds. Uploading Docker images to a compile server allows developers to directly build services. Uploading Docker images to a container image repository enables pipelines to build services automatically. On a compile server, an independent compile container is created for each developer. This design isolates each developer's environment to prevent cross-interference. Developers can connect to the compile containers through SSH and carry out development. In practice, they can use pre-configured compile containers in a secure desktop environment, allowing them to focus on coding and debugging without worrying about environment setup. In addition, Yangtze Computing's compile containers support personal data persistence and include a read-only public directory. This design simplifies upgrades to the compilation environment and the transfer of development materials during maintenance. 4 Pipeline Build Solution (1) Pipeline Requirement Analysis  Code gated check-in requirements: Component gated check-in pipeline : When component code is merged, the gated check-in pipeline is triggered, performing static code analysis, unit tests, and unit test coverage calculation. Code can be successfully merged only after passing these checks, ensuring high code quality. Product gated check-in pipeline : When a product version changes due to component updates, a gated check-in is performed to verify that the product package can be built, ensuring the integrity and availability of the product version. Version build and release requirements: When a component version is released, its binary files must be built and archived to support subsequent use and management. When a test version is released, an HPM package must be built and archived. Additionally, a smoke test is triggered to preliminarily verify that the basic product functions are working correctly. (2) Component Pipeline Design Overview  When code is merged into the component repository, the component gated check-in pipeline is triggered. The component code is pulled and subjected to checks, including static code analysis, unit tests, and component package verification. The results are sent to the development team, and the gated check-in outcome determines whether the code can be merged.  When a component version is ready for release, the component build pipeline is triggered either periodically or manually. The component code is pulled for version building, and the resulting version is released in the Conan repository to enable component updates and sharing. (3) Product Pipeline Design Overview  When code is merged into the Manifest repository, the product gated check-in pipeline is triggered. It pulls the component code, verifies whether the code can be merged, and checks the packaging conditions to ensure that a complete package can be generated. Subsequently, a signature request can be triggered to ensure product security.  When a product version is released, the product build pipeline is triggered either periodically or manually. It pulls the component code, builds and releases the version, and performs smoke tests to verify product performance and functionality. (4) Simulation of Pipelines in Software Development To illustrate the functions and mechanisms of the four pipelines, this blog uses arrows to represent each pipeline type, simulating the build and release processes for three components (A, B, and C) and their associated products. Specifically, the blue downward arrow represents the gated check-in pipeline, the cyan rightward arrow represents the build pipeline, the arrow with black border represents the component pipeline, and the arrow with red border represents the product pipeline.  As shown in the preceding figure, the pipeline design closely aligns with the software engineering process. Version release after multiple iterations of feature integration : For both components and products, a version is released through a build pipeline after passing several gates. Assurance of versions built from the product repository : The product gated check-in pipeline succeeds only after the components have been released through the build pipeline and the changes have been merged into the Manifest repository. If the components are not built, the product gated check-in pipeline will fail and an error is reported indicating the missing components. Update of multiple component dependencies : When a requirement involves several component dependencies, their version updates can be incorporated in a single merge request. Separation between product and component version releases : After a component version is released through the build pipeline, it does not need to be immediately merged into the product repository. Instead, the version can be released and aligned according to the respective development pace of the component and the product. The component gated check-in pipeline, product gated check-in pipeline, component build pipeline, and product build pipeline work together to ensure the quality and efficiency of software development. The gated check-in pipelines strictly control code merging, while the build pipelines handle building and releasing versions. Together, they ensure that software development proceeds smoothly in accordance with the defined processes and standards. 5 Scenario-specific Solutions Deployment scenario: An enterprise builds a Conan repository and plans to migrate Conan binary files from the community repository to its own development environment.   Solution 1: Establish a connection between the community Conan repository and the enterprise's local Conan repository using repository cascading. Theoretically, all binary files can be downloaded from the community repository. This approach works in scenarios where real-time communication with the community repository is possible. While the process is straightforward, it may be impacted by network stability and permission controls.  Solution 2: Run Conan download to download the files and upload them to the enterprise's local Conan repository. Theoretically, all binary files can be downloaded from the community repository.  Solution 3: Use bingo to download the files and upload them to the local Conan repository. In this approach, only the binary files required by a specific component or product version can be downloaded, limiting access to all other binaries in the community. However, this approach is practical for handling specific dependencies. In short, if you have access to the official Conan repository of the openUBMC community, choose Solution 1 for cascading. For offline deployment, opt for Solution 2. If you only need to package the binary files required by a specific component or product, go with Solution 3. 6 Summary The openUBMC-based developer build and pipeline build practices at Yangtze Computing showcase a comprehensive and systematic build process. Developers within the openUBMC community have drawn significant inspiration from well-structured infrastructure configuration, seamless developer build implementation, a well-designed pipeline build, and efficient approaches to Conan's remote-local deployment. Throughout the development process, developers can leverage this experience and project-specific insights to continually optimize the build system, enhance development efficiency, and maintain high software quality. As a result, developers are better positioned to succeed in the competitive market, speed up software delivery and iteration, and better address user needs and market demands.",[14],[820,820],null,1784971460882]