Сообщить об ошибкеКороткий ответ
Единственно верной структуры нет — распространённый паттерн: разделение репозиториев приложений (где команды описывают свои манифесты/Helm-чарты) от отдельного «окружение»-репозитория или набора репозиториев, которые ссылаются на конкретные версии через механизм вроде ApplicationSet в ArgoCD, с RBAC на уровне GitOps-контроллера и Git-репозиториев, ограничивающим каждую команду её собственным namespace/проектом, при этом платформенная команда владеет общими политиками и процессом продвижения между окружениями.
Как это работает подробнее
в ArgoCD, например, можно организовать multi-tenancy через AppProjects, которые ограничивают, какие Git-источники, namespace и кластеры доступны конкретной команде, не давая ей случайно (или намеренно) задеплоить что-то в чужой namespace или в прод-кластер в обход процесса. Структура репозиториев обычно разделяет «что» (манифесты приложения, которыми владеет команда) от «где и когда» (какая версия задеплоена в каком окружении, что может управляться отдельным репозиторием с ограниченным доступом на запись, часто через автоматизированный промоушен-пайплайн, а не ручные правки).
Пример кода
Структура репозиториев (пример для обсуждения):
apps/team-payments/payments-service/ <- владеет team-payments
apps/team-search/search-service/ <- владеет team-search
environments/staging/ <- auto-sync, пишет CI после тестов
environments/production/ <- требует PR + approval от platform team
ArgoCD AppProject "team-payments":
sourceRepos: ["apps/team-payments/*"]
destinations: [{namespace: "payments-*", server: "*"}]Сравнение
- Компромисс. больше автономии командам ускоряет их независимую работу, но увеличивает риск несогласованности политик безопасности и усложняет платформенный аудит; больше централизации даёт консистентность и контроль, но создаёт узкое место и снижает скорость независимых команд. Конкретный баланс — предмет обсуждения, зависящий от зрелости команд и требований безопасности/комплаенса организации.
Что использовать на практике
- На практике. при таком масштабе критична балансировка автономии команд (чтобы 30 команд не ждали платформенную команду на каждое изменение) и централизованного контроля (чтобы избежать хаоса из 30 разных подходов к структуре манифестов и несогласованных политик безопасности). Нужно явно решить, как происходит продвижение версии из staging в prod — автоматически после прохождения gate, через pull request в environment-репозиторий, или смешанно в зависимости от критичности сервиса.
- Пример. Задача для обсуждения: кандидату — оценить эту структуру для случая, когда team-payments нужно срочно задеплоить hotfix в прод в обход обычного staging-цикла, и предложить, как это можно сделать, не нарушая общую модель прав доступа.
Подводные камни
- Частые ошибки. дают всем командам полный доступ на запись во все environment-репозитории ради простоты, теряя контроль и аудит; централизуют весь процесс продвижения через одну платформенную команду, создавая узкое место для 30 независимых команд и теряя смысл автономной GitOps-модели.