Окружения, секреты и best practices

Production, staging, preview — как управлять окружениями в CI/CD. Хранение секретов, branch protection rules, и собранные best practices для надёжного пайплайна.

Почему это важно: Утечка секрета из CI — инцидент безопасности. Деплой непроверенного кода — инцидент доступности. Правильная настройка окружений и секретов предотвращает оба сценария.

Главная идея

Каждое окружение (development, staging, production) имеет свои секреты, правила деплоя и уровень доступа. CI/CD пайплайн проводит код через каждое окружение с возрастающим уровнем проверок.

Как это выглядит на практике

Разработчик создаёт PR → CI запускает тесты
Автоматически создаётся preview environment для этого PR
Ревьюер проверяет код и preview, нажимает Approve
PR мержится → CD деплоит на staging с staging-секретами
QA тестирует staging окружение
Manual approval → CD деплоит на production с production-секретами
Мониторинг подтверждает: ошибок нет, метрики в норме

Примеры кода

Окружения с manual approval

# .github/workflows/deploy.yml
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging  # секреты из окружения staging
    steps:
      - uses: actions/checkout@v4
      - run: kamal deploy -d staging
        env:
          SERVER_IP: ${{ secrets.STAGING_SERVER }}
          DATABASE_URL: ${{ secrets.STAGING_DB_URL }}

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://myapp.com
    # В Settings → Environments → production:
    # Required reviewers: team-lead, devops
    steps:
      - uses: actions/checkout@v4
      - run: kamal deploy -d production
        env:
          SERVER_IP: ${{ secrets.PROD_SERVER }}
          DATABASE_URL: ${{ secrets.PROD_DB_URL }}

Branch protection + CI чеклист

# GitHub Settings → Branches → main:
# ✓ Require pull request reviews (1 approval)
# ✓ Require status checks to pass:
#   - lint
#   - test
# ✓ Require branches to be up to date
# ✓ Do not allow bypassing settings

# Best practices чеклист для CI/CD:
# ✓ Все секреты — в GitHub Secrets, не в коде
# ✓ Docker-образы пиннят версию (ruby:3.3.0, не ruby:latest)
# ✓ Actions пиннят commit SHA, не тег (@v4 → @abc123)
# ✓ Минимальные права: GITHUB_TOKEN с permissions
# ✓ Кэширование зависимостей включено
# ✓ Таймаут на job (timeout-minutes: 15)
# ✓ Уведомления о падении в Slack/email

Что происходит под капотом

GitHub Environments — изолированные наборы секретов с правилами доступа и approval
GITHUB_TOKEN — автоматический токен с минимальными правами, не нужен PAT для большинства операций
Branch protection rules предотвращают прямой push в main без PR и проверок
Секреты маскируются в логах CI — GitHub автоматически заменяет их на ***
OIDC (OpenID Connect) позволяет получать temporary credentials для AWS/GCP без хранения долгоживущих секретов

Типичные ошибки и заблуждения

«.env файл в репозитории — это нормально» — нет, секреты должны быть в CI/CD secrets, .env — в .gitignore
«staging не нужен, деплоим сразу на prod» — staging ловит проблемы, которые не видны в CI (миграции, конфигурация)
«Actions из маркетплейса безопасны» — пинните SHA коммита, а не тег, теги можно переопределить

Ключевые выводы

Окружения (staging, production) изолируют секреты и добавляют approval rules
Секреты — только в GitHub Secrets, никогда в коде или .env в репозитории
Branch protection + required checks = никто не может мержить непроверенный код

Термины урока

{:term=>"Environment", :definition=>"Изолированный набор секретов и правил деплоя в GitHub (staging, production)"}

{:term=>"Branch protection", :definition=>"Правила GitHub, запрещающие push в ветку без PR, ревью и прохождения CI"}

{:term=>"OIDC", :definition=>"OpenID Connect — протокол для получения временных credentials от облачных провайдеров без хранения секретов"}

Связь с работой backend-разработчика

CI/CD — не только автоматизация, но и безопасность. Правильная изоляция окружений, хранение секретов и branch protection предотвращают как случайные ошибки, так и злонамеренные действия.

Мини-разбор реальной ситуации

В стартапе AWS-ключи хранились в .env, который случайно попал в публичный репозиторий. За 4 часа на аккаунте AWS намайнили криптовалюту на $12 000. После инцидента: все секреты перенесены в GitHub Secrets, добавлен OIDC для AWS (без долгоживущих ключей), настроен git-secrets для предотвращения коммита секретов.

Что запомнить

Секреты → GitHub Secrets, не в код. .env → .gitignore
Окружения: staging (автодеплой) → production (manual approval)
Branch protection: required checks + review + no bypass

Итог

Окружения, секреты и protection rules — три столпа безопасного CI/CD. Они превращают пайплайн из просто автоматизации в надёжную систему доставки с правильными guardrails.