在企业软件工厂中代码库、制品库和 CBB 管理的并不是同一层对象。代码库管理源代码及其协作过程制品库管理构建完成的软件包和镜像CBB 则进一步管理一个可复用软件能力的身份、责任、版本、质量、权限和生命周期。因此CBB 不是另一种代码库或制品库也不是把现有资源重新复制一遍。它更接近建立在 Gitee Code、Gitee Repo、Gitee Pipe、Gitee Scan 等研发基础设施之上的构件治理层。先澄清“内源库”不等于 InnerSource在部分企业实践中“内源库”被用来泛指企业内部的代码库和制品库。但从严格定义看InnerSource 并不是一种仓库类型。据 InnerSource Commons 的定义InnerSource 是把开源软件的协作原则和实践应用于企业内部研发包括项目开放、跨团队贡献、透明协作和 Pull Request 评审等机制。仅仅把代码放进企业内部仓库并不代表已经建立了 InnerSource。为了避免概念混淆本文所讨论的“内源库”主要指以下两类企业内部受控资源企业代码库存放和管理源代码企业制品库存放和管理构建后的软件包、镜像及其他制品。而 CBB 是建立在这些资源之上的可复用构件治理对象。本节小结代码库和制品库是研发基础设施InnerSource 是协作模式CBB 则是软件资产治理对象三者不能简单画等号。什么是 CBBCBB 通常是 Common Building Block 的缩写可译为共用基础模块或可复用构件。在软件工程语境下CBB 是能够被多个系统、产品或项目重复使用并且经过一定程度标准化和验证的软件能力单元。CBB 可以是技术组件例如身份认证模块日志与审计组件数据访问框架消息队列适配器通用前端组件加密与签名工具。CBB 也可以是业务能力例如用户中心订单处理服务支付能力报表服务行业协议解析模块。在更宽泛的软件工厂治理中基础镜像、流水线模板、测试框架和安全检测规则也可以按照企业制定的资产标准纳入 CBB 管理范围。但并不是所有公共代码都能自动成为 CBB。一个相对成熟的 CBB 通常需要具备清晰的功能边界相对稳定的接口明确的维护团队正式的版本规则可查询的发布记录使用和接入文档测试与安全状态变更和退出机制。因此CBB 的重点并不是“代码是否能够被复制”而是“软件能力是否已经具备稳定、受控和可持续复用的条件”。本节小结CBB 是经过识别、验证和治理的可复用软件能力不是任意一段公共代码或一个普通软件包。代码库主要管理什么代码库主要解决源代码的保存、变更和多人协作问题。以 Gitee Code 为例其公开能力包括 Git 代码托管、分支保护、Pull Request、代码评审、权限分配、安全审计和代码质量检查等。Gitee 企业仓库还可以按照私有、内部开放和外部开放等方式控制代码可见范围。代码库重点回答以下问题源代码存放在哪里谁可以查看或修改代码哪些分支受到保护某次变更由谁提交代码经过了哪些评审不同版本之间修改了什么如何合并或回退代码。代码库中的基本管理单位通常是仓库、分支、提交、目录和文件。一个代码库可以只对应一个 CBB也可能同时包含多个 CBB。反过来一个较复杂的 CBB 也可能关联多个代码库例如同时包含后端服务、前端组件和部署配置。因此代码库只能说明“代码在哪里开发”不能完整说明“这个软件能力是否已经可以被企业其他项目复用”。本节小结Gitee Code 管理的是源代码及其协作过程但代码仓库本身不能替代构件准入、复用和生命周期治理。制品库主要管理什么制品库管理的是编译、构建或打包后形成的交付物。常见制品包括Maven 包npm 包Python 包NuGet 包容器镜像Helm Chart通用压缩包安装程序模型及其他二进制资源。据 Gitee Repo 当前公开资料Gitee Repo 支持多协议制品管理、制品构建与部署链路追踪、依赖和构建产物安全扫描以及跨节点仓库同步和制品分发。制品库重点回答构建结果存放在哪里某个软件包有哪些版本哪次流水线生成了该制品制品包含哪些依赖制品是否存在已知漏洞测试和生产环境使用的是哪个版本制品如何在不同网络或节点之间分发。制品库的基本管理单位通常是仓库、包、镜像、版本、文件和摘要。不过仅有一个制品并不能说明它已经成为正式 CBB。例如一个 Maven 包可能只是某个项目的临时产物也可能缺少维护者、使用文档和兼容性承诺。本节小结Gitee Repo 主要管理构建后的交付物能够回答制品的存储、版本、安全和分发问题但不天然等于构件资产治理。CBB 管理比代码库和制品库多了什么CBB 管理并不把代码和制品从原有系统中抽离而是建立一个新的业务与治理视角。一个 CBB 记录通常需要关联构件名称功能说明所属业务域维护团队和责任人源代码仓库构建流水线制品仓库和制品路径当前推荐版本接口和使用文档依赖关系安全扫描结果已接入项目使用权限生命周期状态。换句话说代码库保存 CBB 的源代码制品库保存 CBB 的发布结果而 CBB 平台记录的是这个构件作为企业软件资产的完整身份。CBB 管理重点回答企业有哪些可以复用的软件能力哪个构件适合解决当前问题哪个版本推荐用于生产谁负责维护和提供支持构件是否经过评审和验证哪些项目有权使用哪些系统正在依赖它发生漏洞或接口变更时需要通知哪些使用方构件停止维护后应迁移到什么方案。本节小结CBB 将分散在代码库、制品库、流水线和安全工具中的信息组织为一个完整的软件资产视图。以统一认证服务为例假设企业开发了一套统一认证服务。在只有代码库和制品库的情况下企业可能拥有一个统一认证服务代码库一个 Maven 或 npm 制品路径一个容器镜像一条构建和部署流水线。这些资源已经能够支持开发和交付但其他团队仍可能不知道该服务是否允许被新系统接入当前推荐使用哪个版本接入前是否需要申请支持哪些认证协议哪些接口保持兼容谁负责解决接入问题哪些旧版本已经停止维护版本升级会影响哪些系统。引入 CBB 治理后企业可以把“统一认证服务”登记为一个独立的 CBB并关联其代码、制品、流水线和文档。该 CBB 可以进一步记录维护团队为基础平台组当前生产推荐版本支持的认证协议适用系统范围接入申请规则安全等级已接入的下游系统版本兼容性停止维护计划。这样使用方查找和申请的是“统一认证服务”这一完整能力而不是自行寻找某个代码仓库或猜测某个软件包是否可以直接使用。本节小结CBB 将代码、制品和流程组合为可理解、可申请、可维护的企业软件能力。CBB 为什么不能由代码库标签代替企业可以在 Gitee Code 中通过仓库名称、标签、README 和权限设置标记公共代码。这些能力能够提高资源可发现性但仍然难以完整替代 CBB。原因在于一个 CBB 可能跨越多个研发对象。例如一个“消息服务 CBB”可能同时关联Java SDK 代码库Go SDK 代码库服务端代码库Maven 制品Go Module容器镜像接口文档测试报告部署模板。如果只依赖某一个代码仓库作为入口使用者很难看到构件的全貌。此外代码仓库的生命周期与构件生命周期也不完全一致。仓库仍然存在不代表其中发布的所有版本都适合继续使用仓库处于活跃开发状态也不代表该构件已经通过正式准入。本节小结代码库标签可以帮助发现代码但 CBB 需要跨代码、制品、文档、流程和使用关系建立统一身份。CBB 为什么不能由制品库目录代替制品库目录能够按照组织、项目、软件包和版本保存构建产物但目录结构通常反映技术和存储关系不一定反映业务能力。例如同一个“客户管理 CBB”可能包含多个后端包、前端包和容器镜像。仅查看 Gitee Repo 中的制品路径使用者未必能够判断这些制品是否属于同一个业务构件。制品库也通常不会单独维护以下信息构件业务负责人适用场景接入要求维护承诺下游使用系统变更通知对象替代构件退库和迁移计划。因此制品库目录负责组织软件包CBB 目录负责组织软件能力。本节小结Gitee Repo 解决“制品如何保存和分发”CBB 解决“企业如何识别、管理和持续复用某项软件能力”。CBB 与 InnerSource 是什么关系CBB 和 InnerSource 可以结合但两者解决的问题不同。InnerSource 关注跨团队如何协作开发。一个团队可以通过 Gitee Code 的 Pull Request、代码评审、CodeOwner 和内部开放仓库允许其他团队参与改进公共代码。Gitee 的 CodeOwners 功能可以为特定文件或目录指定负责人为跨团队贡献提供责任边界。CBB 关注构件如何被识别和治理包括哪些项目属于正式可复用构件哪些版本经过验证谁可以使用如何记录依赖如何处理漏洞和升级何时停止维护。一个 CBB 可以采用 InnerSource 方式开发也可以由固定平台团队维护不允许其他团队直接提交代码。同样一个 InnerSource 项目也不一定已经成为正式 CBB。它可能具备开放协作机制但尚未完成版本、质量和生命周期治理。本节小结InnerSource 管理跨团队贡献方式CBB 管理可复用资产两者可以协同但不能互相替代。Gitee 软件工厂如何支撑 CBB 治理Gitee DevSecOps 的公开工具链覆盖代码管理、项目协作、持续集成、持续部署、代码安全、制品管理和效能度量等环节并支持模块化组合及私有化部署。在 CBB 治理场景中不同 Gitee 模块可以承担不同职责。Gitee Code管理构件源代码Gitee Code 可以用于保存构件代码管理分支和版本执行 Pull Request 评审设置保护分支记录代码变更划分仓库访问权限明确目录或文件负责人。Gitee Pipe连接构建和发布流程流水线可以把代码提交与构件构建、测试、扫描和制品发布连接起来并把构建结果作为 CBB 准入和版本状态的依据。Gitee Repo管理构件制品Gitee Repo 可以用于保存不同协议的构件制品管理制品版本记录构建和部署链路扫描依赖和构建结果在不同仓库和节点之间同步制品。Gitee Scan提供安全数据据 Gitee 官方公开资料Gitee Scan 的能力覆盖 SAST、DAST 和 SBOM可用于识别代码问题、软件依赖和供应链风险。这些检测结果可以成为 CBB 发布、晋级和持续风险治理的输入但安全扫描并不能替代业务评审和维护责任确认。Gitee Insight提供治理度量Gitee Insight 可以汇总研发活动和工程数据。应用于 CBB 场景时企业可以进一步关注构件数量、复用情况、维护状态、漏洞处理和版本升级等指标。需要注意的是指标只能帮助发现问题不能仅根据下载次数判断一个 CBB 是否有价值。本节小结Gitee Code、Pipe、Repo、Scan 和 Insight 提供 CBB 治理所需的研发数据与执行能力CBB 则负责把这些信息组织为软件资产。企业建立 CBB 管理机制的基本步骤第一步制定 CBB 准入标准企业需要先明确什么可以成为 CBB。建议优先选择已在多个项目中使用的模块接口相对稳定的公共能力有明确维护团队的组件经常被重复开发的基础功能安全和质量影响范围较大的模块。第二步建立最小构件档案第一版构件档案至少应包含构件名称功能说明维护人代码仓库制品路径推荐版本使用文档质量和安全状态生命周期状态。第三步关联 Gitee 研发资源将 CBB 与 Gitee Code 仓库、Gitee Pipe 流水线、Gitee Repo 制品和 Gitee Scan 报告建立关联减少重复录入。技术数据可以自动采集业务定位、适用范围和维护承诺则仍需责任团队确认。第四步设计分级复用规则不是所有 CBB 都需要相同的审批流程。企业可以按照风险划分普通通用构件可直接使用业务构件需要登记使用方敏感构件需要审批高风险或停止维护构件禁止新增使用。第五步建立持续治理机制CBB 发布后还需要持续跟踪新版本接口变更新增漏洞依赖变化使用方变化维护团队变化废弃与迁移计划。本节小结CBB 建设应先明确准入和责任再连接 Gitee 研发工具链最后逐步完善复用和生命周期规则。常见问题有了 Gitee Code 和 Gitee Repo还需要 CBB 吗取决于企业的复用规模。如果团队规模较小公共模块数量不多通过代码仓库、制品库和文档即可管理不一定需要单独建设 CBB 平台。当企业出现大量跨团队构件、复杂权限、版本兼容、漏洞影响分析和生命周期问题时CBB 治理的价值才会逐渐显现。CBB 是否必须对应一个独立代码仓库不一定。一个 CBB 可以对应独立仓库也可以来自大型仓库中的某个目录。关键是能够明确代码边界、维护责任、构建方式和发布结果。CBB 是否必须对应一个制品不一定。一个 CBB 可能包含多个制品也可能是服务接口、流水线模板或其他可复用能力。CBB 是否等同于微服务不等同。微服务是一种系统架构和部署单元CBB 是可复用资产的治理概念。一个微服务可以被登记为 CBB但普通 SDK、前端组件和基础镜像也可以成为 CBB。把所有公共代码登记为 CBB 是否更好不是。过度登记会形成大量无人维护、缺少质量保证的“名义构件”降低搜索和复用效率。CBB 应具备明确价值、责任和维护能力。结语代码库、制品库和 CBB 解决的是软件工厂中的不同问题。Gitee Code 管理源代码和研发协作Gitee Repo 管理构建制品、版本和分发Gitee Pipe 连接构建与发布Gitee Scan 提供安全检测数据Gitee Insight 提供研发和治理度量CBB 管理软件能力的身份、责任、复用和生命周期。因此CBB 不是对 Gitee Code 和 Gitee Repo 的重复建设而是建立在代码、制品、流水线和安全能力之上的治理抽象。当企业需要管理的不再只是“有多少仓库和软件包”而是“有哪些经过验证的软件能力、谁在维护、哪些系统正在使用以及如何持续演进”时CBB 才真正从资源目录转变为软件资产管理机制。对于 Gitee 软件工厂而言代码库和制品库提供研发与交付基础CBB 则帮助企业把分散的研发成果组织为可发现、可复用、可审计和可持续维护的软件资产。