前天，按Gitlab一贯的发版规律，Gitlab官方发布了又一个里程碑大版本GitLab14.0。在GitLab14中，GitlabDevOps工具链更加现代。GitLab14是一个完整的DevOps平台，其中贯穿了安全性、单数据存储支持下可见性和洞察力，支持无缝集成和可扩展系统，用户和企业从中获得速度和效率的收益，其详尽的功能请随虫虫一起学习。
GitLab14.0主要功能
Epic面板
Epic面板通过持续传达Epic状态来调整团队和组织。之前版本的GitLab要求列表中查看和排序Epic以查看整体状态。Epic面板在一个统一的地方可视化和优化所有Epic，使用可自定义的拖放界面，任何用户都可以轻松理解和协作。
Epic面板也是管理和可视化理想Epic工作流的游戏规则改变者，例如创作工作流状态（草稿、写作、完成）、DevOps工作流状态（例如计划、开发和生产中）或任何其他互斥的说明可以使用范围标签进行建模。使用Epic面板可视化工作流程使能够提高可预测性和效率。
Terraform模块注册表
Terraform模块在构建整个组织的标准基础架构组件方面发挥着核心作用。在GitLab13.12更老的版本中，GitLab用户必须使用第三方Terraform模块注册表、本地模块或基于Git的模块。虽然这些选项运行良好，但它们无助于模块的分发，并且它们缺乏适当的版本控制支持，这给模块用户带来了风险。GitLab14.0使用Terraform模块注册表扩展了IaaS。现在，可以使用GitLab中内置的Terraform模块注册表来发现具有语义版本控制支持的Terraform模块，以支持升级和维护。此外，还可以使用GitLabCI/CD轻松发布模块。
在遵循Terraform的最佳实践的同时，建议在专用的GitLab项目中开发每个Terraform模块。为了简化到注册表的转换，用户可以从单个GitLab存储库托管和发布多个模块。
简化的顶部导航菜单
GitLab14.0引入了全新的、简化的顶部导航菜单，可帮助用户以更少的点击次数更快地到达目的地。新的菜单提供了以前的项目、组和更多菜单的组合功能。只需单击一下，就可以访问项目、组和实例级功能。此外，全新的响应式视图改善了小屏幕上的导航体验。
VSCode中合并请求评论
作为一名开发人员，通常大部分时间花在本地开发环境中。当被分配了一个合并请求进行审查时，需要离开编辑器并在GitLab内执行该审查。在GitLab中执行审核时，可能还需要使用本地编辑器来获取有关更改的更多背景信息。
适用于VisualStudioCode(VSCode)的GitLab工作流3.21.0版本现在支持完整的合并请求审查过程，包括线程。在VSCode中选择GitLab图标以打开侧边栏以显示正在审查的合并请求。选择合并请求概述以查看合并请求的完整详细信息和讨论。
侧边栏还包含合并请求中所有更改文件的列表。选择文件会打开差异比较，供查看VSCode中的更改。在查看差异时，可以阅读文件上留下的反馈，并通过选择行号和创建评论来创建新评论。在VSCode中提供的所有评论和反馈都可以在GitLab网络界面中找到，让开发者可以轻松地在VSCode中执行评论。
全新设计的侧边栏
GitLab很大，而且功能越来越丰富。随着新的功能和类别的引入，密集的左侧边栏导航变得不那么直观了。
GitLab14.0中，重新设计和重构了左侧边栏，以提高可用性、一致性和可发现性。新版本中一些指向周围功能的链接，将“操作”菜单中的功能分成三个不同的菜单，改进了视觉对比度并优化了间距，以便所有菜单项都可以舒适地放在较小的屏幕上。这些更改旨在更好地匹配DevOps生命周期心智模型，并在项目和组中导航时提供更可预测和更一致的体验。
使用WYSIWYGMarkdown编辑器编辑wiki页面
许多GitLabwiki使用Markdown格式，对于一些用户来说，Markdown是高效协作的障碍。在新版本中，现在可以在wiki使用丰富、现代的Markdown编辑体验，因此可以放心地进行编辑。
即时反馈和可视化编辑工具有助于使wiki编辑更加直观，并消除协作障碍。完成后，GitLab会将更改保存为Markdown，因此想要直接编辑Markdown的用户可以这样做。甚至可以在新编辑器中输入Markdown，它会在输入时自动格式化文本。
GitLab14.0将内容编辑器引入Wiki，支持大多数基本Markdown内容类型，如标题、粗体和斜体文本、列表、代码块和链接。对整个GitLabFlavoredMarkdown规范的全面支持将在即将发布的版本中提供。计划在未来在GitLab的其他领域提供内容编辑器。
集群管理项目模板
在新版本中，不再使用基于CI/CD模板的集群管理方法。集群管理是管理Kubernetes集群以提高在集群上运行的应用程序可用性的能力。旧方法隐藏了太多逻辑，限制了应用程序的自定义和扩展。使用新方法，可以轻松地从项目模板创建集群管理项目并完全控制您的应用程序。使用新模板创建的项目包含集群管理作业所需的代码，包括对多个应用程序的内置支持。可以轻松地将项目扩展到其他应用程序并完全拥有它们。
此外，将使用Helmv3安装新应用程序。如果以前使用Helmv2安装了GitLab托管应用程序，请查看Helm迁移指南和GitLab托管应用程序迁移指南。CI/CD作业输出还将指导完成这些迁移。
在GitLab14.0中，集群管理项目仅支持基于证书的集群集成。计划在下一个版本中添加对GitLabKubernetes代理的支持。
使用初始模板预填充CI/CD管道编辑器
GitLab中的管道编辑器是和CI/CD管道交互时的一站式工具。以前，在使用编辑器编写第一个管道时，会看到一个空白配置。虽然对于经验丰富的管道作者来说非常有用，但对于那些刚刚开始的人来说，这是一个飞跃。
在新版本中，如果项目没有配置管道，编辑器会预加载3阶段管道的示例模板。用户可以立即保存并运行此管道，以查看它在项目中的运行情况。最重要的是，它还具有详尽地语法的注释，以及帮助开始自定义模板以满足需求的提示。
组级别合并请求的提前期（ULTIMATE）
作为GitLab中本地支持DORA4指标的努力的一部分，合并请求图表的提前期现在可在组级别使用。新版本中扩展了GitLab13.11中完成的工作，可以使用一个图表来显示将合并请求部署到生产环境（不仅仅是在单个项目中，而是跨组聚合）所需的时间。可以全面了解多个项目的吞吐量。
项目级价值流分析的水平导航
项目级价值流分析的各个阶段现在以水平布局显示。这有助于可视化价值流各个阶段的工作流程。它还与集团级价值流分析中的导航体验相匹配。
用于将组添加到DevOps采纳表的改进界面（ULTIMATE）
DevOps采纳表通过按组和子组进行比较，深入了解GitLab在整个组织中的采用情况。以前，最多可以向表中添加个组，较大的组织可以拥有数千个GitLab组。现在可以使用可搜索的下拉列表将任何子组添加到表中。
跟踪代码所有者的使用情况（ULTIMATE）
代码所有者是GitLab中代码审查过程的重要组成部分。当代码所有者被明确标识时，贡献者可以看到谁应该审查对文件或存储库的贡献。代码所有者功能还可用于建立合并请求批准流程。现在，可以跟踪组织中的哪些团队在其开发工作流程中使用代码所有者功能。
如果想推动代码所有者的采用，请按代码所有者列对DevOps采纳表进行排序，以查找尚未采用该功能的团队，以便可以轻松确定哪些团队需要帮助入门。或者，查找已成功配置代码所有者的团队并获取提示和反馈。DevOps采纳表在组级别和实例级别可用。
Wiki编辑的Slack通知中包括指向差异的链接
Slack通知服务可以在用户编辑Wiki页面时通知。Slack消息为提供有关编辑的有用上下文，包括项目、页面名称和提交消息。但是，有时，提交消息没有提供足够的上下文，需要有关内容如何更改的更多信息。
现在，可以单击Slack消息中的比较更改以立即查看差异，从而节省时间并减少因不明确或不完整提交消息而造成的混淆。
用于环境操作的预定义CI/CD变量
如果想使用environment:关键字在部署作业之间重用脚本和配置，则很难根据部署作业执行的操作类型排除某些行为。例如，一个environment:actionofstop可能是一个停止a的作业review_app，并且不希望您的部署脚本运行。
新版本中environment:action:的值可用作CI_ENVIRONMENT_ACTION预定义的CI/CD变量，从而比以往任何时候都更容易配置一个适用于所有部署作业的脚本。
组或子组安装PyPI包
可以使用项目的包注册表来发布和安装PyPI包。当安装PyPI包时，必须指定该包所在的项目。如果项目数量较少，这很有效。如果在一个组中嵌套了多个项目，可能很快会发现自己添加了数十个甚至数百个不同的源。
对于拥有多个团队的大型组织，团队通常将包与源代码和管道一起发布到项目的包注册表。但是，他们还必须能够轻松安装来自组织内其他项目的依赖项。现在可以在组级别安装包，因此不必记住哪个包位于哪个项目中。为此，可以使用简单的API来指定包：
GETgroups/:id/packages/pypi/files/:sha/:file_identifier.
还可以将输出写入文件，或将包描述符作为HTML文件返回。
功能标志用户列表
以前，要访问用户列表，必须导航到“功能标志”页面下的单独选项卡。这种设计模糊了特征标志和用户列表之间的关系，因为用户列表是特征标志的一个子特征。在性能版本中，用户列表现在位于功能标志的子页面下，这改进了工作流程并使它们之间的关系更加清晰。
动态更新事件服务级别协议计时器（PREMIUM）
GitLab13.5中引入的事件服务级别协议(SLA)计时器显示了事件违反SLA之前的剩余时间。但是，用户必须刷新页面以更新计时器。从GitLab14.0开始，无需刷新页面，计时器每15分钟动态更新一次。
数据库负载平衡免费开放
GitLab的数据库负载平衡器支持跨多个数据库服务器分发只读查询。对于拥有数千用户的GitLab实例，使用负载均衡器可以减少主数据库的负载并提高响应速度，从而加快GitLab内的页面加载速度。
在新版本中，负载均衡器从高级版免费开放，以让更多用户受益于此功能。
升级RubyonRails到6.1
在新版本中，RubyonRails升级到了6.1版，以利用应用程序框架的最新改进。
性能栏显示使用了多少内存
性能标准允许系统管理员和软件开发人员能够了解GitLab页面的性能。提高所用内存的可见性对于软件开发人员很重要，因此可以提高GitLab的性能和用户体验。在新版本中，新添加了一个内存字段，用于显示消耗的内存量和为当前请求分配的对象。选中后，将显示一个带有附加信息的视图。有了这些信息，软件开发人员就可以更早地发现内存问题，并开发出更多内存效率和性能更高的功能。
在组级别识别已配置的用户
在新版本中，添加了识别配置用户和贡献者的功能。针对已配置的用户显示新的企业标签。这有助于用户识别组通过SCIM自动化创建的帐户，而不是用户手动创建的帐户。
默认情况下启用实例级DevOps使用报告（ULTIMATE）
现在默认启用实例级DevOps使用报告。DevOps使用报告显示组织中正在使用GitLab的团队的信息：
问题、合并请求、批准、Runner、管道、部署、扫描。
通过将组添加到采纳表，比较整个组织中GitLab的使用情况。可以使用DevOps使用报告方式有：
验证是否从GitLab获得了预期的投资回报。
确定在采用GitLab方面滞后的特定群体，以便可以帮助推进。
确定采用了特定功能（例如管道）的组，并向对开始使用这些功能感兴趣的其他组提供提示。
这只是衡量组织中DevOps使用情况并评估收益，要了解接下来要添加的内容，DevOps使用报告也可在组级别获得。对于SaaS用户，通过查看顶级组中的DevOps使用报告，获取整个组织的使用情况。
在GitLab用户配置文件上设置代词
代词已添加到GitLab用户配置文件中。代词出现在“个人资料”选项卡中的用户名旁边，可以用来：
决定是否在个人资料中添加代词。
自我识别并输入您喜欢的任何代词，无需从预定义列表中进行选择。
除了更具包容性之外，GitLab还希望帮助人们在回复评论时使用正确的代词以尊重人们的身份。
Fork时编辑默认路径和项目名称
Fork项目使用户能够拥有原始存储库的精确副本，在其中进行试验、应用更改并提交对父项目的贡献。分支应该具有有意义的名称来解释其目标，如果项目有Fork，可能需要一个项目的多个分支。
在新版本中，GitLab支持在创建fork时直接编辑项目名称和项目slug。现在可以为同一个项目创建多个分支，每个分支都有不同的名称，都在同一个组中。
添加“~”到CI/CD变量掩码支持字符
必须安全管理存储在CI/CD变量中的密码。可以通过屏蔽变量来隐藏作业日志中的变量值，但GitLab仅支持某些字符。新版本中支持在值中使用“~”来屏蔽变量，这扩展了该功能以支持从其他秘密提供者平台生成的更多秘密。
确定哪些作业触发了下游管道
此前，在查看管道视图时，很难确定哪个作业触发了下游管道。从14.0开始，每个下游管道都会显示触发它的作业的名称。这使得在触发下游管道的复杂管道中跟踪执行流变得更加容易。
通过UI删除关联的包文件
可以使用GitLab包注册表来发布、安装和共享依赖项。当发布依赖项时，会生成多个文件，包括包存档。在GitLab14.0之前，要删除此类文件，必须使用API。GitLab14.0中，现在可以使用UI删除与给定包相关的文件以及包本身。
由于维护整洁的注册表可能具有挑战性，因此目标是通过添加更多关于如何删除未使用文件的选项，让流程更轻松、更高效。
更改问题的类型
在某些情况下，可能希望更改问题的类型。例如，可能希望将问题升级为事件，以确保团队正确处理问题。要更改问题的类型，请编辑问题并从问题类型选择器菜单中选择问题类型。
Grype的容器扫描集成（ULTIMATE）
GitLab容器扫描现在可以选择使用Grype扫描引擎而非默认的Trivy引擎。这为用户提供了选择容器扫描引擎的灵活性和选择。对两款开源扫描仪进行了比较。但是，由于每台扫描仪都是独一无二的，可能希望自己进行比较以决定哪种扫描仪最适合。用户可以通过设CI变量来试Grype扫描仪：
CS_ANALYZER_IMAGE:registry.gitlab/security-products/container-scanning/grype:4。
REST和GraphQLAPI中可用的项目存储位置
随着散列存储的引入，将不好发现项目的存储位置。系统管理员能够在项目的管理UI上查找路径，但对于许多项目来说这样做是不切实际的。在新版本中，新添加了公开项目存储信息的API接口。在RESTAPI中，这个接口是
GET/projects/:id/storage.
对GraphQL，该diskPath字段现在在Repository对象中可用。
GitLabRunner14.0
同期还还发布了GitLabRunner14.0。新功能包括：
WindowsRunners下默认shell为pwsh；
引入Ubuntu风格的runner-helper镜像。
修复一些Bug：
PowerShell不能与FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY设置为false一起使用;
在shell执行器中永久阻塞Go例程;
失败原因job_canceled可以发送给Rails，失败并返回错误
GitlabRunner无法解析GitlabURL-Kubernetes执行器的bug。
Omnibus改进
GitLab14.0包括Mattermost5.35.3。由于引入了即将推出的新功能所需的后端数据库架构，v5.35版本的迁移过程的性能受到显著影响。根据数据库的大小、类型和版本，升级时间应该会比平时更长。这可能从几分钟（平均情况）到几小时（最坏情况，仅限MySQL5.x）不等。在此过程中，还应该预期数据库CPU使用率会出现中度显著峰值。v5.35.3引入了搜索文件的新功能以及批量用户导入期间使用的密码生成逻辑的一些更改。管理员应立即重置批量导入过程中生成的所有用户的密码，并且其密码甚至一次都没有更改。v5.35.3还包含高级安全修复，建议升级。
此前，新的GitLab实例会在安装后默认提示用户输入初始root密码，这意味着匿名用户可以先到达那里设置root密码并进行控制。新版本中，如果用户未提供初始root密码，则会随机创建一个。这提高了新部署GitLab实例的默认安全性。
OmnibusGitLabdocker镜像中现在包含BusyBox，但删除了作为预安装编辑器的vim和nano。BusyBox汇集了许多其他工具的最小版本，通过将BusyBox设为默认编辑器，可以获得许多在容器内部调试时有用的其他工具。
安全和合规性审计
合并相同的DAST漏洞聚合为一个漏洞（ULTIMATE）
在GitLab13.12及更早版本中，扫描中发现的所有DAS漏洞都针对发现漏洞的单个URL列出。当修复为单个文件或配置更改时，这可能会产生许多漏洞。例如：每个HTTP响应一起发送的服务器标头的问题将在站点的每个页面上报告，而不是报告为多次出现的单个问题。
为了减少管理漏洞的开销，GitLab将在多个页面上发现的相同漏洞合并到DAST报告中的单个报告漏洞中。漏洞详细信息包括发现漏洞的所有URL的列表，而不是在每个页面的漏洞列表和仪表板中创建的单个漏洞。
新的报告功能不会追溯组合以前扫描中发现的漏洞。它仅适用于在GitLab14.0及更高版本中执行的扫描。
默认情况下强制执行SSH密钥过期
添加到GitLab的过期SSH密钥现在默认禁用。这将有助于使GitLab实例更加安全。以前，添加到GitLab的过期SSH密钥默认启用，除非管理员明确禁用，否则可以使用。
此更改会影响GitLabSaaS上使用的过期SSH密钥。如果密钥已过期或即将过期，需要更新密钥和使用它们的任何服务。我们关于SSH密钥的文档提供了有关如何创建新SSH密钥的有用步骤。
自建实例的管理员仍然可以配置允许使用过期的密钥。
安全报告广义细节结构（ULTIMATE）
自动安全扫描是任何安全开发过程的重要组成部分。有各种各样的工具和技术涵盖了从源代码扫描到部署后应用程序和基础设施扫描的整个SDLC。虽然这些工具中的任何一个的最终目标都是发现已知和潜在的漏洞，但来自任何给定扫描仪的信息可能会有很大差异。确实存在对扫描输出数据进行标准化的努力，但他们往往只