上个月22日，GitLab官方blog按照惯例发布了有一个月度版本12.7。在12.7中，做了多项改进，包括父子管道，管道资源组、blame视图、结构化日志等。关于本次发布的功能介绍，请和虫虫一起学习。
主要功能介绍
父子管道
复杂的应用程序通常需要复杂的管道，这可能会导致执行变得缓慢且不好排查管理。随着管道复杂性的增加，其可视化会变得越来越笨拙，配置更加复杂，执行速度也变慢。此时，将复杂的管道分成多个管道（以父子关系进行组织）可以提高性能并使管道清晰：因为子管道可以同时运行，所以可以提高性能，而配置和可视化可以分为不同的部分文件或视图。新版本GitLab12.7中，可以使用单独的YAML文件定义这些单独的管道。.gitlab-ci.yml仍然是主要配置入口，但是可以在这个主配置中可以include任何其他YAML文件作为其自己的子管道，并归还给父管道。还支持使用include来促进这些不同管道之间的代码重用。
GitLab在线仓库Beta版Windows共享运行程序
GitLab托管的WindowsSharedRunners推出测试版。可以利用该托管，实现自动缩放和安全的环境，可与GitLab在线仓库在同一GCP基础结构上的Windows虚拟机上运行CI/CD作业。WindowsSharedRunners已预先配置了各种软件包，例如Windows的Chocolately软件包管理器，VisualStudioBuildTools和Microsoft.NetFramework等。
当然也可以继续在自己的基础架构上安装和管理WindowsRunner，以与GitLab团队管理的新可用GitLab在线仓库Runners一起使用或互相替换。
具体请参考WindowsRunnersbeta官方相关文档。
管道资源组
大多数情况下，用户希望尽可能并行化其CI/CD，以加快总运行时间。但是，在某些情况下，可能希望限制并发性。例如，如果要防止作业在同一环境中同时在不同的管道中执行。当广泛使用诸如智能手机，计算机芯片或嵌入式IoT设备之类的物理硬件来运行测试之前，经常会看到这种情况。尝试从多个管道甚至同一管道中的多个作业同时运行测试可能会导致数据损坏，无效的测试结果，甚至使硬件变砖。
使用资源组，可以限制管道并发，以强制作业按顺序执行，从而确保仅按计划使用资源。使用.gitlab-ci.yml中的resource_group关键词，可以限制每个作业指定属于资源组一部分的环境。当作业请求运行程序并且资源已在运行现有作业时，它将一直排队，直到现有作业完成。例如，如果有多个用于测试的IoT设备，并且希望测试作业在组中的任何一台设备上运行，甚至可以为每个作业定义多个资源组。另一个很好的用例是使用Terraform将基础结构作为代码进行管理时，确保一次只对给定环境进行一次更改。
代码审查分析（STARTER及以上）
代码审查是任何软件开发过程的推荐部分，它使对等方和自动化过程能够检查对存储库的建议更改。
由于错过了交接，关键人员正在休假或待审核的项目积压，因此迁入的更新可能停滞在那里。周期时间取决于及时的代码审阅，以保持团队的运转。
为了帮助GitLab实例始终处于开发过程的关键部分，新版本中引入了代码审查分析以突出显示正在审核的合并请求的状态。
合并请求收到成员的