22日Gitlab官方发布了Gitlab今年的一个大版本Gitlab13，该版本提供了大量有意义的更新，包括Gitaly集群新架构、WebIDE深黑主题和高亮、免费的设计面板、价值流分析和安全方面的更新，请随虫虫一同学习。
概述
GitLab12.0的总结
在新的里程碑版本13.0发布之际，我们首先总结一下自12.0版发布以来，Gitlab已经取得的成就。版本12发行版中的三个收藏夹包括：需求管理，容器网络安全性和父子管道。除了产品增强功能之外，还接受了合作伙伴关系/集成，为第三方安全扫描程序添加了集成指南，并发展了专业服务来帮助您进行Jira和Jenkins迁移。Gitlab官方新频道Learn
GitLab使可以轻松找到许多新的使用方法视频，例如。迭代是弹性的关键
GitLab使IT和业务团队能够适应，响应和蓬勃发展。快速迭代是关键。为此，必须快速协作，优化效率并自动化流程以处理安全性和合规性，同时专注于交付业务价值。GitLab13.0可以帮助快速迭代并获得更深入的了解。同时，访问Git存储库至关重要，Gitlab已经增强了Gitaly集群以实现高可用性Git存储，以确保在发生中断时始终有多个热备份可以接管。
快速协作并在整个团队中做出回应
GitLab建立在有助于协作开发，报告，组织和管理工作的功能之上。版本控制是协作的基础，从13.0开始，我们添加了。要管理更复杂的项目，13.0允许查看路线图上的Epic层次结构，查看Epic如何与各个里程碑保持一致，并向发行版中添加一个或多个里程碑，同时在使用开放式阻止程序解决问题时发出警报可帮助您专注于关键路径项目。
设计师是开发团队的重要组成部分。在开发最受欢迎的新功能之一（深色主题的WebIDE）时，使用了如何吸引设计人员进行更紧密的协作。同时，Gitlab免费了，是的个人贡献者将产品设计。
优化效率
随着许多企业努力提高响应速度和效率，GitLab有助于简化现有软件开发流程。旨在提高效率的新功能包括简化到AmazonECS的部署以及新的合并警报列表，这些列表提供了一个界面，可汇总源自多个来源的IT警报。此外，Terraform用户也会很高兴。GitLab13.0允许查看terraformplan合并请求中的摘要，并将GitLab用作HTTPTerraform状态后端。
信任流程，不牺牲安全性或合规性
GitLab帮助企业在软件开发生命周期中端到端地采用安全性和合规性控制，从而降低风险并释放资源以专注于关键业务需求。Gitlab应用程序安全测试功能可帮助用户及早发现并修复安全漏洞。
GitLab在年Gartner应用程序安全测试魔力象限中被评为NichePlayer。自Gartner对12.4进行评估以来，Gitlab添加了许多新功能。在13.0中，Gitlab就添加了通过DAST扫描RESTAPI的功能，以及对私密进行完整提交历史记录扫描的功能，从而可以进行更大的检测。更重要的是，重新设计了处理漏洞对象的方式。这使得能够从安全仪表板导出漏洞，并且将来将解锁许多更强大的漏洞管理功能。
除了安全扫描外，GitLab还可以自动执行策略，并在13.0版本中通过新功能提供更精细的控制，例如使用FreezePeriodAPI设置部署冻结，以轻松防止在指定的时间段内意外释放产品。为了简化审核，现在可以将搜索过滤实例级别的审核事件，作为更大的Epic的一部分。
展望未来，即将发布的版本将提供更多的功能：
建立合规框架并自动采用相关的控制和报告；
迭代与更好地了解A/B测试通过几个功能标志增强和控制，过滤功能标志由状态，A/B测试基于特征标志，并且从合并请求创建功能标志能力；
通过直观地将ValueStreamAnalytics阶段描述为流程来识别瓶颈和浪费；
管理策略并让GitLab自动化使用，包括开箱即用的容器网络策略集；
在生态系统中工作以模糊测试应用程序API，并读取VaultCI变量；
GitLab13.0主要功能改进
GitalyCluster高可用集群（PREMIUM及以上）
高可用性（HA）配置通过消除单点故障，检测故障并自动切换到副本来提高重要系统（如Git存储）的可用性。对开发人员和企业保证对Git存储库的正常访问至关重要。发生中断时，开发人员无法推送代码，自动部署无法执行。
GitLab13中不再使用NFS支持Gitlab的高可用，系统的单个组件可能会发生故障，而不会导致最终用户遇到中断。在新架构中Git存储库存储由Gitaly和Praefect共同处理。Praefect是为Gitaly构建的新路由器和事务管理器，用于协调主节点选举和异步复制。在Gitaly群集中，对Git数据的请求通过Praefect路由调度到多个节点中的一个Gitaly节点。如果发生中断，有多个热备份可以接管。未来计划是保证集群的强一致性，以便在成功消息响应之前在多个Gitaly节点上成功执行写操作，并支持水平分布读取，新架构更好地实现CPU和内存资源的横向扩展。
自动部署到ECS
截止目为止，还没有一种简单的方法可以部署到AmazonWebServices。
在Gitlab13.0中，AutoDevOps已扩展为支持部署到AWS。在新版本中，即使未使用Kubernetes，用户也可以使用AutoDevOps部署到AWSElasticContainerService（ECS）。AutoDevOps具有开箱即用的完整交付管道，可简化并加速交付和云部署。只需提交代码，Gitlab即可完成其余工作。通过消除复杂性，团队可以专注于软件创建的创新方面。该工作流程通过下面方法启动：
用户自定义AWS类型的环境变量：
AWS_ACCESS_KEY_ID，AWS_ACCOUNT_ID和AWS_REGION
并启用AutoDevOps。
然后，将通过自动的交付管道为自动构建ECS部署。
在路线图上查看Epic层次结构（ULTIMATE）
在利用多级Epic时，可能很难在路线图中跟踪每个子Epic。在新版本中可以在路线图上快速展开父级Epic，以查看其所有子级Epic，以确保工作被正确组织并按计划的时间表进行。
版本化代码片段
代码片段对于共享不属于主项目代码库的少量代码和文本很有用。这些项目对于依赖执行其他任务的分组及用户很重要，例如脚本可帮助生成诊断输出或为测试和演示环境设置支持服务。然而，由于代码片段缺乏版本控制，因此很难知道其是否为最新版本，或者可能发生了哪些更改以及如何协调这些更改。
GitLab中的代码片段在新版本中交由Git存储库进行版本控制。编辑代码段时，每次更改都会自动创建一个提交。也支持克隆代码片段以在本地进行编辑，然后将其推送回代码片段存储库。
这是在代码片段上实现更多协作的第一步。在未来的版本中，将会引入对多文件的支持，继续扩展功能和扩展权限。
改进的代码片段编辑器
伴随着GitLab13.0中的版本化的代码片段的发布，Snippets的编辑器也被升级为WebIDE中的轻量级编辑器。使用此编辑器，用户将从基本代码补全和某些语言的lint中受益。同时还改进了源代码语言检测，以更好地高亮语法，并增加了对所有语法高亮主题的支持。这些改进将使在片段上进行编辑和协作变得更加容易。
现在代码片段和WebIDE中的编辑器统一一致。在将来的版本中，此功能也将扩展到单个文件编辑器和.gitlab-ci.yml编辑体验中。
WebIDE中的深色主题
对于那些花时间在代码编辑器上工作的人来说，自定义环境以使其首选项匹配的能力很重要。黑暗主题是码农编辑者中最受欢迎的主题，对于提供舒适的体验很重要。GitLab用户也喜欢深色主题，因为所有GitLab的深色应用程序主题是GitLab问题跟踪器中第二受欢迎的要求。
对于选择Dark语法高亮主题提示的用户，GitLabWebIDE现在完全以Dark为主题。这是提供用户喜爱的编辑体验的重要步骤，也是理解GitLabUI如何响应深色主题的宝贵步骤。
在合并请求中查看terraformplan的摘要
如果使用Terraform将基础结构定义为代码，在slack和MR注释中提交terraformplan命令的更改会非常麻烦。在GitLab13.0中terraformplan可以直接在合并请求中在最有用的上下文中查看命令摘要。这可以帮助更快地验证基础结构的更改，并提供了与团队成员协作的地方，以便随着代码更改而对基础结构产生预期的影响。
GitLab提供的Terraform模板的用户将看到terraformplan合并请求窗口小部件，而无需其他配置。用于Terraform的自定义CI/CD模板的用户可以更新其模板，以使用官方GitLabTerraform模板中的图像和脚本。
GitLabHTTPTerraform状态后端
Terraform的用户知道设置状态文件，配置到实际资源的映射，还可以跟踪其他元数据整个过程繁琐而痛苦。步骤包括启动一个新的Terraform项目，以及设置一个第三方后端来存储可靠，安全且不在gitrepo之外的状态文件。
许多用户希望使用一种更简单的方式来设置其状态文件存储，而无需涉及其他服务或设置。
从GitLab13.0开始，GitLab可用作Terraform的HTTP后端，从而无需为每个新项目分别设置状态存储。
GitLabHTTPTerraform状态后端允许以最少的配置获得无缝的体验，并且能够将状态文件存储在GitLab实例控制的位置。可以使用Terraform的HTTP后端（使用GitLab进行身份验证）来访问它们。用户可以轻松迁移到GitLabHTTPTerraform后端，同时还可以从其本地终端访问它。
GitLabHTTPTerraform状态后端支持：
每个项目多个命名状态文件
锁定
对象存储
静态加密
它可用于GitLab自建实例或者GitLab线上仓库。
使用部分克隆排除大文件
通常不建议在Git中存储大的二进制文件，因为每个添加的大文件都会被在以后克隆或pull中被下载。如果网速比较慢或网络连接不再靠谱，将会非常慢，非常影响效率。
在GitLab13.0中，已为blob大小过滤器以及其他过滤器启用了Git部分克隆功能。这样就可以支持从克隆和提取中排除麻烦的大文件。当Git遇到丢失的文件时，将按需下载。克隆项目时，请使用--filter=blob:none或--filer=blob:limit=1m来完全排除blob或按文件大小排除blob块。
注意，部分克隆需要Git客户端为2.22.0及以上版本。关于部分克隆功能虫虫之前的文章中专门介绍过，大家可以参考学习。
使用变量驱动指标仪表板
在GitLab13.0中，可以创建由变量驱动的仪表板，可以使用单个仪表板来监视多个服务和组件，而不是为要监视的每个服务创建硬编码的仪表板。可以创建一个仪表板并使用变量来更改在其中查看的数据，而无需创建类似的仪表板。
使用Puma减少GitLab的内存消耗
在新版本中，Puma是Omnibus和基于Helm安装的Gitlab默认的Web应用程序服务器。与Unicorn相比，Puma将GitLab的内存占用量减少了约40%，从而提高了GitLab的效率，并有可能节省自建实例的成本。
定制了Unicorn进程数或使用速度较慢的NFS驱动器的安装，可能必须调整默认的Puma配置。有关其他详细信息，请参见有关升级和GitLab图表改进的重要说明。
实例级审核事件的筛选搜索
如果需要查找特定事件（用于审计报告或调查事件）时，这应该很容易。手动挖掘大型数据集不需要花很多时间。
在新版本中可以在实例级审核事件表中的单个对象（例如用户，组或项目）上执行过滤搜索，从而使此过程变得更加容易。此功能仅适用于自建实例的客户，但作为更大的Epic的一部分，它将扩展到组和项目，以使实例，组及项目级别的审核事件体验统一且易于使用。
启用组级默认分支保护
此前，将实例级别的默认分支保护设置向下转换为项目是容易引起困惑，带来不直观的体验：开发人员无法将新的提交推送到他们可以创建的项目中。这使组织很难在减轻风险和允许所有开发人员按部就班地访问项目之间取得平衡。唯一的解决方法是需要将他们提升为维护者。
现在，可以在组级别设置默认分支保护，以为管理员和组所有者提供更好的灵活性。通过使用默认分支保护和默认项目创建设置的组合，组织可以找到自主权和控制权的正确组合，例如使用自定义默认分支保护，并且仅允许维护者创建新项目。这将允许开发人员将新提交（而不是强制推送或删除分支）推送到新项目，但允许维护者控制项目的创建。
对于需要更严格控制的组织，可以禁用默认分支保护的组级配置。通过禁用默认的分支保护的组级别设置，维护人员可以对开发人员的访问和权限应用更严格的控件。
价值流分析——任务类型（PREMIUM及以上）
这个功能强大的新图表使团队可以查看交付如何在不同类型的工作中分配。使用标签来查看交付了多少功能以及版本之间的错误，或者给定团队交付了多少项目而另一团队却交付了多少项目。通过反思通过价值流交付的工作的分布，团队可以调整流程以更好地与战略目标保持一致，或更好地平衡团队之间的资源。
价值流分析——提前时间，周期时间指标（PREMIUM及以上）
这两个关键价值流指标为团队提供了一个基准，可以据此对流程改进工作进行衡量，以便他们可以更轻松地查看流程更改的影响。提前期度量了从请求的项目到交付之间所花费的时间。周期时间衡量开发周期本身的长度。通过优化整个价值流的流程，团队可以避免将问题从一个地方转移到另一个地方，从而加快了发货速度。
在使用开放式阻止程序解决问题时引发警告（STARTER及以上）
在12.8中，Gitlab引入了在问题之间创建依赖关系的功能，其中一个问题可以阻止另一个相关问题。这意味着下游问题在之前的任务完成并关闭之前不应该关闭。这要求在关闭问题之前检查是否已阻止该问题。
必须在关闭问题之前检查问题是否被阻止，这是一个不必要且容易忘记的附加步骤。
如果要尝试通过未解决的阻止程序解决问题，则会向显示警告，从而消除了该步骤。Gitlab还提供了阻止问题的链接，因此可以验证问题是否可以安全关闭。
这种增加的依赖项警报级别有助于使项目保持平稳运行，并确保可以保持问题的顺序！
通过Epic树轻松添加Epic或问题（PREMIUM及以上）
在Epic树中创建和添加问题和Epic曾经被拆分为多个按钮和下拉菜单，并且使用起来有些麻烦。在新版本中已将添加和创建操作整合到一个按钮和菜单中，从而使添加新问题和Epic变得更加轻松快捷。
在设计注释中使用表情符号以增强反馈
在13.0中，设计讨论距离GitLab中的评论经验更近了一步。新增加了表情符号支持，现在可以用更有趣和富有想象力的方式传达的反馈。
合并请求的新比较模式
合并请求（尤其是更改选项卡）是查看和讨论源代码的地方。在目标分支已合并到合并请求的源分支的情况下，源分支和目标分支中的更改可以显示为混合在一起，这使得很难理解目标分支中正在添加哪些更改以及已经存在哪些更改。
在GitLab13.0中，新添加了一个实验比较模式，该模式将显示通过模拟合并计算得出的差异-与使用两个分支的合并基础相比，该更改更准确地表示出来。通过选择master（HEAD），可以从比较目标下拉列表中使用新模式。将来它将替换当前的默认比较。
WebIDE的语法高亮主题
查看代码时，GitLab支持六个语法高亮首选项。在GitLab上查看和编辑代码时，主题对于开发人员非常重要，因为必须在一天中舒适地工作。现在，我们已经发布了对WebIDE中所有六个语法高亮首选项的支持。这包括SolarizedDark，Solarized，Monokai和无高亮选项。
在最近的几个发行版中（例如12.8和12.9），Gitlab一直在稳步添加和改进WebIDE中对语法高亮首选项的支持。这些更新是在此工作之后进行的，并有助于为也在13.0中启动的WebIDE中的黑暗主题奠定基础。
直观地突出显示设计注释图钉，以便可以