概述
日期GitLab官方博客宣布其新的版本gitlab 11.10发布，本次升级带来哪些功能呢？请追随虫虫脚步，咱们一起学习尝鲜。
为增强对DevOps生命周期的管理，增加其可视化。新版本对操作面板进行增强，通过面板可以管道状态的浏览。尤其是对多项目的跨项目管道的支持，如果你的项目运行在微服务架构时候，通常需运行管道来部署测试和多个位于不同项目库中代码，通过操作面板现在这些管道的运行状态一目了然。
Git中最方便的就是便利的分支管理，当然这也导致了项目分支的碎片化，这时项目的合并成了个痛点。通常，源分支和目标CI管道都没问题，但是将其合并组合时候就就管道会报错。为了解决这个问题，gitlab 11.10可以在分支合并之前预先对对合并结果运行管道。这样可以帮助我们更加有效定位和排查问题，解决分支合并的痛点。
在GitLab 11.10，gitlab还提供了更多功能来简化协作和优化开发工作流程。在此前的版本中，曾引入了合并请求建议，允许审查者在合并请求中增加单行变更，该注释可以在注释界面中轻松提交。新版对该功能做了改进，可以支持多行变更：指定要删除行，添加行等，而且对分支由权限用户一键单击即可接受更改。
GitLab 11.10主要功能
范围标签(PREMIUM及以上)
范围标签可以让团队能够在问题，合并请求或epic使用互斥标签(共享相同的范围)，解决自定义字段和自定义工作流状态的用例。它们仅使用标签标题中的特殊双冒号语法进行配置。
假设我们需要在问题中自定义字段来跟踪功能所针对的OS支持，每个问题应该只针对一个平台。我们可以根据需要创建platform::iOS，platform ::Android，platform ::Linux等标签。在给定的问题上是哟个用这些标签中的任何一个都会根据自动删除以platform ::开头的其他其他标签。
比如我们有标签workflow :: development，workflow :: review以及workflow :: deployed，表示我们团队的工作流状态。如果问题中已经应用了标签workflow :: development，并且开发人员想要将问题升级到workflow::review，他只需应用该标签，就会自动删除workflow::development标签。当我们在工作流程的问题板中的标签列表中移动问题时，此行为默认运行。
更彻底的容器注册清理
正常使用带有CI管道的容器注册时，通常会将许多迭代修改推送到同一个标记。由于Docker分布式实现方式，默认行为是保留系统中的所有修改，会导致大量空间的占用。通过将-m参数与registry-garbage-collect一起使用，运维管理员现在可以轻松地消除这些历史修改，释放存储空间。
组合式Auto DevOps
Gitlab的Auto DevOps功能使团队能够轻便使用DevOps实践。从11.10开始，Auto DevOps的每个作业都可以作为独立模板使用。使用GitLab CI的include功能，用户只能包含Auto DevOps的某些阶段，并使用自定义的gitlab-ci.yml。这将使团队能够在利用上游所做的任何更新的同时，包含所需的工作。
按目标分支过滤合并请求
用于发布或部署软件的Git工作流通常涉及多个长期运行的分支，比如在向旧版本的后端移植修复或通过QA过程到产品，但是在多条合并请求查找合并请求目标分支的中往往很费劲。
先版本中可以通过合并请求的目标分支过滤项目和组的列表，从而更容易找到要合并的分支。
按创建日期对Wiki页面排序
项目的Wiki页允许团更加便捷地共享文档和其他重要信息。在新版本中，Wiki中的页面列表可以按创建日期和标题进行排序，允许用户快速查找最近创建的内容。
在Grafana仪表板中查看负载均衡指标
为监控GitLab实例运行状态很重呀。在11.9中绑定了Grafana中提供了默认仪表板。从新版本开始，包括新的仪表板来监控omnibus集成的nginx、PSQL,redis和gitaly服务的指标，下面是omnibus综述页面的漂亮仪表盘：
关于Grafana配置虫虫在11.9的文档中介绍过，大家可以查看历史文章。
允许用户更改CI中的克隆路径
默认情况下，GitLab Runner将项目克隆到$CI_BUILDS_DIR的唯一子路径。但是，实际中的某些项目，比如Golang项目，可能需要将代码克隆到要构建的特定目录。
在GitLab 11.10中，gitlab引入了一个名为GIT_CLONE_PATH的变量，允许用户在开始作业之前指定GitLab Runner将克隆到的特定路径。
在组级别启用/禁用Auto DevOps
为了便于使用Auto DevOps使用现代DevOps从构建到部署的工作流，默认是启动Auto DevOps的。
从GitLab 11.10开始，新增加了对任何给定组中的所有项目启用和禁用Auto DevOps的配置。
更新Kubernetes部署标签选择器
部署面板提供了一种简单的方法来深入了解Kubernetes部署。
在新本中，更新了标签与部署匹配的方式。部署面板通过app.xxx/app和app.xxx/env或app进行匹配。此外，从GitLab 12.0开始，会从Kubernetes部署选择器中删除"app"标签匹配，而只会匹配app.xxx/app和app.xxx/env。
组级别集群的组Runner
新版本中组级别的集群以通过Group运行GitLab Runner的安装。组级别的Kubernetes Runner将用cluster和kubernetes标签标记在组内的项目中。
为GitLab CI/CD作业添加git clean标志的控制
默认情况下，GitLab Runner在GitLab CI/CD中运行作业时检查代码的过程中运行git clean。GitLab 11.10中，新添加配置项目，用于控制git clean命令的开关。新变量为GIT_CLEAN_FLAGS默认值为-ffdx，接受git clean命令的所有可能选项。
外部认证的支持
安全环境可能需要使用其他外部授权资源进行检查以允许项目访问。10.6中添加了对这个附加访问控制层的支持，根据社区意见该功能添加到了内核中予以支持。
MR弹出窗口
在新版本中，将鼠标悬停在合并请求链接上时将会弹出一个MR窗口。之前只显示了合并请求的标题，现在增加了合并请求状态，CI管道状态，标题和相对URL。
在未来的版本中，还计划添加其他重要信息，如受让人和里程碑等。并且给问题标签页也增加弹出窗口。
管道成功时推送和合并
基于主干的开发流程中应该避免长期运行的分支，以支持小型，短期，单一所有者分支。通过将最小的更改直接推送到目标分支很常见，但是可能会影响build。
在新版本中，GitLab支持新的Git推送选项，以自动打开合并请求，设置目标分支，并在管道成功通过时启用合并，并推送到分支中。
改进了与外部监控仪表板的集成
GitLab可以访问多个Prometheus服务器(在环境和项目，组级别马上回支持)，但是常见的仪表板工具很难支持或不支持多个端点。在新版本中，团队现在可以与单个Prometheus API接口进行交互，与Grafana等服务的集成变得更加简单。
监视群集请求的资源(ULTIMATE版本)
GitLab可以通过监视交互的Kubernetes集群提供一些信息。从11.10版本开始，可以监视群集请求的CPU和内存资源，帮助在应用程序发生之前发现潜在的影响。
SAST支持Elixir(ULTIMATE版本)
gitlab将对安全扫描中添加对更多语言和深度的支持。在新版本中，增加对 Elixir语言项目启用安全扫描，并可以扩展到对使用Phoenix框架创建的项目的支持。
在组安全性仪表板中显示DAST结果
在组安全性仪表板中添加了动态应用程序安全性测试(DAST)结果，以附带已经存在的SAST，容器扫描和依赖性扫描结果。
在日志中屏蔽受保护变量的值
GitLab提供了几种保护和限制GitLab CI/CD中变量范围的方法。但是，可能会存在变量被有意或无意地暴露到构建日志中。
GitLab 11.10中，添加了屏蔽某些类型变量的功能，增加了一定程度的保护，防止意外泄漏这些变量的内容到日志中。此外，GitLab现在将自动屏蔽许多内置令牌变量。
简化和改进的许可license 页面(STARTER及以上)
为了改善用户体验并简化处理许可证密钥，在管理面板中重新设计了许可页面，并突出显示页面中最重要的元素。
即时Kubernetes资源创建
GitLab的Kubernetes集成通过为每个GitLab项目创建服务帐户和专用命名空间来利用RBAC安全性。从11.10版本开始，为了最大限度地提高创建这些资源的效率，只有在部署需要时才会创建它们。
在进行Kubernetes部署时，GitLab CI将在部署之前创建资源。
显示Knative函数的函数调用计数
新版中，使用GitLab 无服务器部署函数包括为特定函数接收的调用数。为了显示调用次数首先需要在部署Knative的群集上安装Prometheus。
允许开发人员在Core中创建组中的项目
之前gitlab 10.5开始添加了一个可配置选项，允许Developer角色在组中创建项目，新版中这个功能被增加到核心中。项目创建是提高工作效率的关键功能，将此选项移至核心中可增加其稳定性和兼容性。
GitLab chart改进
对GitLabchart进行了以下改进：
添加了对Elasticsearch的支持。
Omnibus改进
GitLab 11.10中对Omnibus进行了以下改进：
GitLab 11.10集成新版本Mattermost 5.9.0，一个开源的Slack替代品，最新版本包括一个新的集成目录，一种从Hipchat迁移数据的简单方法，等等。此版本还包括安全更新等。
新版本中已经对Grafana做了深度集成，因此可以非常轻松地开始监控Omnibus的个组件状态。
添加了从Docker注册清理旧容器映像的支持。
ca-certs更新至2019-01-23。
GitLab Runner 11.10
同期发布了GitLab Runner 11.10，主要更新包括：
添加选项以指定克隆路径。
改进对git clean的支持。
允许用户禁用调试跟踪。
在Windows Cmd中使用延迟变量扩展进行错误检查。
修复Windows上的颜色输出。
更多信息，请参考官方GitLab Runner的CHANGELOG。
性能改进
GitLab持续改善其性能。 GitLab 11.10中带来的性能改善包括：
用户autocomplete更快。
优化用于在搜索时列出项目问题的SQL查询。
Elasticsearch搜索结果不再支持Gitaly。
GraphQL查询应用了复杂性限制。
在启用Prometheus时，禁用diff方法检测以提高合并请求的性能。
提高GitHub Pull Request导入的性能。
基于refnamecommit缓存查找。
通过缓存MR时候文件块差异改进合MR diff的性能。
功能弃用
GitLab Geo将在GitLab 12.0中强制执行Hashed Storage
GitLab Geo需要Hashed Storage来缓解辅助节点上的竞争条件。在GitLab 12.0中，Geo将强制执行Hashed Storage要求。
生效日期：2019年6月22日
Ubuntu 14.04支持
GitLab 11.10是支持Ubuntu 14.04的最后一个版本。Canonical宣布对Ubuntu 14.04的标准支持将于2019年4月结束。建议用户升级到当前的LTS版本之一--Ubuntu 16.04或Ubuntu 18.04。
弃用日期：2019年5月22日
限制单次推送创建的最大管道数
以前，GitLab会为推送中包含的每个分支的HEAD创建管道。这对于可能一次推送多个更改的开发人员来说是有意义的(比如功能分支和开发分支)。
但是，当推送具有许多活动分支的大型存储库时，可能是从另一个位置移动，images或Fork，为每个分支都创建管道没有意义。从GitLab 11.10开始，在推送操作期间创建最多4个管道。
生效日志：2019年5月22日
弃用GitLab Runner老代码路径
从GitLab 11.9开始，GitLab Runner一直在使用一种新方法来克隆/获取存储库。在GitLab 11.0中，更改了为GitLab Runner配置metrics服务器的方式。将删除metrics_server，支持GitLab 12.0中的listen_address。
在11.3中，GitLab Runner开始支持多个缓存提供者，这导致S3特定配置的新设置。这些路径都将在GitLab 12.0不在支持。
弃用日期：2019年6月22日
弃用GitLab Runner的入口功能标志
11.4中，GitLab Runner引入了一个功能标志
FF_K8S_USE_ENTRYPOINT_OVER_COMMAND以解决一些问题。在GitLab 12.0将关闭这些功能标志。
弃用日期：2019年6月22日
GitLab Runner放弃对达到EOL的Linux发行版的支持
在GitLab 12.0中，GitLab Runner将不再向达到EOL的Linux发行版分发软件包。
在GitLab 12.0起，GitLab Runner将不再向这些Linux发行版发布版本。
弃用日志：2019年6月22日
删除旧版GitLab Runner Helper命令
作为支持Windows Docker执行程序的一部分，将会弃用一些就的帮助程镜像命令。
从GitLab 12.0中，GitLab Runner将使用新命令。这仅影响覆盖帮助镜像的用户。
弃用日志：2019年6月22日
从GitLab Runner中删除传统的git clean机制
在非受保护的分支上删除或修改Git标记的发行说明历来仅限于维护者和所有者。
由于开发人员可以添加标签以及修改和删除未受保护的分支，因此开发人员也应该能够删除Git标记。在GitLab 11.10中，将对对权限模型进行更改，以改进工作流程并帮助开发人员更好，更有效地使用标记。
弃用日志：2019年4月22日
管理面板中的"系统信息"部分
GitLab在admin/system_info中显示有关GitLab实例的信息，但此信息可能不准确。
GitLab 12.0中将删除管理面板的这一部分，建议使用其他监控功能。
弃用日志：2019年6月22日
TLS v1.1弃用
从GitLab 12.0开始，默认情况下将禁用TLS v1.1以提高安全性。这可以解决问多安全问题，比如"心脏出血"漏洞，并使GitLab开箱即用，符合PCI DSS 3.1标准。
现在要立即禁用TLS v1.1，可在gitlab.rb中设置nginx ['ssl_protocols'] ="TLSv1.2"并运行gitlab-ctl reconfigure。
弃用日期：2019年6月22日
用于安装GitLab的OpenShift模板
官方的gitlab helm chart是在Kubernetes上运行GitLab的推荐方法，包括在OpenShift上的部署。
不推荐使用的OpenShift模板，该模版将在GitLab 12.0中移除。
弃用日期：2019年6月22日
老安全作业定义
为安全作业引入CI/CD模板，不在推荐使用老的作业定义，这些定义将在GitLab 12.0或更高版本不在支持。更新你的作业定义以使用新语法，以便从GitLab提供的所有新安全功能中受益。
迁移日期：2019年6月22日
安装更新
新版本的安装更新比较方便，直接使用发行版的包管理器安装升级即可，比如在centos，直接使用
yum update gitlab-ce
更新成功后显示：
