PR-based рабочий поток
Тема дорожной карты · Terraform
Pull Request рабочий процесс для Terraform устанавливает структурированный процесс ревью, при котором каждое изменение инфраструктуры предлагается в виде PR, автоматически валидируется с помощью terraform plan и мёржится только после одобрения коллегами — воспроизводя дисциплину код-ревью, применяемую при разработке приложений. При открытии PR CI-система (GitHub Actions, GitLab CI или Atlantis) запускает terraform init с настроенным remote-бэкендом, выполняет terraform validate и tflint для синтаксических и lint-проверок, затем публикует полный diff плана как комментарий к PR, чтобы ревьюеры могли оценить зону поражения до подтверждения. Pull Request рабочий процесс для Terraform обеспечивает, что terraform apply никогда не запускается локально против production; вместо этого мёрж в основную ветку запускает автоматизированный apply-джоб, использующий OIDC-учётные данные, читающий среда-специфичные tfvars и записывающий результаты в remote-state на S3 или Terraform Cloud. Checkov или Sentinel — как обязательные проверки статуса — блокируют мёржи, вносящие небезопасные конфигурации ресурсов в провайдерах AWS, Azure, GCP или Kubernetes. Этот рабочий процесс создаёт неизменяемый журнал аудита каждого изменения инфраструктуры, связывая результаты terraform apply непосредственно с PR, автором и одобрившими ревьюерами.
Как это работает
PR-based рабочий поток обычно: PR открыт → CI гоняет terraform fmt -check, validate, tflint, tfsec, потом terraform plan против state целевой среды и постит plan комментом в PR. На merge в main → CI делает terraform apply автоматически (с гейтами одобрения для prod). Инструменты: Atlantis (open-source PR-автоматизация), Terraform Cloud / Enterprise (managed-предложение HashiCorp), env0, Spacelift, GitHub Actions / GitLab CI с кастомными workflow.
Когда применять
Автоматизируйте весь flow до деплоя в production. PR-comment с plan — killer-фича: ревьюеры видят, что именно меняется. Требуйте approval до apply для production (ручной гейт). Запускайте plan по расписанию (drift-detection) — выявляет ручные изменения. Для RF / суверенности — self-host Atlantis на Yandex Cloud + GitLab-раннер; избегайте Terraform Cloud (US-hosted).
Типичные ошибки
Ловушки PR-based рабочий поток: auto-apply в prod без approval-гейта (один плохой PR = плохой prod); долгие plan, превышающие время CI-раннера (делите на меньшие root-модули); credentials в CI-логах (маскируйте, никогда не echo); не обработаны конкурентные PR за один lock (Atlantis ставит в очередь; Terraform Cloud сериализует).