GitLab 17.0:通用CI/CD目录,基于Ansible脚本GET一键安装包
GitLab 17.0 中发布的关键改进
包含组件和输入的CI/CD目录现已普遍可用
CI/CD 目录提供对社区和行业专家创建的大量组件的访问。无论您是在寻找持续集成、部署管道还是自动化任务的解决方案,都可以按类别浏览以查找适合您需求的组件。
价值流仪表板中的AI影响分析(Ultimate)
AI Impact 是价值流仪表板中提供的仪表板,可帮助组织了解GitLab Duo 对生产力的影响。这个新的逐月指标视图将AI 使用趋势与SDLC 指标(例如交付时间、周期时间、DORA 和漏洞)进行比较。 PM 和其他经理可以使用AI Impact 仪表板来衡量端到端工作流程节省了多少时间,同时关注业务成果而不是开发人员活动。
在第一个版本中,AI 使用情况以每月代码建议使用情况来衡量,计算方式为每月唯一代码建议用户数除以每月唯一贡献者总数。
终极用户可以在有限的时间内使用AI影响仪表板。之后,需要GitLabDuo Enterprise 许可证才能使用仪表板。
Linux Arm上托管的运行器简介(PREMIUM)
GitLab SaaS 提供Linux Arm 托管运行器。现在可用的中型和大型Arm 机器类型分别具有4 个或8 个vCPU,与GitLabCI/CD 完全集成,使得比以往更快、更经济高效地构建和测试应用程序成为可能
介绍部署详细信息页面(PREMIUM)
在新版本中,您可以直接链接到GitLab中的部署。以前,如果您在部署上进行协作,则必须从部署列表中查找该部署。由于列出的部署数量众多,因此找到正确的部署非常困难且容易出错。
从17.0 开始,GitLab 提供了可以直接链接到的部署详细信息视图。在第一个版本中,部署详细信息页面提供了部署作业的概述以及在持续交付设置中批准、拒绝或评论部署的可能性。
GitLab Duo Chat 现在使用Anthropic Claude 3 Sonnet(PREMIUM)
GitLab Duo 聊天变得更好了。新版本使用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 个项目。
在GitLab 17.0 中,可以将组添加到项目的CI/CD 作业令牌白名单中。支持最多200 个列表适用于项目和组,这意味着项目允许列表现在最多可以包含200 个具有授权访问权限的项目和组。此改进使得添加与组关联的大量项目变得更加容易。
CI/CD新增关键字rules:exists增强上下文控制
CI/CD 关键字规则:exists 的默认行为因定义关键字的位置而异,这可能会使其更难以与更复杂的管道一起使用。在作业中定义时,rules:exists 会在运行管道的项目中搜索指定文件。但是,当在节包含中定义时,rules:exists 会在托管包含该节的配置文件的项目中搜索包含指定的文件。如果配置分散在多个文件和项目中,则可能很难知道将在哪个确切项目中搜索定义的文件。
在新版本中,引入了project和ref子键rules:exists,提供了一种显式控制该关键字的搜索上下文的方法。这些新子项可通过精确指定搜索上下文、减少不一致并提高管道规则定义的清晰度来帮助您确保准确的规则评估。
使用Switchboard进行配置更改的更改日志(Ultimate)
在新版本中,您可以使用Switchboard 配置页面查看对GitLab 专用实例基础设施所做的配置更改的状态。
所有有权在Switchboard 中查看或编辑租户的用户都将能够查看配置更改日志中的更改,并在这些更改应用于实例时跟踪这些更改的进度。
目前,交换机配置页面和更改日志可用于更改,例如通过将IP 添加到允许列表或配置实例的SAML 设置来管理对实例的访问。
GitLab 17.0中的其他改进
使用RESTAPI在GitLab中查看Jira问题(PREMIUM)
在此版本中,可以使用REST API 在GitLab 中查看Jira 问题。您还可以指定一个或多个Jira 项目来查看问题。
迁移项目分类识别
新版本可以支持直接传输以在GitLab实例之间迁移GitLab组和项目。到目前为止,进口项目的识别并不容易。在新版本中,为通过直接传输导入的项目添加了可视化指示器,其中创建者被识别为特定用户:
评论(系统评论和用户评论)、问题、拉取请求、史诗、设计、片段和用户个人资料活动。
在GitLab中查看多个Jira项目的问题
对于较大的仓库,新版本中,设置Jira问题集成时可以在GitLab中查看多个Jira项目的问题,可以实现:
输入最多100 个Jira 项目密钥,以逗号分隔。
将Jira 项目密钥留空以包含所有可用密钥。
在GitLab 中查看Jira 问题时,您可以按项目过滤问题。
要为GitLab Ultimate 中的漏洞创建Jira 问题,您只能指定Jira 项目。
增强的Epic删除保护(PREMIUM)
新版Take Care 更新了删除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 用于在脚本作业的主要部分之后运行附加命令。这通常用于清理作业使用的环境或其他资源。但是,如果作业被取消,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。
过滤包注册表UI以查找有错误的包
您可以使用GitLab 包注册表来发布和下载包。有时,包会因错误而无法上传。之前无法快速查看上传失败的包。这使得获得组织的包注册表的完整视图变得困难。
在新版本中,可以过滤包注册表UI 以查找上传失败的包。此改进使调查和解决遇到的任何问题变得更加容易。
支持 FIPS 模式下的Kubernetes的GitLab代理
从GitLab17.0开始,您可以以FIPS模式安装GitLab并启用Kubernetes组件的代理。在新版本中符合FIPS 的用户可以受益于Kubernetes 与GitLab 的所有集成。
服务台的多个外部参与者
有时,不止一个人参与解决支持票证,或者请求者希望让同事了解票证的最新状态。在新版本中,最多10 名没有GitLab 帐户的外部参与者可以处理帮助台票证和一般问题。
对于工单上的每条公共评论,外部参与者都会收到一封帮助台通知电子邮件,他们的回复将在GitLab UI 中显示为评论
只需使用快速操作/add_email 和remove_email,通过几次按键即可添加或删除外部参与者。
GitLab 还可以配置为将初始电子邮件标头中的所有电子邮件地址添加到帮助台票证中。
所有帮助台电子邮件模板都可以使用Markdown、HTML 和动态占位符根据您的喜好进行自定义。取消订阅链接占位符使外部参与者可以轻松选择退出对话。
自动删除未经验证的辅助电子邮件地址
如果辅助电子邮件地址已添加到用户个人资料但未经验证,则该电子邮件地址将在三天后自动删除。此前,这些电子邮件地址处于保留状态,如果没有人工干预,则无法释放。这种自动删除功能可减少管理员开销,并防止用户保留不属于他们的电子邮件地址。
编辑自定义角色及其权限(Ultimate)
以前,无法编辑现有自定义角色及其权限。可以在新版本中编辑自定义角色及其权限,而无需重新创建角色来进行更改。
改进了管理员和群组的分支保护设置(Ultimate)
以前,设置默认分支保护选项不允许与受保护分支的设置具有相同级别的配置。
在此版本中,默认分支保护设置已更新,以提供与受保护分支相同的体验。这样可以更灵活地保护默认分支,并简化流程以匹配受保护分支设置中已有的内容。
将合并请求审批策略切换为打开失败或关闭失败(Ultimate)
对于许多组织来说,合规性是按浮动比例运作的,在满足要求和确保开发人员速度不受影响之间取得平衡。合并请求批准策略有助于在DevSecOps 工作流程的核心(合并请求)中实现安全性和合规性。正在引入失败开放合并请求批准策略的新选项,以便为希望在组织中推出控制措施时轻松过渡到策略执行的团队提供灵活性。
当合并请求审批策略配置为失败时,现在只有在违反策略规则并且项目具有正确配置的安全分析器时才会阻止MR。如果未为项目启用分析器或分析器未成功生成结果,则策略将不再认为这是给定规则和分析器的违规行为。这种方法允许在团队努力确保正确的扫描执行和实施时逐步推出策略。
Linux 软件包改进(PREMIUM)
CentOS Linux 7 将于2024 年6 月30 日终止生命。GitLab17.1 将是最后一个支持CentOS 7 的GitLab rpm 软件包。
私人共享群组成员在所有成员的“成员”选项卡上列出
使用RESTAPI从Bitbucket Cloud导入
在新版本中,添加了使用REST API 导入Bitbucket Cloud 项目的功能。对于导入大量项目来说,这是比使用UI 导入更好的解决方案。
使用API重新导入选定的项目关系
从包含许多相同类型项目(例如合并请求或管道)的导出文件导入项目时,有时某些项目不会导入。
在此版本中,添加了API 接口,用于重新导入命名关系,跳过已导入的项目。该API需要以下两项:
项目导出存档。
类型(问题、合并请求、管道或里程碑)。
设计管理功能扩展到产品团队
GitLab 正在通过更新的权限扩展协作。新版本中具有报告者角色的用户可以访问设计管理功能,使产品团队能够更直接地参与设计过程。这一变化通过邀请整个组织更广泛的参与来简化工作流程并加速创新。
团体客人可以链接问题(PREMIUM)
减少将问题和任务从报告者关联到访客所需的最低角色,从而在维护权限的同时更灵活地组织整个GitLab 实例的工作。
价值流仪表板中合并指标的新中位时间(Ultimate)
向价值流仪表板添加了一个新指标:合并中值时间。在GitLab 中,该指标表示合并请求创建时间和合并时间之间的中位时间。新指标通过确定合并请求和代码审查流程的效率和生产力来衡量DevOps 的健康状况。
通过分析该指标在其他SDLC 指标的背景下如何演变,团队可以识别生产力低或高的月份,了解新的DevOps 实践对开发速度和交付流程的影响,减少总体交付时间,并提高软件交付速度。
按创建日期、上次更新日期和标题对路线图进行排序(PREMIUM)
扩展了路线图视图中可用的Epic 排序选项,以便在组织项目和确定项目优先级时提供更大的灵活性。在新版本中,Epics 可以按照创建日期、上次更新日期和标题进行排序。此增强功能为未来更高级的排序功能奠定了基础,以帮助更动态地管理Epics。
使用可自定义的快捷方式更快地访问GitLabDuo Chat(PREMIUM)
在新版本中,直接从JetBrains 中的编辑器打开Duo Chat 变得更加容易。使用默认的Alt+D 键盘快捷键(或设置您自己的快捷键)快速打开Duo Chat 并输入问题。使用相同的键盘快捷键关闭窗口。
项目评论模板(PREMIUM)
随着GitLab 16.11中发布群组评论模板,这些模板被引入到GitLab17.0项目中。
在整个组织中,在问题、史诗和合并请求中使用相同的模板化响应会很有帮助。这些回复可能包括要回答的标准问题、对常见问题的回复或结构良好的合并请求审核评论。项目级评论模板为您提供了另一种方式来确定模板的可用性范围,从而使组织在跨用户共享这些模板时具有更多的控制力和灵活性。
要创建评论模板,请转到GitLab 上的任何评论框,然后选择插入评论模板管理项目评论模板。创建评论模板后,所有项目成员都可以使用它。发表评论时选择插入评论模板图标,将应用保存的回复。
标准化CI/CD Catalog组件发布流程
一直致力于开发CI/CD组件,包括使将组件发布到CI/CD目录的过程成为一致的体验。作为这项工作的一部分,release-cli 版本已从CI/CD 作业中发布,使用关键字release和image作为唯一的方法。对发布过程的所有改进仅适用于此方法。为了避免此限制引入重大更改,请确保始终使用最新版本的映像(release-cli:latest) 或至少高于v0.16 的版本。现在,对于CI/CD 组件项目,UI 中的“发布”选项已禁用。
增加Kubernetes代理授权限制
使用GitLab Kubernetes 代理,可以与组共享单个代理连接。最终目标是支持大型多租户集群中的单个代理。以前,使用CI/CD 只能与100 个项目和组共享代理,使用user_access 关键字只能与100 个项目和组共享代理。在GitLab 17.0 中,可以共享的项目和组的数量增加到500 个。
跟踪部署中的快速合并请求
在过去的版本中,仅当项目的合并方法是“合并提交”或“具有半线性历史记录的合并提交”时,才会在部署中跟踪合并请求。从GitLab 17.0 开始,在部署中跟踪合并请求,包括合并方法为快进合并的项目。
为用户定制头像
现在可以使用API 上传任何用户类型(包括机器人用户)的自定义头像。这对于在UI 中从视觉上区分机器人用户(例如组和项目访问令牌或服务帐户)与人类用户特别有用。
识别由管理员模式发起的会话
作为实例管理员,当使用多个浏览器或不同的计算机时,可能很难知道哪些会话处于管理模式,哪些不是。在新版本中,管理员可以转到“用户设置”“活动会话”来确定哪些会话使用管理模式。
在自行管理实例级别管理自定义角色(Ultimate)
在此版本之前,在自建的GitLab 实例上,必须在组级别创建自定义角色。这可以防止管理员集中管理实例的自定义角色,从而导致整个实例中出现重复的角色。在新版本中,自定义角色在自创建实例级别进行管理。只有管理员可以创建自定义角色,但管理员和群组所有者都可以分配它们。
政策机器人评论的可选配置(Ultimate)
当合并请求违反策略时,安全策略机器人会发布评论,帮助用户了解该策略何时在其项目上实施、何时完成评估以及是否存在任何阻止MR 的违规行为,并提供解决问题的指导。这些注释现在是可选的,可以根据策略启用或禁用。这为组织提供了灵活性和控制力,以确定他们希望如何向用户传达这些策略。
自定义角色的用户体验改进(Ultimate)
对自定义角色的用户体验做了一系列改进,具体如下:
创建新的自定义角色时会打开一个新页面。
改进了自定义字符表的设计。
改进了删除自定义角色对话框的设计。
预先检查基本角色的权限。
成员页面显示受邀群组的成员
Beta版提供两种数据库模式
目前大多数自建实例客户只使用单一数据库。为了保证GitLab SaaS和自建实例的设置一致,自建实例的客户需要默认迁移并运行分解。在16.0中,两个数据库连接成为自建实例安装的默认设置。 17.0 中,将结束对自建实例单数据库连接的支持,但对单数据库两连接的支持将持续到19.0。
在17.0 中,两个数据库模式作为有限测试版发布,目标是在19.0 之前普遍可用运行分解。在17.0 中迁移仍然是可选的,但需要在升级到19.0 之前执行。
通过可自定义的语言设置获得更多代码建议
在GitLab VS Code 工作流程扩展中,现在有一个选项可以为代码建议配置其他语言。该功能目前仍是一个实验项目。
GitLab Runner 17.0
GitLab Runner 17.0也同时发布。主要更新内容有:
有关在断开连接的环境中安装Runner Operator 的文档。
GitLab图表改进
GitLab Operator 现在可用于云原生混合安装的生产用途。
global.busybox 删除了在指定自定义BusyBox 值时回退到BusyBox 图像的支持。
对基于BusyBox 的init 容器的支持已在GitLab 16.2 (Helm Chart 7.2) 中弃用,并由基于通用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)
新版本中解决了影响远程规则集的秘密检测错误。可以通过远程规则集覆盖或禁用规则
。远程规则集提供了一种在单个位置配置规则的可扩展方法,可以跨多个项目应用。
用户评论
作为一个频繁参与游戏开发的开发者,我对GitLab最新版17.0的印象非常深刻!它提供了一个通用的CI/CD环境,简化了项目的连续集成和连续部署过程。
有7位网友表示赞同!
使用GitLab 17.0,引入基于Ansible脚本的一键安装包,使得我们的团队能够快速、高效地在新服务器上部署游戏环境,节省了大量的预览时间。
有10位网友表示赞同!
我发现最新的版本中整合的CI/CD流程非常流畅,不仅提升了工作效率还确保了代码质量和稳定性。特别是对于那些有多种分支管理需求的游戏项目来说,这是一个重要的升级。
有16位网友表示赞同!
对于游戏开发者而言,GitLab提供的Ansible脚本自动安装功能是极大的便利,尤其是在需要在多个环境下部署不同的游戏版本时。
有7位网友表示赞同!
自从采用了GitLab的17.0版后,我们团队的时间利用率提升了至少20%,这主要得益于更为精细的持续集成和更快更稳定的CI/CD流程。
有15位网友表示赞同!
对于寻求一个全面解决方案来优化开发过程而言,这个新版本的GitLab确实提供了一个很好的平台。尤其在游戏测试部署阶段,它大大减少了出错的可能性。
有5位网友表示赞同!
我个人非常欣赏GitLab提供的基于Ansible的一键安装包功能,这对于游戏团队来说是极具价值的投资——不仅易于实施而且还极大提升了基础设施的安全性。
有7位网友表示赞同!
从17.0版本切换以来,我注意到的是其对CI/CD流程的改进,使得整个开发和发布过程更高效、更透明。尤其是在游戏中不断调整代码以适应市场反馈时极为便利。
有8位网友表示赞同!
GitLab 17.0在管理游戏开发中的脚本自动化方面做得相当出色,它简化了我们的部署流程,并且确保了每个发布的版本都是经过精心测试的。
有13位网友表示赞同!
作为开发者社区的一员,我很高兴能看到像GitLab这样的平台,不断提供创新功能来支持游戏开发者的日常挑战。17.0版是其中一个最好的例子!
有11位网友表示赞同!
对于依赖云原生和自动化流程的游戏项目来说,GitLab 17.0的CI/CD工具集是不可或缺的一部分。它极大地提高了我们的生产力。
有15位网友表示赞同!
采用基于Ansible的一键安装包后,我们团队得以快速部署游戏环境,并在无需大量手动干预的情况下进行持续集成和发布。
有16位网友表示赞同!
在GitLab 17.0中实现的通用CI/CD目录改善了多平台的游戏开发过程。它为我们的开发流程提供了更大的灵活性和一致性。
有5位网友表示赞同!
对于热衷于采用自动化工具推进游戏项目的人来说,GitLab的最新版无疑是一大利好消息,尤其是新增加的功能让日常操作变得更简便。
有18位网友表示赞同!
我非常推荐给任何寻求更高效、更可控的开发过程的游戏开发者团队使用GitLab 17.0。它为我们带来了显著的改进和便利性。
有8位网友表示赞同!
升级到GitLab 17.0后,我们游戏团队见证了部署速度与流程稳定性的提高,这为我们的产品带来更多的市场机会。
有18位网友表示赞同!
在使用过众多版本后,我对17.0中的通用CI/CD目录赞赏有加。它简化了我们的项目管理,并显著减少了人为错误的机会。
有13位网友表示赞同!
基于Ansible的GET一键安装功能给我们的团队带来了极大的解放感,以前需要大量时间解决的问题现在变得非常容易处理。
有14位网友表示赞同!
对于一直在寻找优化游戏开发流程解决方案的游戏工作室来说,GitLab 17.0是一个值得探索的强大工具,它改善了我们的整体工作流程效率。
有9位网友表示赞同!