Help us learn about your current experience with the documentation. Take the survey.

教程：为企业规模构建包注册表

随着组织规模的增长，包管理可能会变得越来越复杂。 GitLab 包注册表模型为企业包管理提供了强大的解决方案。了解如何利用包注册表对于安全、简单且大规模地使用包至关重要。

在本教程中，您将学习如何将 GitLab 包注册表模型整合到企业组结构中。尽管此处的示例专门针对 Maven 和 npm 包，但您可以将本教程的概念扩展到 GitLab 包注册表支持的任何包类型。

完成本教程后，您将了解如何：

开始之前

要完成本教程，您需要以下内容：

一个 npm 或 Maven 包。
熟悉 GitLab 包注册表。
一个测试项目。您可以使用现有项目，或为此教程创建一个。

了解 GitLab 包注册表

像 JFrog Artifactory 和 Sonatype Nexus 这样的传统包管理器使用单个集中式存储库来存储和更新您的包。在 GitLab 中，您直接在组或项目中管理包。这意味着：

团队将包发布到存储代码的项目中。
团队从根组注册表中消费包，该注册表聚合了其下的所有包。
访问控制继承自您现有的 GitLab 权限。

由于您的包像代码一样被存储和管理，您可以将包管理添加到现有项目或组中。此模型具有几个优势：

包与其源代码的所有权清晰
无需额外配置的细粒度访问控制
简化的 CI/CD 集成
与团队结构的自然对齐
通过根组消费使用单个 URL 访问所有公司包

创建企业结构

考虑在单个顶级组下组织您的代码。例如：

company/ (顶级组)
├── retail-division/
│   ├── shared-libraries/    # 部门特定的共享代码
│   └── teams/
│       ├── checkout/        # 团队在此发布包
│       └── inventory/       # 团队在此发布包
├── banking-division/
│   ├── shared-libraries/    # 部门特定的共享代码
│   └── teams/
│       ├── payments/        # 团队在此发布包
│       └── fraud/           # 团队在此发布包
└── shared-platform/         # 企业级共享代码
    ├── java-commons/        # 共享 Java 库
    └── ui-components/       # 共享 UI 组件

在此结构中，公司中的所有团队将代码和包发布到自己的项目中，同时继承顶级 company/ 组的配置。

设置顶级组

如果您已有顶级组并且拥有所有者角色，则可以使用它。

如果您没有组，请创建一个：

在左侧边栏顶部，选择 Create new ( ) 和 New group。
在 Group name 中，输入组的名称。
在 Group URL 中，输入组的路径，用作命名空间。
选择 visibility level。
可选。填写信息以个性化您的体验。
选择 Create group。

此组将存储您组织中的其他组和项目。如果您有其他项目和组，可以将它们转移到新的顶级组进行管理。

在继续之前，请确保您至少拥有：

一个顶级组。
属于顶级组或其子组的一个项目。

发布包

为了保持清晰的所有权，团队应该将包发布到自己的包注册表中。这使包与其源代码保持在一起，并确保版本历史与项目活动相关联。

要发布 Maven 包：

配置您的 pom.xml 文件以发布到项目的包注册表：

<!-- checkout/pom.xml -->
<distributionManagement>
    <repository>
        <id>gitlab-maven</id>
        <url>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven</url>
    </repository>
</distributionManagement>

要发布 npm 包：

配置您的 package.json 文件：

// ui-components/package.json
{
  "name": "@company/ui-components",
  "publishConfig": {
    "registry": "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/"
  }
}

消费包

由于您的项目在单个顶级组下组织，您的包仍然可以被组织访问。让我们为您的团队配置一个用于消费包的单一 API 端点。

配置您的 pom.xml 以从顶级组访问包：

<!-- 任何项目的 pom.xml -->
<repositories>
    <repository>
        <id>gitlab-maven</id>
        <url>https://gitlab.example.com/api/v4/groups/company/-/packages/maven</url>
    </repository>
</repositories>

配置您的 .npmrc 文件：

# 任何项目的 .npmrc
@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/

此配置自动提供对组织中所有包的访问，同时保持基于项目发布的优势。

添加部署令牌

接下来，我们将添加一个只读部署令牌。此令牌提供对存储在组织子组和项目中的包的访问权限，以便您的团队可以使用它们进行开发。

在您的顶级组中，在左侧边栏选择 Settings > Repository。
展开 Deploy tokens。
选择 Add token。
填写字段，并将范围设置为 read_repository。
选择 Create deploy token。

您可以根据需要向顶级组添加任意数量的部署令牌。请记住定期轮换您的令牌。如果您怀疑令牌已泄露，请立即撤销并替换它。

使用包与 CI/CD

当 CI/CD 作业需要访问包注册表时，它们使用预定义的 CI/CD 变量 CI_JOB_TOKEN 进行身份验证。此身份验证自动发生，因此您不需要进行任何额外配置：

publish:
  script:
    - mvn deploy  # 对于 Maven 包
    # 或
    - npm publish # 对于 npm 包
  # CI_JOB_TOKEN 提供自动身份验证

总结与后续步骤

将您的 GitLab 项目组织在一个顶级组下有几个好处：

简化的配置
- 所有包访问使用一个 URL
- 跨团队的一致设置
- 易于令牌轮换
清晰的所有权
- 包与其源代码保持在一起
- 团队保持对发布的控制
- 版本历史与项目活动相关联
自然的组织
- 您的组与公司结构匹配
- 团队可以在保持自主性的同时进行协作

GitLab 包注册表模型为企业包管理提供了强大的解决方案。通过结合基于项目的发布和顶级组消费，您可以获得两全其美的效果：清晰的所有权和简化的访问。

这种方法随着您的组织自然扩展，同时保持安全性和易用性。首先通过单个团队或部门实施此模型，并在看到这种集成方法的好处时进行扩展。请记住，虽然本教程专注于 Maven 和 npm，但相同的原则适用于 GitLab 支持的所有包类型。