昨天Gitlab官方博客发布了Gitlab新的月度版本Gitlab13.1，该版本搭理扩展了告警管理，新增加了改善代码质量的工具集以及安全和合规方面的内容，更多内容请和虫虫一起往下学习。

分配告警给团队成员

在GitLab 13.1中，可以将GitLab告警分配给团队中的特定用户，简化分类工作流程，委派需要调查的问题，并确保不会丢失任何严重告警。

管道失败后自动通知

每当管道发生故障时，都会自动收到一封电子邮件通知。但是，如果管道在失败后成功，则不会发送自动通知，这需要手动检查管道的状态。在新版本中引入了一个功能自动通知管道在失败后是否成功。

告警分配记录在系统注释中

指标仪表板面板显示相关的仪表板链接

指标仪表板通常与其他仪表板相关。使用仪表板链接，可以显示指向相关的GitLab指标和Grafana仪表板的链接，这些链接保留了当前正在查看的仪表板的时间窗口。

指标仪表板面板显示外部链接

指标仪表板在方便向下钻取时最有用。在GitLab 13.1中，可以将自定义URL添加到指标仪表板中面板的”更多操作”菜单中，将指标面板和仪表板与其他指标仪表板以及团队使用的其他故障排除工具进行交叉链接。

指标仪表板配置验证

配置仪表板YAML文件可能很复杂且容易出错。如果仪表板YAML定义无效，GitLab 13.1会自动对YAML文件进行验证，并通过显示警告消息来帮助诊断指标仪表板问题。

在环境中设置功能标记策略(PREMIUM及以上)

在新版本中，重新设计了功能标志UI，启用针对多种环境的设置策略。此前，随着环境数量的增加，管理功能标记和设置策略要困难得多。这项改进可以实现更灵活地在大规模环境中创建策略并将其应用于环境。

将设计线程标记为已解决

使用13.1，可以将任何评论标记为”已解决”，以表示该评论现已完成。更好的是，已解决的注释图钉将会从设计中消失，使得，设计人员可以专注于剩下的内容。如果需要重新访问某些内容，所有已解决的线程将在侧边栏底部的”已解决的注释”区域中。从那里，可以再次找到它们，并查看哪个修订版本适用于该修订版本。这将大大改设计的工作流程，让设计人员因专注于重要的事情。

代码感知

代码审查是一个重要的过程，需要了解建议的更改和周围的代码，以了解是否已以可维护的方式进行。在编写新代码或查看对现有代码的更改时轻松浏览定义，使开发人员可以更好地理解所编写的软件。在查看新代码以及合并请求中的代码更改时，这非常有用。但是，设置可浏览的定义通常意味着配置外部工具和资源，或使用专用的IDE。有了GitLab，情况就不再如此。

在13.1版本中，以LSIF格式为基础，通过在项目.gitlab-ci.yml文件中添加新作业(指定LSIF 告)可以将GitLab的本机代码感知添加到任何项目中。生成后，无需外部工具和IDE，将鼠标悬停在代码中的对象上就可以显示的代码感知操作。未来的迭代将包括查找引用的能力以及API支持。

图形代码覆盖率随项目的变化而变化

一个项目常常有一个代码覆盖率目标，但是开发团队可能对目标值随着时间的变化趋势不太了解。需要一种更简便的方法来跟踪代码覆盖率随时间的变化，而不会带来额外的麻烦。

现在，”代码覆盖率”图可以更好地了解代码覆盖率随时间变化的趋势。它显示管道中计算的覆盖率值的简单图形。

问题标题固定

在新版本中，无论阅读的是问题的哪一部分，问题标题将始终始终显示在问题的顶部。这确保始终具有上下文，无论单击的是深层对话线程的链接，在问题中滚动得很深还是正在使用多个类似问题的选项卡。

蓝绿色部署文档

该文档一个使用NGINX进行蓝绿色部署的示例，示例直接从.gitlab-ci.yml文件中交换部署。如果使用类似的配置，此示例将帮助设置蓝绿色部署，并提供可针对其他类型的应用程序进行自定义的指导。

更快地分配问题

GitLab喜欢使用户工作流程尽可能简单。现在，可以通过单击按钮将问题分配给评论者，在评论旁边。这样可以让注意力和精力集中在注释周边，而不会导航至侧面板或使用快速分配命令。

指定发布链接的资产类型

新版本中，GitLab允许使用下拉菜单方便地指定已添加到发布中的资产链接的类型。以前，如果添加了到发行版的链接，则无法传达它是什么类型的资产。使用此添加项，可以从以下选项中选择资产类型：” Runbook”，” Package”，” Image”或” Other”。

更出色的面面检测和新的独立密码检测模板(ULTIMATE)

密码检测已从SAST的子功能提升为它自己的类别。现在，”密码检测”发现更加可见，显示在合并请求和管道安全性选项卡中的自己的部分中。现在，”秘密检测”还将在”安全性配置”页面上显示配置状态，并在”项目安全性仪表板”中显示发现。

密码检测CI/CD配置设置在单独的GitLab提供的模板中提供，并作为新的安全扫描类型运行。Auto DevOps现在也包含了这个新的密码检测模板。建议实施此新模板，然后从文件中的SAST配置模板中删除旧的SAST secrets-sast作业定义。以后的GitLab版本中弃用旧的SAST秘密作业定义SAST.gitlab-ci.yml。

SAST扫描Helm支持(ULTIMATE)

针对Kubernetes清单的已更新，支持Helm Charts。此更新还增加了对两个新环境变量KUBESEC_HELM_CHARTS_PATH和KUBESEC_HELM_OPTIONS的支持，以自定义分析仪设置。

贡献分析现在显示批准(STARTER及以上)

安全仪表板上的动态问题状态图标(ULTIMATE)

以前，在”安全性仪表板”中，具有相关问题的漏洞列表项显示一个带有该问题链接的静态图标。通过改进可用性，该图标现在可以动态反映问题是打开还是关闭。一目了然，您现在可以判断是否可能需要进一步关注漏洞。

Bug修复

13.1中一些值得注意的BUG修复有：

如果通过UI创建发布，则不会收集GitLab发布证据；

图片在发布列表面板中溢出；

版本说明中的Markdown格式未正确显示；

显示上游管道中的下游管道错误；

尝试通过Jobs API下载标记引用的工件存档失败，并显示” 404 Not Found”；

验证实例级别变量的值的大小；

在禁用管道，合并请求”必须成功”选项处于启用状态并且禁用了外部管道时，显示准确的错误消息；

搜索提交时遵从”ref”参数；

确保设置Elasticsearch highlight.max_analyzed_offset整个GitLab应用程序中参数；

修复Elasticsearch版本7.7.0的嵌套数组问题；

将机密问题中的注释显示为机密注释的bug；

在Epic树中显示通过API添加到Epic的问题；

通过API按标题添加时，按顺序应用范围标签；

NOT为Epics 启用布尔过滤器；

性能改进

在GitLab 13.1中，提供了CI管道处理，查看git blame等方面的性能改进。GitLab 13.1中的性能改进有：

对blame文件延迟加载加载提交日期和创作日期；

当查看文件时缓存内容；

优化的CI管道处理；

功能弃用

作业的默认存档时间设置为3个月

变更日期：2020年6月22日

为了帮助使用gitlab官 的所有工作存档日期将设置为3个月。作业存档后：可以对归档作业执行的操作和不能执行的操作如下：

仍然可以查看作业，日志，关联的管道和部署，以及重新运行整个管道。

无法重试，重新运行或触发该作业，也无法触发该作业的部署。

2020年3月22日之前生成的现有作业将在2020年9月22日之前存档。

默认工件过期在gitlab.com上更改为30天

变更日期：2020年6月22日

为了帮助维护使用gitlab官 整体性能，工件的到期时间将在被设置为30天。在更新的作业生成新的工件后的30天之前，将不会归档来自上一个成功作业的工件。没有到期日期的工件不会更改，但是以后的更新也会为其添加到期日期。

AWS ECS的部署模板正在移至新位置

变更日期：2020年7月22日

更改了Deploy to AWS ECS gitlab-ci.yml模板的位置。如果用户已在CI/CD配置中引用了此模板，请通过替换template: Deploy-ECS.gitlab-ci.yml为对其进行更新template:AWS/Deploy-ECS.gitlab-ci.yml。目前正在扩展受支持的AWS目标，并且所有将来与AWS相关的模板都可以在AWS template文件夹中找到。

在SAST配置中弃用秘密检测作业

变更日期：2020年9月22日

新版本中，密码检测CI/CD配置设置被挪到一个单独的GitLab模板中，并作为新的安全扫描类型运行。为确保项目继续运行密码检测，建议使用新的秘密检测模板，然后从文件中的SAST配置模板中删除旧的SAST secrets-sast作业定义。

GitLab 13.4即将取消对旧的SAST秘密作业定义的支持。

Auto DevOps弃用Herokuish支持

变更日期：2020年10月22日

GitLab正在将Auto DevOps从Herokuish buildpack迁移到Cloud Native Buildpacks，Herokuish将从根本上弃用，Cloud Native Buildpacks是buildpack支持的下一个迭代。

GitLab 12.10及更高版本将支持Cloud Native Buildpacks。所有新的Auto DevOps项目将于下个月开始使用Cloud Native Buildpacks，Herokuish支持将在2020年10月取消。

不建议使用Kubernetes 1.12和1.13进行集成

变更日期：2020年9月22日

为了将Kubernetes与GitLab集成，Gitlab引入了Kubernetes支持策略，为Git用户提供明确的升级时间表。计划：

GitLab对Kubernetes 1.12的支持将于2020年9月22日终止。

GitLab对Kubernetes 1.13的支持将于2020年11月22日终止。

在这些变更之后，各种GitLab功能可能仍然可以使用，但是将不会得到官方支持。GitLab同时致力于增加对最新Kubernetes版本的支持。

Kubernetes 1.12已被弃用

变更日期：2020年8月22日

从GitLab 13.2开始，Kubernetes 1.13将成为部署GitLab时受支持的。Kubernetes 1.12 不再在上游维护，最近已被流行的容器管理服务(如GKE和EKS)删除。

旧功能标志弃用

变更日期：2020年9月22日

在13.1之前创建的功能标志与正在开发的新体系结构不兼容。从13.1开始，默认情况下，GitLab在线仓库将启用新系统创建所有新功能标记。从13.2开始，对于自建实例也是生效。在早期版本中创建的功能标志可以使用到13.4，然后它们将变为只读。在14.0中，所有旧版功能标志将被完全删除。

Git 2.25或更高版本

变更日期：2020年6月22日

从GitLab 13.1开始，GitLab需要Git 2.25或更高版本。Omnibus安装包括Git 2.27。从源安装的实例必须手动升级。

计划删除安全扫描程序的Docker-in-Docker(DinD)

变化日期： 2020年9月22日

为了提高安全性并降低扫描的复杂性，在13.0中已弃用GitLab Secure扫描器中的Docker-in-Docker(DinD)，并计划在13.4中将其删除。默认情况下，GitLab安全产品开始在GitLab 13.0中的供应商模板中使用非DinD模式。Gitlab鼓励用户更新其供应商的模板以使用此新行为。如果您覆盖或使用自定义Secure CI模板，则可以按照以下指南从现有作业模板中禁用Docker in Docker(DinD)：

在Docker中禁用Docker进行依赖性扫描(12.10文档)

在Docker中为SAST禁用Docker(12.10文档)

升级更新

Omnibus安装

Omnibus套件安装的实例可直接使用Linux包管理器可以升级。

比如CentOS使用:

yum updata/install gitlab-ce

即可自动完成升级：

相关资源：国标软件设计文档(操作手册(GB8567——88),测试分析 告(GB8567…