Рекомендации по использованию правил ревью кода в Yandex Managed Service for GitLab

Managed Service for GitLab позволяет гибко настраивать обязательные правила ревью кода, прежде чем код может быть добавлен в целевую ветку проекта. Функциональность является альтернативой встроенному в GitLab Enterprise Edition инструменту Approval Rules и доступна вне зависимости от версии GitLab.

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

Подробнее читайте на странице Правила ревью кода в Yandex Managed Service for GitLab.

В разделе приведены примеры файлов APPROVALRULES и (опционально) CODEOWNERS для следующих типовых сценариев:

• Пример настройки правил для ревью от конкретных пользователей
• Пример настройки правил для двухэтапного ревью
• Пример настройки правил для ревью изменений в CI/CD

Помимо правил ревью кода в репозитории может быть настроена защита веток. Это два параллельных механизма, поэтому выполнения правил ревью кода может быть недостаточно для слияния мерж-реквеста с целевой веткой. Для упрощения считается, что приведенные в примерах ветки не являются основными в репозитории, например main, и защищены только от прямых внесений изменений (direct push).

Правила ревью кода начинают действовать после того, как изменения в файлах APPROVALRULES и (опционально) CODEOWNERS будут влиты в основную ветку репозитория. Переносить эти изменения в остальные ветки не нужно.

У пользователей, выполняющих ревью мерж-реквестов, должна быть минимальная роль Reporter в проекте GitLab, в большинстве случаев используется более привилегированная роль Developer.

Предварительные действияПредварительные действия

1. Если у вас еще нет инстанса GitLab, создайте и активируйте его.

2. Если у вас еще не сконфигурированы правила ревью кода в инстансе и проекте GitLab, настройте их.

   Примечание

   Минимальная конфигурация для функциональности правил ревью кода указана в каждом примере.

3. Создайте пользователей и группы согласно примерам ниже.

4. Создайте файлы APPROVALRULES и (опционально) CODEOWNERS в основной ветке репозитория согласно примерам ниже.

Пример настройки правил для ревью от конкретных пользователейПример настройки правил для ревью от конкретных пользователей

В примере представлен сценарий для обязательных проверок мерж-реквестов специалистами по информационной безопасности. Для слияния с веткой release требуется одобрение мерж-реквеста от одного из пользователей с username: security-expert1 или security-expert2.

Сценарий также подходит для других простых случаев, когда вы хотите защитить одну ветку и назначать конкретных согласующих.

Содержимое файла APPROVALRULES:

# Правила ревью
ApprovalRules:
  # Произвольное название правила
  - SecurityReview:
      # Список пользователей (username), которые могут одобрить мерж-реквест
      approvers:
        - "security-expert1"
        - "security-expert2"
      # Требуемое количество одобрений
      count: 1
# Группы веток, к которым применяются правила
BranchGroups:
  # Произвольное название группы веток
  - Release:
      # Список веток, к которым применяются правила
      branches:
        - release
      # Применяемые правила
      rules:
        - SecurityReview

В результате при создании мерж-реквеста в ветку release в поле Reviewer автоматически назначается один из указанных пользователей, а сам мерж-реквест блокируется до того, как будет одобрен.

ApprovalRules:
  - SecurityReview:
      groups:
        - "soc"
        - "secops"
      count: 1
...

Пример настройки правил для двухэтапного ревьюПример настройки правил для двухэтапного ревью

В примере представлен сценарий для обязательных проверок мерж-реквестов в два этапа:

1. Для слияния с веткой stage требуется одно одобрение от разработчика из группы devs — код проверяется на корректность, стиль, тесты и архитектуру.
2. Для слияния с веткой release требуются два одобрения: от разработчика из группы devs и от технического лида из группы tech-leads, который оценивает соответствие бизнес-целям и стандартам команды.

Соответственно подразумевается, что сначала изменения попадают из основной ветки, в которой ведется разработка, например dev, на стейджинг (ветка stage) и тестируются там, а уже после этого — в релиз (ветка release).

Вы также можете адаптировать сценарий для случаев, когда для слияния мерж-реквестов в разные ветки требуются разные правила ревью.

Содержимое файла APPROVALRULES:

# Правила ревью
ApprovalRules:
  # Произвольное название правила
  - TechnicalReview:
      # Список групп, участники которых могут одобрить мерж-реквест
      groups:
        - devs
      # Требуемое количество одобрений
      count: 1
  - LeadApproval:
      groups:
        - tech-leads
      count: 1
# Группы веток, к которым применяются правила
BranchGroups:
  # Произвольное название группы веток
  - Stage:
      # Список веток, к которым применяются правила
      branches:
        - stage
      # Применяемые правила
      rules:
        - TechnicalReview
  - Release:
      branches:
        - release
      rules:
        - TechnicalReview
        - LeadApproval

В результате при создании мерж-реквеста в ветку stage в поле Reviewer автоматически назначается один из участников группы devs, а сам мерж-реквест блокируется до того, как будет одобрен. После мержа изменения тестируются на стейджинге.

Далее разработчик создает мерж-реквест из ветки stage в ветку release. В поле Reviewer автоматически назначаются один из участников группы devs и один из участников группы tech-leads, а сам мерж-реквест также блокируется до того, как получит оба одобрения.

ApprovalRules:
  - TechnicalReview:
      approvers:
        - "dev1"
        - "dev2"
      count: 1
...

Пример настройки правил для ревью изменений в CI/CDПример настройки правил для ревью изменений в CI/CD

В примере представлен сценарий для обязательных проверок мерж-реквестов DevOps-инженерами, только если была затронута конфигурация CI/CD. Если в мерж-реквесте были изменены файл .gitlab-ci.yml или файлы с расширением .yml в директории ci/, то для слияния с веткой release требуется одобрение от одного из участников группы devops-team.

Сценарий также подходит для других случаев, когда вы хотите разграничить область ревью в разных директориях или файлах репозитория для разных команд или пользователей.

Фильтрация по путям не поддерживается в APPROVALRULES, поэтому используйте совместно с правилами ревью механизм Code Ownership.

Содержимое файла CODEOWNERS:

# <Пути_к_файлам_или_паттерны_фильтрации> @<ответственная_группа>
.gitlab-ci.yml @devops-team
ci/*.yml @devops-team

Содержимое файла APPROVALRULES:

# Группы веток, к которым применяются правила
BranchGroups:
  # Произвольное название группы веток
  - Release:
      # Список веток, к которым применяются правила
      branches:
        - release
      # Применяемые правила
      rules:
        - CODE_OWNERS

В результате при создании мерж-реквеста в ветку release, затрагивающего файлы .gitlab-ci.yml или ci/*.yml, в поле Reviewer автоматически назначается один из участников группы devops-team, а сам мерж-реквест блокируется до того, как будет одобрен.

BranchGroups:
  - All:
      branches:
        - "*"
      rules:
        - CODE_OWNERS

См. такжеСм. также

• Правила ревью кода в Yandex Managed Service for GitLab
• Настройка правил ревью кода в Yandex Managed Service for GitLab
• Создание и активация инстанса Managed Service for GitLab

Документация GitLabДокументация GitLab

• Merge request approval rules
• Syntax of CODEOWNERS file
• Protected branches
• Default branch
• Roles and permissions
• Groups