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

向 GitLab 添加新的服务组件

GitLab 产品由多个服务组件组成，这些组件作为独立的系统进程运行，彼此之间相互通信。这些服务可以在同一实例上运行，也可以分布在不同的实例上。现有组件列表可在 GitLab 架构概览中找到。

集成阶段

以下大纲重新使用了成熟度指标的命名作为示例，展示了集成组件的各种阶段。这些阶段仅与组件的实际成熟度松散关联，旨在作为实施顺序的指南。例如，一个组件无需默认启用即可成为“Lovable”（受欢迎）。默认启用本身并不会导致组件成为“Lovable”。

将新组件集成到 GitLab 的初始步骤是从在问题跟踪器中创建一个功能提案开始。

确定该组件所属的产品类别，并指定负责该类别的工程经理和产品经理。

有关从提案到发布任何 GitLab 功能的一般步骤，可参见产品开发流程。

添加新服务与其他贡献遵循相同的合并请求工作流，并且必须满足相同的完成标准。此外，还需要涵盖以下几点：

对于可与 GitLab 完全独立运行的服务：

首次迭代应是添加连接和使用该服务作为外部安装组件的能力。这通常涉及在 GitLab 中提供连接到该服务的设置，或允许其连接。然后提供关于如何安装和配置该服务以配合 GitLab 使用的文档。

Elasticsearch 是按此方式集成的服务示例。许多其他服务（包括像 Gitaly 这样的内部项目）最初都是作为单独安装的替代方案开始的。

对于依赖现有 GitLab 代码库的服务：

首次迭代应是可选的，可通过 gitlab.yml 配置或通过功能标志实现。对于这类服务，通常需要在初始集成过程中将服务和其依赖项与 GitLab 打包。

ActionCable 是按此方式添加的服务的示例。

随 GitLab 发布的代码需使用法律团队批准的许可证。请参阅现有批准的许可证列表。

添加必须编译的新依赖项时，请通知分发团队。我们必须能够在所有支持的平台上编译该依赖项。

要与 GitLab 打包的新服务需在以下环境中可用。

开发环境

打包新服务的第一步是在开发环境中提供它，以便进行协作和反馈。

标准安装方法

为了让服务能够被打包供最终用户或 GitLab.com 使用，它需要包含在标准安装方法中：

应保持依赖项最新，并跟踪安全更新。对于 Rails 代码库，JavaScript 和 Ruby 依赖项会使用 GitLab 依赖扫描扫描漏洞。

此外，Omnibus 包或云原生镜像中使用的任何系统依赖项都应添加到依赖更新自动化中。

如果该服务组件需要随每月的 GitLab 版本更新或发布，则应将其添加到发布工具自动化中。该项目由交付组维护。

有多种级别的自动化可用于将组件包含在 GitLab 月度版本中。在不同级别下将组件包含在版本中的要求和流程详见发布文档。

由发布工具管理的带有版本的项目列表可在发布工具项目目录中找到。

例如，Gitaly、GitLab Workhorse 和 GitLab Shell 的所需版本需要通过各种发布管道同步。