极狐GitLab 17.0 重点功能解读

沿袭我们的月度发版机制，今天我们正式发布极狐GitLab 17.0。此次发布带来众多功能更新，包括CI/CD  目录的正式发布、价值流仪表盘中的 AI 影响分析、引入部署细节页面等。

以下是此次版本发布的一些重点功能更新详情，请查阅。

17.0 容器镜像

如果通过镜像安装，那么 17.0 的容器镜像为：

registry.gitlab.cn/omnibus/gitlab-jh:17.0.0-jh.0

如果通过 Helm Chart 进行云原生安装，对应的 Helm Chart 为：

helm search repo gitlab-jh
NAME                   	CHART VERSION	APP VERSION	DESCRIPTION
gitlab-jh/gitlab       	8.0.0        	v17.0.0    	GitLab is the most comprehensive AI-powered Dev...
gitlab-jh/gitlab-runner	0.65.0       	17.0.0     	GitLab Runner

17.0 重要改进

CI/CD 目录和组件已经正式可用（GA）

CI/CD 目录现在已经正式可用。作为此版本的一部分，我们还将 CI/CD 组件和输入变为正式可用。

有了 CI/CD 目录，你就可以访问由社区和行业专家创建的海量组件。无论你是在寻找持续集成、部署流水线或者自动化任务的解决方案，你都会发现很多不同的且可以满足你需求的组件。关于目录和组件的详情，你可以阅读这篇博文。

欢迎大家贡献更多优质的组件，让 CI/CD 目录丰富起来，方便其他用户快速构建高质量流水线。

价值流仪表盘中的 AI 影响分析

在价值流仪表盘中的 AI 分析是一个能够帮助组织了解极狐GitLab AI 产品对其生产力影响的一个仪表盘。这个新的月度对比度量视图将 AI 使用趋势和 SDLC（软件开发生命周期）度量标准，诸如前置事件、循环周期、DORA 以及漏洞进行比较。软件研发管理者可以使用 AI 影响仪表盘来衡量在端到端的工作流中节省了多少时间，同时还能聚焦在业务产出而不是研发活动上。

在这第一个版本中，AI 使用量以每月代码建议的使用率来衡量，计算方式是将每月独特的代码建议用户数除以总的每月独特贡献者数。

在 Linux Arm 上安装 Runner

我们很高兴地宣布，我们在极狐GitLab SaaS（JihuLab.com）上引入了 Linux Arm 版本的 Runner。当前支持 medium和 largeArm 机器类型，相当于 4 vCPU 和 8 vCPU，而且和极狐GitLab 深度集成，这能够让你应用的构建、测试比以往更快、更省。

我们决定提供业界最快的 CI/CD 构建速度并且希望看到团队的反馈周期在缩短，最终快速交付高质量软件。

引入部署详情页面

现在你可以直接链接到极狐GitLab 的某个部署上。之前，如果你们在一个部署上进行协作，你不得不从部署列表中查找部署。因为有海量的部署列表，找到合适的部署是非常困难而且容易出错。

从极狐GitLab 17.0 开始，极狐GitLab 提供了一个可以直接链接过去的部署详情视图。在这首次版本中，部署详情页面提供了一个详情，里面包含部署的作业以及在持续交付设置中对部署进行批准、拒绝或者添加注释。我们正在探索进一步增强部署详情页面的方法，包括从相关的流水线作业链接到它。

价值流仪表盘中新的使用率概览面板

我们用一个概览面板强化了价值流仪表盘。这个新的视图解决了管理层对软件交付性能洞察的诉求，而且给出了一个极狐GitLab 在软件研发全生命周期的全局视图。

概览面板会展示群组级别的指标，诸如群组/子群组、项目、用户、议题、合并请求以及流水线的数量。

将群组添加到 CI/CD 作业令牌允许列表中

自极狐GitLab 15.9 引入的 CI/CD 作业令牌允许列表有效阻止了其他项目对于你自有项目的非授权访问。之前，你只能允许来自其他特定项目的访问，并且最多限制为 200 个项目。

在极狐GitLab 17.0 中，你可以将群组添加到 CI/CD 作业令牌允许列表中。现在，200 的上限同时适用于项目和组，这意味着项目允许列表现在可以授权最多200个项目和组访问。此项改进使得添加与组关联的大量项目变得更加容易。

使用 rules:existsCI/CD 关键字来加强上下文控制

rules:existsCI/CD 关键字的默认行为与关键字的定义位置有关，因此在一些比较复杂的流水线中就很难使用此关键字了。当其定义在作业中时，rules:exists会在正运行流水线的项目中搜索特定的文件。然而，当其定义在 include部分中时，rules:exists会项目的配置文件中搜索特定的文件，而这些配置文件需要包含 include部分。如果配置文件被分割为多个文件和项目，那么就会很难确信到底去哪个项目中搜索定义好的文件。

在此版本中，我们为 rules:exists引入了子关键字 project和 ref，能够帮助你显式地控制对于此关键字的搜索上下文。这些新的子键帮助你通过精确指定搜索上下文，减少不一致性，并增强你流水线规则定义中的清晰度，确保规则评估的准确性。

使用 Switchboard 做配置变更时的变更日志（仅限GitLab）

现在，可以使用 Switchboard 配置页面查看对你的极狐GitLab 专用实例基础设施所做的配置更改的状态。

所有能够查看或编辑 Switchboard 上租户的用户，都将能够查看变更日志中的变更，并跟踪他们在应用到实例时的进展情况。

当前，Switchboard 配置页面和变更日志可用于诸如通过将IP添加到允许列表来管理对实例的访问或配置实例的SAML设置等变更。

我们将在接下来的季度扩展这项功能，以便为其他配置启用自动更新。

17.0 的其他改进

使用 REST API 开启在极狐GitLab 中查看 Jira 议题功能

在此版本中，你可以使用 REST API 来开启在极狐GitLab 中查看 Jira 议题功能。你还可以指定一个或者更多 Jira 项目来查看议题的来源。

指示那些通过直接转移导入的条目

你可以使用直接转移来在极狐GitLab 实例之间进行群组和项目的迁移。

直到现在，导入的条目都不太容易被识别。在此版本中，我们为通过直接转移导入的条目添加了可视化指示器，其中创建者被识别为特定用户：

• 注释（系统注释和用户评论）
• 议题
• 合并请求
• 史诗
• 设计
• 片段
• 用户个人资料活动

在极狐GitLab 上查看来自多个 Jira 项目的议题

对于大型仓库来说，当你设置了 Jira 议题集成后，就可以在极狐GitLab 上查看来自多个 Jira 项目的议题。

• 输入最多100个Jira项目键，用逗号分隔。
• Jira 项目值为空则表示会包含所有可用的值。

当你在极狐GitLab 上查看 Jira 议题时，你可以通过项目来过滤议题。

为了在极狐GitLab 旗舰版中为漏洞创建 Jira 议题，你可以只指定一个 Jira 项目。

加强史诗删除保护

我们已经更新了删除史诗时的操作，以便更好的保护项目结构和数据。这一切都是想让用户在管理项目的时候能给他们更多的控制和思考时间。

现在，当你删除一个父史诗时，我们不再自动删除其所有子记录，而是首先解除父级关系，以保留这些子记录。此项变更能够让你以更安全的方式来管理史诗，确保误删除不会导致有价值数据的丢失。

里程碑和迭代在议题看板上的可视化

我们已经改进了议题看板以便为你提供一个关于你项目时间线和阶段的清晰洞察。现在，有了在议题卡片上直接显示的里程碑和迭代详情，你就可以很轻松地对团队工作量进行追踪和调整了。此项强化的设计目的是为了让你的计划和执行更加高效，让你保持在循环中并领先于计划。

简化的价值流仪表板配置文件结构

现在，你可以通过使用一个简化的结构驱动的自定义 UI 框架来自定义价值流仪表盘了。在新的格式中，字段提供了展示数据以及仪表盘面板层级布局的更多灵活性。有了这个新的框架，管理员可以随时追踪仪表盘的变更。这些版本历史可以帮助你回退到之前的版本，并且对仪表盘的不同版本进行对比。

有了这个自定义特性，决策者就可以更加聚焦在与业务相关的信息上了，同时团队还能够更好的组织和展示他们的关键 DevSecOps 指标。

针对极狐GitLab UI 提交的提交签名

之前，极狐GitLab 的页面提交和自动提交都没办法进行签名。现在，针对私有化部署版本，你可以使用签名 key、提交者名称以及邮箱地址来为页面和自动提交进行签名。

始终对取消的作业执行 after_script命令

after_scriptCI/CD 关键字被用来运行作业中主 script部分之后的额外命令。这通常被用来清理环境或者作业使用到的一些资源。然而，如果作业被取消，那么 after_script之后的命令就不会运行。

在极狐Gitlab 17.0 中，当作业被取消后，after_script中的命令依旧会执行。

已发布的 CI/CD 组件语义版本范围

当使用一个 CI/CD 目录组件时，你可能想要它自动使用最新的版本。比如，你也并不想去手动监控你所使用的组件，而且在其每次有小版本更新或者安全补丁发布后手动将其修改到下一个版本。但是使用 ~latest有时也是有危险的，小版本的发布可能会有一些非期望行为的变更，而且主版本的更新可能会因为一些破坏性的变更而具有更高的使用风险。

在此版本中，你可以选择使用某个 CI/CD 组件的最新主版本或者小版本。比如，指定以 2主版本的组件版本，你会得到与此主版本相关的所有更新，比如 2.1.1、2.1.2、2.2.0，但是没有 3.0.0。如果指定 2.1的话，你将只能获得那些与小版本相匹配的更新，比如 2.1.1、2.1.2但是没有 2.2.0。

Filter package registry UI for packages with errors

你可以使用极狐GitLab 内置的软件包仓库来发布和上传镜像。有时候，会因为一些错误导致软件包上传失败。之前，没有什么快速的方式来查看上传失败的软件包。如果想要对整个组织的软件包仓库有一个整体了解，这种情况下就会显得比较困难。

现在你可以在软件包仓库 UI 上对上传失败的软件包进行过滤了。此项改进能够让你更容易调研或者解决遇到的问题。

在 FIPS 模式下支持极狐GitLab Kubernetes agent

从极狐GitLab 17.0 开始，在Kubernetes 组件启用的情况下，可以使用 agent 在 FIPS 模式下安装极狐GitLab。现在，FIPS 合规用户能够从极狐GitLab 和 Kubernetes 的集成中获益了。

针对服务台的多个外部参与者

有时候会有多人参与进来共同解决一个工单或者请求者想要同时都能知晓工单的最新动态。

现在，你可以在服务台工单和常规问题上，最多允许10名没有极狐GitLab 账号的外部参与者参与进来。

针对工单的每一次外部评论，外部参与者都会接收到服务台的通知邮件，他们的回复也将会显示在极狐GitLab UI 上。

可以简单地使用快捷操作 /add_email和 remove_email来添加或移除参与者。

你还可以通过配置极狐GitLab 来从初始邮件的 Cc header 中将邮件添加到服务台工单中。

你可以根据个人喜好定制所有服务台电子邮件模板，比如使用 markdown、HTML 以及动态占位符等。

一个可用的退订连接占位符能够让外部参与者更轻松地选择退出对话。

DAST 默认支持 arm64 和 amd64 架构

DAST 5 默认支持 arm64 和 amd64 架构。这能够让客户自主选择 Runner 的部署架构而且还能进行成本优化。

依赖项支持 Android

依赖项扫描用户现在可以扫描 Android 项目了。可以使用 CI/CD 目录组件进行 Android 扫描配置了。对于使用 CI/CD 模板的用户来讲，也一样可以对 Android 项目进行扫描。

当覆盖或禁用规则时，密钥检测支持远端规则集

我们修复了一个对远端规则集有影响的缺陷。现在可以通过远端规则集来对规则进行覆盖或者禁用。远端规则集提供了一个可扩展的方式来在单一地方进行规则配置，从而应用到多个项目上。

自动删除未验证的次要邮件地址

如果你在你的用户资料中添加了一个次要邮件地址，但是又没有进行验证，现在这个邮箱地址会在三天以后被自动删除。之前，这些邮件地址会处于一个保留状态，无法在没有手动干预的情况下进行释放。这次发布的自动删除功能大大减少了管理员的工作量，而且能够阻止用户保留那些他们没有所有权的电子邮件地址。

编辑自定义角色及其权限

之前，你是无法编辑既有的自定义角色及其权限的。现在，在无需重新创建角色情况下就可以编辑自定义角色和权限了。

为管理员和群组改进了分支保护设置

之前，设置默认分支保护选项时，不允许进行与受保护分支设置相同的配置级别。

在此版本中，我们更新了默认分支保护设置，为用户提供和保护分支相同的设置体验。这为保护默认分支提供了更多的灵活性，并简化了流程，以匹配受保护分支设置中已经存在的配置。

为自定义角色新增权限

下面是一些可被用来创建自定义角色的权限：

• 指派安全策略链接
• 管理和指派合规框架
• 管理 webhook
• 管理推送规则

有了此版本发布的自定义权限，你可以通过创建一个具有与所有者相同权限的自定义角色，来减少群组中所需的所有者数量。自定义角色允许你定义细粒度的角色，以便只给用户完成他们工作所需的权限，减少非必要的权限升级。

切换合并请求审核策略为失败开启或失败关闭

合规性对于许多组织来说是一个滑动标尺，因为他们在满足要求和确保开发者速度不受影响之间寻求平衡。合并请求审批政策有助于在DevSecOps 核心工作流程中实现安全和合规的操作——合并请求。我们为合并请求审核策略引入了一个新的失败开启选项，为那些希望在组织内推出控制措施时，能够灵活地过渡到政策执行的团队提供便利。

当一个合并请求审核策略配置为失败开启时，MR 只有在违反政策规则并且该项目已正确配置了安全分析器的情况下才会被阻止。如果没有开启项目的分析器或者分析器没有成功生成报告，该政策将不再将此视为针对给定规则和分析器的违规行为。这种方法允许团队在确保正确执行和实施扫描的同时，逐步推进政策。

在漏洞报告上更新了过滤器

漏洞报告过滤器的设计不具备可扩展性。我们被页面上的水平空间所限制。现在，你可以使用过滤搜索组件，通过状态、严重性、工具以及活动的任意组合来过滤漏洞报告。这种变化可以让我们添加新的过滤器，比如有用户提议的按标识符进行过滤。

改进了 Linux 软件包

CentOS Linux 7 将在2024年6月30日到达生命周期的终点。这也让极狐GitLab 17.1 成为了提供 CentOS 7 安装包的最后一个版本。

私有共享群组中的成员会在所有成员的“成员”标签页上列出

之前，当一个公共群组或项目邀请到一个私有群组中，私有群组仅会展示在成员页面的群组选项中，私有成员对公共群组来说是不可兼得。为了让这些群组之间的成员进行更好的协作，现在我们将所有的被邀请群组成员展示在成员选项中，包括私有的邀请群组中的成员。成员身份的来源将对没有访问私有群组权限的成员隐藏。然而，至少拥有项目中“维护者”角色或组中“所有者”角色的用户将能够看到成员身份的来源，以便他们可以管理其项目或组中的成员。如果当前查看“成员”标签页的用户未经过身份验证或不是组或项目的成员，他们将看不到私有组成员。我们希望这一变化将使群组和项目的成员更容易一目了然地了解谁有权访问某个群组或项目。

使用 REST API 从 Bitbucket Cloud 导入项目

在这个里程碑中，我们提供了试用 REST API 从 Bitbucket Cloud 导入项目的能力。

当有大量项目需要导入的时候，这明显是一种比从 UI 进行导入得更好的解决方案。

通过使用 API 重新导入选定的项目关系

当从具有多个相同条目（比如，合并请求或流水线）的导入文件导入项目时，有时候有些条目就不会被导入。

在此版本中，我们增加了一个 API 端点，用来重新导入一个命名的关系，跳过那些已经被导入的条目。此 API 需要：

• 一个项目导出的归档文件。
• 一种类型（议题、合并请求、流水线或里程碑）。

设计管理功能扩展到了产品团队

极狐GitLab 通过更新权限来扩展协作范围。现在，具有报告者角色的用户可以访问设计管理功能了，这能够让产品团队更加直接地参与设计过程。这个变化通过邀请组织内更广泛的参与，简化了工作流程并加速了创新。

群组中的访客可以链接议题了

我们将关联问题和任务所需的最低角色从“报告者”降低到“访客”，这为你提供了更多的灵活性，以便在你的极狐GitLab实例中组织工作，同时保持好权限。

价值流仪表盘中新的中位合并时间指标

我们为价值流仪表盘添加了一个新的指标：合并中位时间。在极狐GitLab 中，这个指标代表了合并请求被创建和被关闭之间的中位时间。这个新的指标通过识别合并请求和代码审核流程的效率和生产力来衡量 DevOps 健康度。

通过分析这一指标在其他软件开发生命周期（SDLC）指标背景下的演变情况，团队能够识别月度生产力的高低，了解新的 DevOps 实践在研发速度和交付流程方面的影响，减少整体的前置实践，而且还能增加软件交付的效率。

通过创建日期、最新更新日期以及头衔来对路线图进行排序

我们在路线图视图中扩展了史诗排序选项，为你在管理以及给项目进行优先级排序方面提供了更多的灵活性。现在你可以通过创建日期、最新更新日期以及头衔来对史诗进行排序了。这项增强功能为将来更高级的排序能力奠定了基础，以帮助你更动态地管理史诗级任务。

项目评论模版

继极狐GitLab 16.11 发布群组评论模板后，我们在 17.0 中引入了项目评论模板。

在跨组织的情况下，在议题（issue）、史诗（epic）以及合并请求（merge request）中使用相同的模板回复是非常有帮助的。这些响应可能包含需要回答的标准问题、针对常见问题的回复或者对合并请求审核注释的优秀结构等。项目级别的注释模板给了你一种额外的方式来限定模板的可用性，给组织在不同用户之间共享项目带来了更多可控性和灵活性。

为了创建一个评论模板，需要在极狐GitLab 的任意评论框中选择插入评论模板 --> 管理项目评论模板。当你创建完评论模板后，所有项目成员就都可以使用了。当你在评论时选择插入评论模板，那么你保存的响应都就会被应用生效。

极狐GitLab Runner 17.0

我们还发布了极狐GitLab Runner 17.0。极狐GitLab Runner 是一个轻量级、高扩展的代理，用来运行你的 CI/CD 作业并且将结果发送回极狐GitLab 实例。极狐GitLab Runner 和极狐GitLab CI/CD 绑定在一起，而极狐GitLab CI/CD 是一个开源且内置在极狐GitLab 里面的服务。

新特性：

• 在离线网络环境中安装 Runner Operator 的文档更新。

标准化 CI/CD 目录组件的发布流程

我们已经在 CI/CD 组件上做了很多努力的工作，包括让将组件发布到 CI/CD 目录的过程成为一种一致性的体验。作为工作的一部分，我们已经完成了通过 release关键字以及 release-cli镜像来在 CI/CD 作业中发布组件版本。所有对发布过程的改进将仅适用于上述方法。为了避免由于这种限制带来的破坏性变更，请确保你始终在使用最新的镜像（release-cli:latest）或者至少比 v0.17高的最新版本。现在，对于 CI/CD 组件项目，禁用了在 UI 上的发布选项。

增加了对 Kubernetes agent 的授权限制

对于极狐GitLab Kubernetes agent 来说，你可以和某个群组共享单个 agent 链接。我们的目的是支持在一个大型多租户集群上使用单个 agent。然而，你就会面临链接共享数限制这个问题。直到现在，单个 agent 只能在使用 CI/CD 的 100个项目和群组中进行共享，以及使用 user_access关键词的 100 个项目和群组之间共享。在极狐GitLab 17.0 中，这一共享数据上升到了 500。

在部署中追踪快速合并请求

在过往的版本中，只有当项目的合并方法为合并提高（Merge commit）或具有线性历史的合并提交（Merge commit with semi-linear history）时，才会在部署中对合并请求进行追踪。从极狐GitLab 17.0 开始，当合并方法为快速合并（Fast-forward）时，也会在部署中对合并请求进行追踪。

API 安全测试分析器更新

在极狐GitLab 17.0 版本中，我们发布了以下 API 安全测试分析器更新：

• 系统环境变量可以从 CI Runner 传递到用于某些高级场景（如请求签名）的自定义 Python 脚本中。这将让这些场景的实现变得更加容易。
• 现在，API 安全容易可以以非 root 用户运行了，这提高了灵活性和合规性。
• 对提供 TLSv1.3 芯片的服务器支持，这对于采用 API 安全测试来说提供了更高的自定义属性。
• 升级 Alpine 到 3.19，这解决了一些安全问题。

如之前所宣贯的，我们在极狐GitLab 17.0 中将 API 安全测试的主版本号改成了 5。

依赖扫描扫描默认的 Python 镜像

随着对于 Python 3.9 默认镜像的弃用，Python 3.11 成为默认镜像。

在弃用声明中写道，新的默认 Python 镜像是 3.10。直接升级到 Python 3.11 是为了确保符合 FIPS 策略。

为密钥检测引入了高级漏洞追踪

现在，密钥检测使用了更高级的漏洞扫描算法，以更准确地识别在重构或不相关更改中，相同的密钥是否在文件内移动。如果有以下情形，那么将不会创建新的漏洞：

漏洞在文件内移动。

同一个文件中出现了相同值的新漏洞。

否则，既有工作流（合并请求小部件、流水线报告以及漏洞报告中）将与之前一样对待这些发现。通过确保不会将重复的漏洞报告为密钥位置的移动，团队能够更容易地管理泄露的密钥。

简化了多种语言的 SAST 分析器覆盖率

现在，极狐GitLab 静态应用程序安全测试（SAST）可以用更少的分析器来扫描同一种语言了，这提供了一种更加简单、高度自定制化的扫码体验。

在极狐GitLab 17.0 中，针对以下语言，我们用在基于 Semgrep 分析器中定义的极狐GitLab 管理规则取代了特定语言分析器：

• Android
• C 和 C++
• iOS
• Kotlin
• Node.js
• PHP
• Ruby

同时，我们已经更新了 SAST CI/CD 模版来反映新的扫描覆盖率并且移除了那些再也不用的特定语言分析器作业。

为用户定制头像

现在，你可以使用 API 来为任意类型的用户（包括机器人）上传自定义头像。这对于从 UI 上来显著识别机器人用户来讲是非常有帮助的，比如群组和项目访问令牌或服务账号。

识别由管理员模式启动的会话

作为实例管理员，当你使用多个浏览器或者不同的电脑时，很难知道到底哪个是管理模式的会话，哪个又不是。现在，管理员可以在用户设置 --> 活跃会话中识别哪些会话是管理模式的。

在私有化部署实例层级上管理自定义角色

此版本前，在私有化部署实例上，只能在群组上创建自定义角色。这也就意味着管理员无法集中来管理针对实例级别的自定义角色，也就导致了整个实例内部会有一些重复的角色。现在，对于私有化部署版本来说，可以在实例级别对自定义角色进行管理了。之后管理员可以创建自定义角色，但是管理员和群组所有者都可以指派此自定义角色。

需要注意的是，当前的修改不会对极狐GitLab SaaS （JihuLab.com）上的自定义角色工作流产生影响。

针对策略机器人评论的可选配置

安全策略机器人在合并请求违反政策时会在合并请求上发表评论，以帮助用户理解何时在他们的项目上执行策略、何时完成评估，以及是否有任何违规行为阻止了 MR（合并请求），并提供解决这些问题的指南。当前，这些评论在每一种策略中是可选且可被启用/禁用的。这就给了组织很大的灵活性和控制性，以便让他们决定如何去跟用户去沟通这些策略。

自定义角色的 UX 改进

在自定义角色的用户体验上，我们做了一系列的改进：

• 当创建新的自定义角色时，会打开一个新的页面。
• 改进了自定义角色表的设计。
• 改进了删除自定义角色对话框的设计。
• 基础角色的权限预检查。

极狐GitLab chart 改进

极狐GitLab Operator 已经可以在云原生混合安装的生产环境上正式可用了。在采用极狐GitLab Operator 之前，务必阅读安装文档。

当指定自定义 BusyBox（global.busybox）的值时，对回退到 BusyBox 镜像的支持已经被移除。在极狐GitLab 16.2（Helm Chart 7.2）中，基于 BusyBox 的初始化容器的支持已经被弃用，转而支持一种通用的基于极狐GitLab 的初始化镜像。

对于 gitlab.kas.privateApi.tls.enabled和 gitlab.kas.privateApi.tls.secretName的支持已经移除。取而代之的是 global.kas.tls.enabled和 global.kas.tls.secretName。

弃用的队列选择器以及否定选项已经从 Sidekiq 中移除。

在成员页面显示被邀请群组的成员

之前，只能在成员页面的群组选项卡上看到被邀请到群组或项目的群组成员。这也就意味着用户必须同时检查群组和成员选项卡来了解谁可以访问特定群组或项目。现在，共享成员会被展示在程序员选项卡上，这可以让人一目了然地看到所有属于某个组或项目的所有成员。

双数据库模式处于 Beta 版

当前，大多数私有化部署客户只使用单个数据库。为了确保极狐GitLab SaaS（JihuLab.com）和私有化部署有相同设置，我们要求私有化部署客户默认迁移并运行两个数据库。在极狐GitLab 16.0 中，在私有化部署安装中，两个数据库连接成为了默认配置。在极狐GitLab 17.0 中，我们将两个数据库模式发布为受限制 Beta 版，目标是在 19.0 中使运行分离模式普遍可用。

迁移需要进行宕机。私有化部署客户可以使用工具来执行此项操作，并有段时间宕机。我们引入了一个新的 gitlab-ctl命令来允许你将单数据库极狐GitLab 实例升级到解耦设置模式。此设置包含两个在我们的 Linux 软件包中运行良好的命令。实际的迁移（复制数据库）是极狐GitLab 项目中 rake 任务的一部分。