github回滚单个文件_GitLab 13.7发布，审阅者，问题克隆，部署失败回滚等

12月22日距离平安夜还有两天，距离新年还有一周多点，又到Gitlab发版的日子了。这次发布的版本是Gitlab 13.7，虽然和日常的功能略少点，但是也包括了45项功能和改进， 详细的功能请和虫虫一道学习尝试。

概述

增强项目管理以实现跨协作

合并请求(MR，Github中是PR)是Git生态协作交互中最重要的部分。它促进了Fork协作，支持将其与相关问题直接关联，提供一个中心位置，通过commit进行交流，代码更改建议，执行代码审查等。在新版本中，Gitlab添加了合并请求审阅者，功能通过使审阅更加容易和更有条理来改善代码审阅过程，新功能可以快速找出合并请求中涉及的人员，或请求进行正式审查向他们发送通知。

工作流中的上下文切换和手动任务阻碍了在组和项目之间进行有效协作的能力。花费更少的时间来开发有价值的功能，而花费更多的时间来管理项目，这就是为什么能够的对简化敏捷规划和项目管理如此重要的原因。

在项目上进行协作并快速迭代以开发应用程序，这样需要能够快速确定问题的重要性顺序，确定所有阻止者，并使用该信息确定下一步的工作重点。现在，新版中可以按阻止者对问题进行排序，以快速找出哪些问题阻止了其他问题的进展，以及轻松按问题列表中阻止者的数量进行排序。

改进的发布自动化和部署灵活性

用户需要灵活性来控制如何定期组织，自动化和部署应用程序。可靠且频繁地部署应用程序可以更快地将价值带到客户手中。

为了改善GitLab自动发布的方式，新添加了在发生故障时自动回滚的功能。此功能会自动将失败的部署恢复为上一次成功的部署，并发送自动通知以提醒用户当前状态。无需手动进行任何更改，并且可以确信在尝试解决问题时，潜在的问题不会导致停机或加剧。

发生故障时自动回滚非常适合进行一项改进，即能够在"环境"页面中查看部署状态。现在，可以轻松找到部署状态并确定需要执行的操作，例如停止或回滚部署。

更可靠，高效的软件包和依赖项管理

用户的工作流程取决于多种编程语言，二进制文件，集成和工件，这些都是开发过程的重要输入或输出。为了可以更有效地管理软件包和依赖项，从而减少浪费的开发时间，并且出于效率考虑，新添加了快速查找和查看通用软件包的选项。还对GitLab的依赖项代理进行了改进，已经在GitLab 13.6的Core中提供。

现在，可以避免Docker速率限制，并使用Dependency Proxy来加快管道的速度，以确保在缓存DockerHub上托管的容器镜像时对可靠性的信心并提高效率。

社区中许多人都希望看到的另一个改进是，Dependency Proxy现在可以与私有项目一起使用，并解决了那些使私有项目的人无法利用此功能的限制。

最后但并非最不重要的一点是，支持预定义变量与依赖项代理一起使用，而不必依赖于自己定义的变量或gitlab.ci-yml文件中的硬编码值。这提供了一种更可扩展且更有效的方式来开始代理和缓存镜像。

GitLab 13.7主要功能

合并请求的审阅者

要求小伙伴们帮你代码应该开发的日常工作，但这通常很繁琐。要求进行审查之类的简单任务可能会导致混乱。例如，应该怎么开始？一封邮件？评论？聊天消息？没有正式的流程，评论可能会不一致并且难以跟踪。此前，一种选择通过合并请求中分配审阅者。即使具有这种形式，作者和审阅者都出现在参与者中，这使得其他团队成员很难知道谁在做什么。

GitLab 13.7引入了用于合并请求的审阅者，允许作者向某发出请求审阅。新的"审阅者"字段允许以与参与者相似的方式将用户指定为审阅者。审阅者收到通知，邀请他们审阅合并请求。这提供了一个请求审阅的正式流程，并阐明了合并请求中每个用户的角色。

未来的迭代将包括显示合并请求中最相关的审阅者，以及使审阅者成为中心的简化的合并请求批准流程。

发生故障时自动回滚(ULTIMATE)

如果部署中遇到严重问题，则通常需要花费很长时间来进行手动操作以解决该问题，并且会导致影响用户的生产质量下降。现在，可以利用自动回滚机制，将部署还原为上一次成功的部署。此外，当GitLab在生产中发现问题时，它会自动以发出告警通知。这使高枕无忧，并有宝贵的开发时间来调试，研究和解决问题，而不会造成停机。

快速克隆问题

为了使生成类似问题的效率更高，问题现在支持/clone快速行动，该行动可以在同一项目中创建具有相同标题，描述和元数据的新问题。该/clone行动迅速取代了较为繁琐的过程，它涉及多个步骤来创建一个问题，复制源问题的ID或路径，并使用copy_meta快速行动。

默认情况下，问题被克隆到同一项目中，并不包括评论，但是也可以在克隆时更改默认行为。

Red Hat OpenShift GitLab Runner镜像

今天可用的是Red Hat OpenShift容器平台的GitLab Runner容器镜像。要在OpenShift上安装运行程序，可以使用新的GitLab Runner操作程序，该程序可从Red Hat的Operator Hub的beta通道中获得。该Operators是一个Web控制台，OpenShift群集管理员可以发现并选择要在其群集上安装的Operators。默认情况下，Operator Hub部署在OpenShift容器平台中。预计在2021年初将GitLab Runner Operators在稳定版发布，并向GA进行过渡扩展。

在"环境"页面上显示部署状态

以前，在查看"环境"页面时，无法知道正在进行部署。通过现在可以看到部署状态和警报，"环境"页面将指示可以根据部署状态(成功，失败或进行中)采取何种操作。例如，可能想停止当前正在进行的部署，或回滚完成的部署。

通过UI设置部署流量权重(PREMIUM及以上)

在GitLab 13.7中，可以直接从用户界面中的部署板更改canary权重。可以直接从gitlab-ci.ymlAPI和API中更改canary的权重，但是在UI中，可以查看部署并直接从Deploy Boards缩放Pod。这样可以更好地控制手动或定时增量部署，并可以更好地缓解风险。

API支持部署频率(ULTIMATE)

作为首次在GitLab中支持DORA4指标的迭代的一部分，此版本增加了对项目级别部署频率的API支持。这样，可以随着时间的推移监视部署的效率，轻松找到瓶颈，并在必要时快速采取纠正措施。

在一个项目中支持多个清单文件(PREMIUM及以上)

在以前的GitLab版本中，GitLab Kubernetes代理要求用户将所有Kubernetes资源收集到一个清单文件中。在新版本的GitLab中，GitLab Kubernetes代理可以从项目中的指定目录中递归地获取Kubernetes清单。平台工程师可以使用一个存储库从一个地方管理不同的集群，并且可以使用一个代理描述大型部署。