Gitlab Permissions Guide
В данном гайде описываются рекомендации как настроить роли и права разработчиков и других инженеров в случае когда в качестве платформы для git используется saas или selfhosted версия Gitlab
Как и все гайды Ensi данный гайд может быть удален или доработан под требования конкретного внедрения
Обзор ролей в Gitlab
Остановимся на главных ролях:
- Reporter - доступ только на чтение;
- Developer - стандартная роль для разработчиков. Обычно есть право на создание новых репозиториев. Push и Merge в защищенные ветки часто недоступен для этой роли.
- Maintainer - кроме всех прав Developer еще всегда может создавать репозитории, иногда имеет право создавать подгруппы, может удалять и переименовывать репозитории. Может иметь больше прав на push/merge в защищенные ветки. Может настраивать CI/CD. Это группа для разработчиков наделенных опытом и ответственностью, а также devops инженеров
- Owner - полный доступ к группе, включая добавление новых участников и смена ролей.
Конкретные права ролей зависят от настроек групп и/или даже репозиториев в этих группах.
Полное описание ролей и прав можно найти на специальной странице документации Gitlab
Проецирование команд в Gitlab
Вне зависимости от того планируется ли развитие Ensi-сервисов силами одной общей команды разработки или команд будет несколько рекомендуется создать одну общую группу-директорию под все сервисы платформы конкретного внедрения. Пример такой группы
- если команда одна, то удобнее будет добавлять людей непосредственно в эту корневую группу;
- если команд несколько - создаем подгруппу под каждую команду и добавляем людей в них. Подгруппу называем с префиксом Team, чтобы не путать с подгруппами для доменов. После этого для каждой команды определяем список доменов (тоже подгрупп), которыми она владеет, заходим в эти подгруппы и шарим их с нужной командой;
- если у вас сначала была одна команда, а потом она выросла и разбилась на несколько - создаем подгруппы под них, а из корневой всех убираем;
Разработчики соседних команд должны иметь доступ хотя бы на чтение к чужим доменам. Для этого шарим домен с соседними командами, но выставляем ограничение на максимальную роль.
- если вы практикуете innersource между командами, то это Developer;
- если нет - скорее всего вам подойдет и Reporter дающий только доступ на чтение;
Определение роли пользователя в команде
После того как появились команда/ы и домены/сервисы которыми эта команда владеет встает вопрос с какой ролью добавлять конкретного пользователя в команду.
Гайдлайны здесь следующие:
- если человеку достаточно лишь доступа на чтение - добавляем с ролью Reporter;
- присоединившимся к команде разработчикам - по-умолчанию Developer;
- самым опытным и погруженным в проект разработчикам - Maintainer; Это люди ответственные за ревью младших разработчиков, сборку релизов и т д. В группе всегда должен быть хотя бы один разработчик с ролью Maintainer или выше;
- У всех DevOps инженеров должна быть роль Maintainer;
- в группе необязательно должен быть Owner, необходимые действия может совершать Owner вышестоящих групп Gitlab. Однако, если команда большая, отвечает за большое число сервисов, много людей приходит и уходит, то может быть удобно переложить эти функции на одного из Maintainer-ов, дав ему Owner права на конкретную группу.
Настройки групп связанные с ролями и правами
Allowed to create projects (repositories) : Developers and Maintainers
Allowed to create subgroups: Maintainers
Настройки проектов-репозиториев связанные с ролями и правами
Вне зависимости от выбранного flow работы с git рекомендуется делать production ветку защищенной со следующими настройками:
Repository → Protected Branched → Allowed to Merge : Developers and Maintainers
Repository → Protected Branched → Allowed to Push : No one. Может быть смягчено до Maintainers на период разработки MVP