[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for GitLab](../index.md) > [Концепции](index.md) > Правила ревью кода > Обзор

# Правила ревью кода в Yandex Managed Service for GitLab

Managed Service for GitLab позволяет гибко настраивать обязательные _правила ревью кода_, прежде чем код может быть добавлен в целевую [ветку проекта](../../glossary/vcs.md#branch). Функциональность является альтернативой встроенному в GitLab Enterprise Edition инструменту [Approval Rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) и доступна вне зависимости от [версии](https://about.gitlab.com/pricing) GitLab.

Конфигурация правил ревью в Managed Service for GitLab настраиваются только в виде кода (Configuration as Code) в файлах `APPROVALRULES` и (опционально) `CODEOWNERS`.

{% note warning %}

За использование правил ревью кода в Managed Service for GitLab взимается плата в зависимости от используемой [конфигурации](approval-rules.md#packages). Подробнее читайте на странице [Правила тарификации для Yandex Managed Service for GitLab](../pricing.md).

{% endnote %}

Если в инстансе GitLab включены правила ревью кода, Managed Service for GitLab анализирует подтверждения от ревьюеров на соответствие заданным правилам. Если подтверждений недостаточно, в мерж-реквесте создается техническая дискуссия, блокирующая его интеграцию в целевую ветку. При изменении мерж-реквеста в дискуссии создается или обновляется комментарий с текущим статусом соответствия правилам. Когда все необходимые подтверждения получены, дискуссия закрывается.

Если закрыть техническую дискуссию вручную, она будет создана заново. В случае интеграции мерж-реквеста в обход заданных правил пользователи с ролью `Maintainer` и выше получат уведомление на электронную почту о нарушении установленного процесса ревью кода.

Подробнее о работе с правилами ревью в разделе [Настройка правил ревью кода](../operations/approval-rules.md).

## Токен GitLab {#gitlab-token}

Настройка правил ревью кода осуществляется с помощью _[токена GitLab](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)_. Токен запрашивается для авторизации при взаимодействии с репозиторием — так происходит обращение к API GitLab.

Токен GitLab обладает сроком жизни, который задается во время [создания токена](../operations/approval-rules.md#gitlab-token). Срок жизни истекает в полночь UTC в указанный день. Максимальный срок жизни — год с момента создания токена.

Накануне истечения срока GitLab отправляет уведомление о том, что приближается окончание срока жизни токена. Уведомление приходит на электронную почту аккаунта, от лица которого был создан токен.

Выпустите новый токен и добавьте его в настройки инстанса GitLab до того, как истечет срок жизни прежнего токена. Иначе сервис Managed Service for GitLab будет работать некорректно.

## Доступные конфигурации {#packages}

Выбранная конфигурация влияет на [стоимость использования вычислительных ресурсов инстанса](../pricing.md#prices).

Вы можете выбрать нужную конфигурацию, исходя из задач команды:

* **Базовая** — включает возможность создания одного правила на каждый проект без дополнительных условий. Подходит для небольших команд (до 10 человек).
* **Стандартная** — позволяет настроить несколько правил на каждый проект и назначить [владельцев кода](../operations/approval-rules.md#code-ownership) (Code Owners) на определенные файлы или директории (не более 10 записей). Подходит для команд среднего размера (от 10 до 30 человек).
* **Продвинутая** — включает в себя возможности стандартной конфигурации без ограничения на количество записей Code Ownership и позволяет настраивать разные правила ревью для разных веток проекта. Подходит для больших команд (больше 30 человек).

Подробное сравнение возможностей конфигураций в таблице:

| Функциональность                  | Описание | Базовая<br>конфигурация | Стандартная<br>конфигурация | Продвинутая<br>конфигурация |
|:----------------------------------|:---------|:------------------------------------:|:---------------------------------------:|:------------------------------------:|
| Одно правило ревью на проект      | Возможность выбрать группу пользователей, один из которых должен провести ревью перед объединением веток. | ![yes](../../_assets/common/yes.svg) | ![yes](../../_assets/common/yes.svg)    | ![yes](../../_assets/common/yes.svg) |
| Защищенные ветки                  | Возможность выбрать ветки, для которых действуют правила ревью. | ![yes](../../_assets/common/yes.svg) | ![yes](../../_assets/common/yes.svg)    | ![yes](../../_assets/common/yes.svg) |
| Code Ownership                    | Возможность закрепить определенные файлы и директории (в т. ч. по маске) за определенными пользователями. Такие пользователи становятся владельцами кода (code owners) и могут принимать участие в ревью, если коммиты в мерж-реквесте затрагивают их файлы. | ![no](../../_assets/common/no.svg)   | ![yes](../../_assets/common/yes.svg) | ![yes](../../_assets/common/yes.svg) |
| Несколько правил ревью            | Возможность задавать больше одного правила ревью на проект. | ![no](../../_assets/common/no.svg)   | ![yes](../../_assets/common/yes.svg) | ![yes](../../_assets/common/yes.svg) |
| Правила для разных веток          | Возможность задавать разные правила ревью для разных веток, например `release` и `master`. | ![no](../../_assets/common/no.svg)   | ![no](../../_assets/common/no.svg)      | ![yes](../../_assets/common/yes.svg) |

## Примеры использования {#examples-mgl}

* [Рекомендации по использованию правил ревью кода в Yandex Managed Service for GitLab](approval-rules-scenarios.md)
* [Безопасное хранение паролей для GitLab CI в виде секретов Yandex Lockbox](../tutorials/gitlab-lockbox-integration.md)