按照版本发布计划，Gitlab如期发布了其新的一个大版本GitLab 17.0，该次发布累提供了60多项的功能改进和亮点（包括社区提交的344项MR），其中包括包含普遍可用的CI/CD目录、AI 影响分析仪表板、Linux Arm 上的托管运行程序、部署详细信息页面等等！更多功能请和虫虫一起学习。

GitLab 17.0 中发布的关键改进包含组件和输入的CI/CD目录现已普遍可用

借助CI/CD目录，可以访问由社区和行业专家创建的大量组件。无论是在寻找持续集成、部署管道还是自动化任务的解决方案，都能分类浏览适合需求的组件。

价值流仪表板中的AI影响分析(Ultimate)

AI Impact是价值流仪表板中提供的仪表板，可帮助组织了解GitLab Duo对生产力的影响。这个新的逐月指标视图将AI使用趋势与SDLC指标（例如交付时间、周期时间、DORA和漏洞）进行了比较。PM和其他管理人员可以使用AI Impact仪表板来衡量端到端工作流节省了多少时间，同时专注于业务成果而不是开发人员活动。

在第一个版本中，AI使用情况以每月代码建议使用率来衡量，计算方式为每月唯一代码建议用户数除以每月唯一贡献者总数。

Ultimate用户可以在有限的时间内使用AI Impact仪表板。之后，需要GitLabDuo Enterprise 许可证才能使用仪表板。

Linux Arm上托管的运行器简介(PREMIUM)

GitLab SaaS提供Linux Arm托管运行程序。现在可用的medium和large Arm 机器类型分别配备4或8 vCPU，与GitLabCI/CD完全集成，将使能够比以往更快、更经济高效地构建和测试应用程序

介绍部署详细信息页面(PREMIUM)

新版本中可以直接链接到GitLab中的部署。以前，如果正在协作部署，则必须从部署列表中查找部署。由于列出的部署数量众多，找到正确的部署很困难，而且容易出错。

从17.0开始，GitLab提供了可以直接链接到的部署详细信息视图。在第一个版本中，部署详细信息页面提供了部署作业的概述，以及在持续交付设置中批准、拒绝或评论部署的可能性。

GitLab Duo Chat 现在使用Anthropic Claude 3 Sonnet(PREMIUM)

GitLab Duo Chat变得更好了。新版本中使用Anthropic Claude 3 Sonnet作为基础模型，取代 Claude 2.1 来回答大多数问题。

GitLab正在为一系列任务选择最佳模型和编写性能良好的提示时采用测试驱动的方法。通过最近对聊天提示的调整，与之前基于 Claude 2.1构建的先前聊天版本相比，基于Claude 3 Sonnet的聊天答案的准确性、全面性和可读性方面取得了显著改进。

GitLab Duo Chat 在自中间实例中支持操作方法问题(Ultimate)

GitLab Duo Chat的一个流行功能是回答有关如何使用GitLab的问题。虽然 Chat提供了各种其他功能，但这项特定功能以前仅在GitLab SaaS可用。

新版本中，也开始支持GitLab自建实例，无论新手还是专家，都可以向Chat 寻求帮助，解决诸如“如何在GitLab中更改密码？”之类的问题。或“如何将Kubernetes集群连接到 GitLab？”。聊天旨在提供有用的信息，以更有效地解决问题。

价值流仪表板中的新使用情况概览面板(Ultimate)

通过“概览”面板增强了“价值流仪表板”。新的可视化功能满足了高管层对软件交付性能的洞察需求，并清晰地展现了GitLab在软件开发生命周期(SDLC)中的使用情况。

概述面板显示组级别的指标，例如（子）组、项目、用户、问题、合并请求和管道的数量。

将组添加到CI/CD作业令牌白名单

GitLab 15.9中引入CI/CD作业令牌允许列表，可防止其他项目未经授权访问您的项目。以前，只能允许其他特定项目在项目级别进行访问，最多可允许200个项目。

GitLab17.0中，可以将组添加到项目的CI/CD作业令牌白名单中。最大可支持200个列表，适用于项目和组，这意味着项目允许列表现在最多可以有200个授权访问的项目和组。此改进使得添加与组关联的大量项目变得更加容易。

CI/CD新增关键字rules:exists增强上下文控制

CI/CD关键字rules:exists的默认行为会根据关键字的定义位置而有所不同，这可能会使其更难与更复杂的管道一起使用。在作业中定义时，rules:exists会在运行管道的项目中搜索指定的文件。但是，在部分中定义时include，rules:exists会在托管包含该部分的配置文件的项目中搜索指定的文件include。如果配置分散在多个文件和项目中，则很难知道将在哪个确切项目中搜索定义的文件。

在新版本中，引入了project和ref子键rules:exists，提供了一种明确控制此关键字的搜索上下文的方法。这些新子键可帮助您通过精确指定搜索上下文、减少不一致并增强管道规则定义的清晰度来确保准确的规则评估。

使用Switchboard进行配置更改的更改日志(Ultimate)

新版本中可以使用Switchboard配置页面查看对GitLab专用实例基础设施进行的配置更改的状态。

所有有权在Switchboard中查看或编辑租户的用户都将能够查看配置更改日志中的更改，并在这些更改应用于实例时跟踪其进度。

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

GitLab 17.0中的其他改进使用RESTAPI在GitLab中查看Jira问题(PREMIUM)

在此版本中，可以使用 REST API在GitLab中查看Jira问题。还可以指定一个或多个Jira项目来查看问题。

迁移项目分类识别

新版本中可以支持直接传输在GitLab实例之间迁移GitLab组和项目。到目前为止，导入的项目都不容易识别。在新版本中，为通过直接传输导入的项目添加了视觉指示器，其中创建者被标识为特定用户：

注释（系统注释和用户评论）、问题、合并请求、Epic、设计、片段和用户个人资料活动。

在GitLab中查看多个Jira项目的问题

对于较大的存储库，新版本中可以在设置Jira问题集成时查看GitLab中多个Jira项目的问题，可以实现：

输入最多100个Jira项目键，以逗号分隔。

将Jira项目密钥留空以包含所有可用密钥。

在GitLab中查看Jira问题时，可以按项目过滤问题。

要为GitLab Ultimate中的漏洞创建Jira问题，只能指定一个Jira项目。

增强的Epic删除保护(PREMIUM)

新版保重更新了删除Epic时会发生的情况，以更好地保护项目的结构和数据。这是为了让在管理项目时获得更多控制权并安心无忧。在新版本中当删除父Epic时，不会自动删除其所有子记录，而是通过首先分离父关系来保留它们。此更改为提供了一种更安全的方式来管理Epic，确保意外删除不会导致丢失有价值的信息。

问题板上可见的里程碑和迭代

新版本中改进了问题板，让可以更清晰地了解项目的时间表和阶段。在新版本中通过问题卡上直接可见的里程碑和迭代详细信息，可以轻松跟踪进度并动态调整团队的工作量。该增强功能旨在提高您的计划和执行效率，让随时了解情况并提前完成计划。

简化的价值流仪表板配置文件架构(Ultimate)

在新版本中可以使用简化的架构驱动的可自定义UI框架自定义价值流面板。在新格式中，字段提供了显示数据和布局仪表板面板的更多灵活性。借助新框架，管理员可以跟踪仪表板随时间的变化。版本历史记录可以帮助恢复到以前的版本并比较仪表板版本之间的更改。

使用这种定制，决策者可以专注于与其业务最相关的信息，而团队可以更好地组织和显示关键的DevSecOps指标。

JetBrains IDE 的GitLabDuo 插件中1Password集成(PREMIUM)

新版本中可以将1Password密码管理与JetBrains的GitLabDuo 插件集成。开发人员可以在JetBrains IDE设置中用1Password密钥引用替换个人访问令牌。这简化了密钥管理，并实现了无缝密钥轮换，无需手动更新令牌。

为GitLab UI提交签名

之前，无法对GitLab进行的Web提交和自动提交进行签名。新版本中可以使用签名密钥、提交者名称和电子邮件地址配置自建实例实例，以签署Web和自动提交。

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

CI/CD关键字after_script用于在script作业的主要部分之后运行附加命令。这通常用于清理作业使用的环境或其他资源。但是，after_script如果作业被取消，命令不会运行。

从GitLab17.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。

过滤包注册表UI以查找有错误的包

可以使用GitLab包注册表来发布和下载包。有时，包会因错误而无法上传。之前无法快速查看上传失败的包。这使得全面了解组织的包注册表变得困难。

在新版本中可以过滤软件包注册表UI以查找上传失败的软件包。该改进可以实现更轻松地调查和解决遇到的任何问题。

支持 FIPS 模式下的Kubernetes的GitLab代理

从GitLab17.0 开始，可以在 FIPS 模式下安装GitLab，并启用Kubernetes组件的代理。在新版本中符合FIPS的用户可以从Kubernetes 与GitLab的所有集成中受益。

服务台的多个外部参与者

有时，不止一个人参与解决支持票，或者请求者希望让同事了解票的最新状态。在新版本中最多可以有10位没有GitLab帐户的外部参与者处理服务台票证和常规问题。

外部参与者会收到针对工单上的每条公共评论的服务台通知电子邮件，他们的回复将在GitLab UI中显示为评论

只需使用快速操作/add_email并remove_email通过几次击键即可添加或删除外部参与者。

还可以配置GitLab将初始电子邮件标题中的所有电子邮件地址添加Cc到服务台票证中。

可以使用markdown、HTML和动态占位符根据自己的喜好定制所有服务台电子邮件模板。取消订阅链接占位符可让外部参与者轻松选择退出对话。

自动删除未经验证的辅助电子邮件地址

如果将辅助电子邮件地址添加到用户个人资料中但未进行验证，该电子邮件地址在三天后会自动被删除。此前，这些电子邮件地址处于保留状态，如果没有人工干预，无法释放。这种自动删除功能可以减少管理员开销，并防止用户保留他们不拥有所有权的电子邮件地址。

编辑自定义角色及其权限(Ultimate)

以前，无法编辑现有的自定义角色及其权限。在新版本中可以编辑自定义角色及其权限，而无需重新创建角色进行更改。

改进了管理员和群组的分支保护设置(Ultimate)

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

在此版本中，更新了默认分支保护设置，以提供与受保护分支相同的体验。这可以更灵活地保护您的默认分支，并简化流程以匹配受保护分支设置中已存在的内容。

将合并请求审批策略切换为打开失败或关闭失败(Ultimate)

对于许多组织来说，合规性的运作是浮动的，在满足要求和确保开发人员速度不受影响之间进行平衡。合并请求批准策略有助于在DevSecOps工作流程的核心（合并请求）中实现安全性和合规性。正在引入fail open合并请求批准策略的新选项，为希望在组织中推出控制措施时轻松过渡到策略实施的团队提供灵活性。

当合并请求审批策略配置为失败打开时，现在只有在违反策略规则并且该项目已正确配置安全分析器时才会阻止MR。如果未为项目启用分析器或者分析器未成功生成结果，则策略将不再认为这是给定规则和分析器的违规行为。这种方法允许在团队努力确保正确的扫描执行和实施时逐步推出策略。

Linux 软件包改进(PREMIUM)

CentOS Linux 7将于2024年6月30日终止使用。GitLab17.1将是最后一个支持CentOS 7的GitLab rpm包。

私人共享群组成员在所有成员的“成员”选项卡上列出

以前，当公共群组或项目邀请私人群组时，私人群组仅列在“成员”页面的“群组”选项卡中，私人成员对公共群组的成员不可见。为了让这些群组的成员之间更好地协作，新版本中在“成员”选项卡中列出了所有受邀群组成员，包括来自私人受邀群组的成员。对于无权访问私人群组的成员，成员资格来源将被屏蔽。但是，至少具有项目中的维护者角色或群组中的所有者角色的用户将可以看到成员资格来源，以便他们可以管理其项目或群组中的成员。如果当前查看“成员”选项卡的用户未经身份验证或不是群组或项目的成员，将看不到私人群组成员。

使用RESTAPI从Bitbucket Cloud导入

在新版本中，添加了使用RESTAPI导入Bitbucket Cloud项目的功能。与使用UI导入相比，这对于导入大量项目来说是一个更好的解决方案。

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

从包含许多相同类型的项目（例如合并请求或管道）的导出文件导入项目时，有时不会导入其中一些项目。

在此版本中，添加了一个API接口，用于重新导入命名关系，跳过已导入的项目。此API需要以下两项：

项目导出档案。

类型（问题、合并请求、管道或里程碑）。

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

GitLab正在通过更新权限来扩大协作。在新版本中具有记者角色的用户可以访问设计管理功能，使产品团队能够更直接地参与设计过程。这一变化通过邀请整个组织的更广泛参与来简化工作流程并加速创新。

团体客人可以链接问题(PREMIUM)

将关联问题和任务所需的最低角色从记者减少到访客，让在保持权限的同时更灵活地组织整个GitLab实例中的工作。

价值流仪表板中合并指标的新中位时间(Ultimate)

在价值流仪表板中添加了一个新指标：合并中位时间。在GitLab中，此指标表示合并请求创建时间和合并时间之间的中位时间。新指标通过确定合并请求和代码审查流程的效率和生产力来衡量DevOps的健康状况。

通过分析该指标在其他SDLC指标背景下的演变方式，团队可以确定生产率低或高的月份，了解新的DevOps实践对开发速度和交付过程的影响，减少总体交付时间，并提高软件交付速度。

按创建日期、上次更新日期和标题对路线图进行排序(PREMIUM)

扩展了“路线图”视图中可用的Epic排序选项，在组织和确定项目优先级时更加灵活。在新版本中可以按创建日期、上次更新日期和标题对Epic进行排序。该增强功能为未来更高级的排序功能奠定了基础，可帮助实现更动态地管理Epic。

使用可自定义的快捷方式更快地访问GitLabDuo Chat(PREMIUM)

在新版本中直接从JetBrains中的编辑器打开Duo Chat变得更加容易。使用默认Alt+D键盘快捷键（或设置您自己的）快速打开Duo Chat并输入问题。使用相同的键盘快捷键关闭窗口。

项目评论模板(PREMIUM)

继GitLab 16.11发布群组评论模板后，这些模板被引入到GitLab17.0项目中。

在整个组织中，在问题、Epic和合并请求中使用相同的模板化响应会很有帮助。这些答复可能包括需要回答的标准问题、对常见问题的答复或合并请求审核评论的良好结构。项目级评论模板为您提供了另一种方式来确定模板的可用性范围，从而使组织在跨用户共享这些模板时具有更多的控制力和灵活性。

要创建评论模板，请转到GitLab上的任何评论框，然后选择插入评论模板 > 管理项目评论模板。创建评论模板后，所有项目成员都可以使用它。发表评论时选择插入评论模板图标，保存的回复将被应用。

标准化CI/CD Catalog组件发布流程

一直在努力开发CI/CD组件，包括使将组件发布到CI/CD目录的过程成为一种一致的体验。作为这项工作的一部分，已将使用关键字release和image从CI/CD作业发布版本release-cli作为唯一方法。发布过程的所有改进仅适用于此方法。为避免此限制引入重大更改，请确保始终使用图像的最新版本（release-cli:latest）或至少大于的版本v0.16。UI中的“release”选项现在已为CI/CD组件项目禁用。

增加Kubernetes代理授权限制

使用适用于Kubernetes的GitLab代理，可以与组共享单个代理连接。最终目标是支持大型多租户集群中的单个代理。之前使用CI/CD只能与100个项目和组共享代理，使用user_access关键字只能与100个项目和组共享。在GitLab17.0 中，可以共享的项目和组的数量增加到500个。

跟踪部署中的快速合并请求

在过去的版本中，仅当项目的合并方法是Merge commit或Merge commit with semi-linear history时，才会在部署中跟踪合并请求。从GitLab17.0 开始，合并请求会在部署中进行跟踪，包括在合并方法为Fast-forward merge的项目中。

为用户定制头像

现在可以使用API为任何用户类型（包括机器人用户）上传自定义头像。这对于在UI中直观区分机器人用户（例如群组和项目访问令牌或服务帐户）与人类用户尤其有用。

识别由管理员模式发起的会话

作为实例管理员，当使用多个浏览器或不同的计算机时，很难知道哪些会话处于管理模式，哪些不是。在新版本中管理员可以转到用户设置>活动会话来确定哪些会话使用管理模式。

在自行管理实例级别管理自定义角色(Ultimate)

在此版本之前，在自建实例GitLab上，必须在组级别创建自定义角色。这样管理员无法集中管理实例的自定义角色，从而导致整个实例中的角色重复。在新版本中自定义角色在自建实例级别进行管理。只有管理员可以创建自定义角色，但管理员和组所有者都可以分配这些自定义角色。

政策机器人评论的可选配置(Ultimate)

当合并请求违反策略时，安全策略机器人会发布评论，以帮助用户了解何时在其项目上实施策略、何时完成评估以及是否存在任何阻止MR的违规行为，并提供解决问题的指导。这些注释现在是可选的，可以在每个策略中启用或禁用。这为组织提供了灵活性和控制力，以确定他们希望如何向用户传达这些策略。

自定义角色的用户体验改进(Ultimate)

对自定义角色的用户体验进行了一系列改进，具体如下：

创建新的自定义角色时会打开一个新页面。

改进了自定义角色表的设计。

改进了删除自定义角色对话框的设计。

预先检查基本角色的权限。

成员页面显示受邀群组的成员

以前，受邀加入群组或项目的群组成员仅在“成员”页面的“群组”选项卡中可见。这意味着用户必须检查“组”和“成员”选项卡才能了解谁有权访问某个组或项目。在新版本中共享成员也列在“成员”选项卡中，可一目了然地全面了解属于某个组或项目的所有成员。

Beta版提供两种数据库模式

目前，大多数自建实例客户仅使用单个数据库。为了确保GitLab SaaS和自建实例之间的设置相同，要求自建实例客户默认迁移并运行分解。在16.0中，两个数据库连接成为自建实例安装的默认设置。在17.0中，将终止对自建实例的单个数据库连接的支持，但将继续支持具有两个连接的单个数据库，直到 19.0。

在17.0中，发布了两个数据库模式作为有限的Beta版，目标是在19.0之前普遍可用运行分解。迁移在17.0中仍然是可选的，但需要在升级到19.0之前执行。

迁移需要停机时间。自行管理的客户可以使用工具执行该迁移，但需要停机一段时间。引入了一个新gitlab-ctl命令，允许将单数据库GitLab实例升级到分解设置。此设置包含可与我们的Linux包配合使用的命令。实际迁移（复制数据库）是GitLab项目中rake任务的一部分。

通过可自定义的语言设置获得更多代码建议

在GitLab VS Code工作流程扩展中，现在可以选择为代码建议配置其他语言。目前该功能还是一个实验项目。

GitLab Runner 17.0

同期还发布了GitLab Runner 17.0。主要更新为：

在断开网络的环境中安装 Runner Operator 的文档。

GitLab图表改进

GitLab Operator现在可用于云原生混合安装的生产用途。

global.busybox删除了指定自定义BusyBox值时回退到BusyBox镜像的支持。

GitLab16.2（Helm Chart 7.2）中已弃用对基于BusyBox的init容器的支持，取而代之的是基于通用GitLab的init镜像。

对gitlab.kas.privateApi.tls.enabled和 gitlab.kas.privateApi.tls.secretName的支持也已删除。必须使用global.kas.tls.enabled和global.kas.tls.secretName来代替。

已弃用的队列选择器和否定选项已从Sidekiq图表中删除。

安全和合规性SAST安全扫描器更新

从SAST CI/CD模板中删除一组特定于语言的分析器，并用基于Semgrep的分析器中GitLab 支持的检测规则替换它们的覆盖范围。以下分析器现已弃用，将在 GitLab 17.0 中终止支持：

Brakeman (Ruby, Ruby on Rails)

Flawfinder (C, C++)

MobSF (Android, iOS)

NodeJS 扫描 (Node.js)

PHPCS安全审计 (PHP)

更改SAST CI/CD 模板以停止基于SpotBugs分析器的Kotlin和Scala代码。以上语言SAST的分析功能将基于Semgrep使用GitLab支持的检测规则进行扫描。弃用的分析器将仅收到安全更新；不保证其他常规改进或更新。GitLab 17.0 中的分析器终止支持后，将不再提供进一步的更新。但是，默认GitLab不会删除之前为这些分析器发布的容器镜像，也不会删除使用自定义 CI/CD 管道作业定义来其运行的能力。漏洞管理系统将更新大多数现有发现，以便它们与新的检测规则相匹配。未迁移到新分析器的发现将自动解决。

如果已删除的分析器应用了自定义，或者当前在管道中禁用了基于Semgrep 的分析器，则必须按照此更改的弃用问题中详细说明采取操作。

自定义角色的新权限(Ultimate)

可以使用新的权限来创建自定义角色：

分配安全策略链接；

管理和分配合规框架；

管理网络钩子；

管理推送规则；

随着这些自定义权限的发布，可以通过创建具有这些所有者等效权限的自定义角色来减少组中所需的所有者数量。自定义角色允许定义精细的角色，仅向用户授予完成其工作所需的权限，并减少不必要的权限升级。

DAST现在默认支持arm64和amd64架构(Ultimate)

DAST 5默认支持arm64和amd64架构。这使客户能够选择Runner主机架构并优化成本节约。

Android 依赖项扫描支持(Ultimate)

依赖扫描的用户现在可以扫描Android项目。要配置Android扫描，请使用CI/CD 目录组件。CI/CD 模板的用户还支持Android扫描。

秘密检测在覆盖或禁用规则时支持远程规则集(Ultimate)

新版本中解决了影响远程规则集的秘密检测错误。可以通过远程规则集覆盖或禁用规则。远程规则集提供了一种在单个位置配置规则的可扩展方法，可以跨多个项目应用。

API安全测试分析器更新(Ultimate)

17.0中，新发布了以下API安全测试分析器更新：

系统环境变量现在从CI运行器传递到用于某些高级场景（如请求签名）的自定义Python脚本。这将使实现这些场景变得更容易。

API安全容器现在以非root用户身份运行，从而提高了灵活性和合规性。

支持仅提供TLSv1.3密码的服务器，使更多客户能够采用API安全测试。

容器镜像升级到Alpine 3.19，解决了安全漏洞。

依赖扫描默认Python镜像(Ultimate)

在弃用Python3.9 作为默认Python镜像之后，Python 3.11现在成为默认镜像。

新的默认Python版本的目标是3.10。为了确保FIPS合规性，需要直接迁移到Python 3.11。

引入用于秘密检测的高级漏洞跟踪(Ultimate)

机密检测现在使用高级漏洞跟踪算法，可以更准确地识别同一机密何时由于重构或不相关的更改而在文件中移动。如果出现以下情况，则不再创建新发现：

泄漏在文件内移动。

同一文件中出现相同值的新泄漏。

否则，现有工作流程（合并请求小部件、管道报告和漏洞报告）将像以前一样处理结果。通过确保不会将重复的漏洞报告为秘密转移位置，团队可以更轻松地管理泄露的秘密。

更新了漏洞报告的过滤功能(Ultimate)

漏洞报告过滤器的旧实现不可扩展。受页面水平空间的限制。在新版本中可以使用过滤搜索组件按状态、严重性、工具或活动的任意组合过滤漏洞报告。此更改允许用户添加新的过滤器，例如此建议的按标识符过滤。

简化了SAST分析器的覆盖范围，涵盖更多语言

GitLab 静态应用程序安全测试 (SAST) 现在可以使用更少的分析器扫描相同的语言，从而提供更简单、更可定制的扫描体验。

在GitLab17.0 中，已将基于Semgrep的分析器中针对以下语言的特定语言分析器替换为GitLab管理的规则：

安卓、C和C++、iOS、Kotlin、Node.js、PHP，Ruby

新更新SASTCI/CD模板，以反映新的扫描覆盖范围，并删除不再使用的特定于语言的分析器作业。

错误修复、性能改进和UI改进

在17.0中提供的所有错误修复、性能增强和UI方面做了持续改进（详略）。

功能弃用和重大变化

在17.0有些功能被启用，有些有重要变化更新：

GraphQL中删除“previousStageJobsOrNeeds”。

删除对不受支持的方法访问 GraphQL API的支持。

SAST安全扫描重大更新

从SAST CI/CD模板将删除对Brakeman (Ruby, Ruby on Rails)、Flawfinder (C, C++)、MobSF (Android, iOS)、NodeJS 扫描 (Node.js)、PHPCS安全审计 (PHP)等支持，并停止基于SpotBugs分析器的Kotlin和Scala代码分析。所有语言分析将都基于Semgrep的分析器中GitLab 支持的检测规则替换它们的覆盖范围。

升级更新Linux package (原Omnibus GitLab)Omnibus

Omnibus套件被新命名为Linux安装包，目前支持的发行版信息如下：

这些系统的自建实例可直接使用发行版本自带的包管理器可以升级。

例如对CentOS:

yum updata/install gitlab-ce

就能自动完成升级。

GET脚本

在安装上GitLab新提供了GET（Gitlab Environment Toolkit）环境工具包，这是使用Terraform和Ansible脚本来用于帮助按照参考架构部署扩展的自管理GitLab环境。

GET工具包由GitLab质量工程支持团队创建和维护，支持以下功能：

支持动态部署从1k到50k的所有参考架构大小。

支持部署参考架构的云原生混合变体（目前仅限AWS和GCP）。

GCP、AWS和Azure（Linux包）云提供商支持。

nightly Linux 软件包(Omnibus)构建支持.

使用OpenSearch进行高级搜索.

Geo支持;

容器注册表支持;

零停机升级支持;

内置可选负载平衡和监控（Prometheus）设置;

SSL/TLS支持（直接或通过hooks）;

选定组件（负载均衡器、PostgreSQL、Redis）的替代来源（云服务、自定义服务器）;

本地支持 (Ansible);

自定义配置/任务/文件支持;

ET工具包可以实现零停机升级，使用编辑好的zero_downtime_update.yml使用：

ansible-playbook -i environments/10k/inventory playbooks/zero_downtime_update.yml

Docker版本

先停止和删除旧的容器：

sudo docker stop gitlab

sudo docker rm gitlab

然后Pull官方最新镜像：

sudo docker pull gitlab/gitlab-ce:latest

重新启动容器（启动参数和以前保持一致）即可，比如:

sudo docker run --detach \

--hostname gitlab.example.com \

--publish 443:443 --publish 80:80 --publish 22:22 \

--name gitlab \

--restart always \

--volume /srv/gitlab/config:/etc/gitlab \

--volume /srv/gitlab/logs:/var/log/gitlab \

--volume /srv/gitlab/data:/var/opt/gitlab \

gitlab/gitlab-ce:latest

Docker compose

通过：

docker-compose pull

docker-compose up -d

升级到GitLab17.0的重要说明

在升级到GitLab17.0之前，如果使用Sentry跟踪GitLab环境中的错误，则必须将Sentry 实例升级到21.5.0或更高版本。

必须先升级到GitLab1 6.11，然后再升级到GitLab17.0，以完成后台迁移。