Что входит в процесс проверки кода (code review) в DevOps-практике?

В DevOps проверка кода — это не только ревью коллегой, а автоматизированный конвейер гарантий качества, встроенный в CI/CD. На моих проектах процесс выглядел так:

1. Предварительные автоматические проверки (Pre-commit / PR Checks): Эти проверки запускаются автоматически при создании Pull/Merge Request и должны пройти до приглашения ревьюверов.

• Статический анализ кода (SAST):
  • Linters: golangci-lint для Go, hadolint для Dockerfile, terraform validate и tflint для IaC. Они ловят стилевые ошибки и простые баги.
  • Сканеры уязвимостей: trivy или grype для сканирования образов Docker на уязвимости в базовых слоях и зависимостях.
  • Проверка конфигов: kubeval или kubeconform для валидации Kubernetes манифестов, checkov для Terraform на предмет небезопасных настроек.
• Тестирование:
  • Юнит-тесты: Для инфраструктурного кода (Terraform, Ansible) это могут быть тесты с terratest.
  • Интеграционные тесты: Например, развертывание инфраструктуры в изолированном окружении (с помощью Terraform в отдельном аккаунте AWS) и проверка, что все ресурсы создались.

2. Ревью кода коллегой (Peer Review): Здесь мы смотрим не только на синтаксис, но и на:

• Безопасность: Не залиты ли секреты (пароли, ключи) в код. Используются ли безопасные практики (не root в Docker, минимальные IAM-роли).
• Соответствие инфраструктурным стандартам: Правильное тегирование ресурсов, использование утвержденных модулей Terraform, корректные лимиты ресурсов в Kubernetes.
• Наблюдаемость: Добавлены ли необходимые метрики, логи и трейсы для нового функционала или измененной инфраструктуры.
• Документация: Обновлены ли README, схемы архитектуры, runbooks для операторов.

3. Постревью-проверки и артефакты: После мержа код проходит финальные этапы CI/CD:

• Сборка артефактов: Сборка Docker-образов с тегами, содержащими хэш коммита.
• Деплой в staging: Автоматический деплой изменений в тестовое окружение, где запускаются e2e-тесты.
• Сканирование артефактов: Повторное сканирование собранного образа на уязвимости.

Пример секции из .gitlab-ci.yml для инфраструктурного кода:

stages:
  - validate
  - test
  - deploy-staging

validate-terraform:
  stage: validate
  image: hashicorp/terraform:latest
  script:
    - terraform init
    - terraform validate
    - terraform fmt -check
    - tflint
    - checkov --directory .

integration-test:
  stage: test
  script:
    - go test -v ./test/... -timeout 30m  # Запуск terratest

Цель всего процесса — гарантировать, что каждое изменение безопасно, надежно и может быть автоматически развернуто.