企业官网建设流程全解析

在企业软件工厂中，代码库、制品库和 CBB 管理的并不是同一层对象。
代码库管理源代码及其协作过程，制品库管理构建完成的软件包和镜像，CBB 则进一步管理一个可复用软件能力的身份、责任、版本、质量、权限和生命周期。
因此，CBB 不是另一种代码库或制品库，也不是把现有资源重新复制一遍。它更接近建立在 Gitee Code、Gitee Repo、Gitee Pipe、Gitee Scan 等研发基础设施之上的构件治理层。
先澄清：“内源库”不等于 InnerSource
在部分企业实践中，“内源库”被用来泛指企业内部的代码库和制品库。但从严格定义看，InnerSource 并不是一种仓库类型。
据 InnerSource Commons 的定义，InnerSource 是把开源软件的协作原则和实践应用于企业内部研发，包括项目开放、跨团队贡献、透明协作和 Pull Request 评审等机制。仅仅把代码放进企业内部仓库，并不代表已经建立了 InnerSource。
为了避免概念混淆，本文所讨论的“内源库”主要指以下两类企业内部受控资源：

• 企业代码库：存放和管理源代码；
• 企业制品库：存放和管理构建后的软件包、镜像及其他制品。
  而 CBB 是建立在这些资源之上的可复用构件治理对象。
  本节小结：代码库和制品库是研发基础设施，InnerSource 是协作模式，CBB 则是软件资产治理对象，三者不能简单画等号。
  什么是 CBB？
  CBB 通常是 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 则帮助企业把分散的研发成果组织为可发现、可复用、可审计和可持续维护的软件资产。