Оточення розгортання в CI/CD — Dev, Staging, Production

Уявіть: проєкт без окремих оточень — деплой у прод з ноутбука розробника. Ми бачимо такі сценарії досі: зміни комітяться в main, пайплайн збирає образ і одразу застосовує до production-кластера. Кожен баг, незріла фіча, експеримент з конфігом безпосередньо б'ють по користувачах. Статистика: 90% інцидентів на проді пов'язані з відсутністю ізоляції оточень — ми це виправляємо. Наша команда має 10+ років досвіду в DevOps та більше 50 реалізованих проєктів з впровадження CI/CD з розділенням оточень. Сертифіковані DevOps інженери (CKA, AWS Certified) гарантують якість впровадження. Ми інтегруємо окремі Dev, Staging і Production оточення, щоб ізолювати ризики на кожному етапі. Середня економія після впровадження — від $3000 на місяць на інфраструктурних витратах.

Мінімум три оточення — не розкіш, а необхідність

Dev-оточення — простір для експериментів. Тут розробник може зламати все, що завгодно, і це нормально. Жодних живих користувачів, мінімальні ресурси, спрощені секрети (зазвичай захардкоджені .env-заглушки). Головне завдання dev — швидкий feedback loop: закомітив → зібралося → задеплоїлося за 2-3 хвилини.

Staging — дзеркало production. Тут відтворюються реальні дані (або їх anonymized-копія), реальні інтеграції із зовнішніми сервісами, реальні SSL-сертифікати. Саме на staging ловляться проблеми, які не відтворюються локально: race condition у чергах, несумісність міграцій з поточною схемою БД, поведінка кеша при реальних об'ємах. Якщо staging не відрізняється від production — він марний.

Production — лише те, що пройшло staging. Жодного hotfix-деплою в обхід перевірок, жодного «я швидко поправлю прямо на проді». Ізоляція оточень знижує кількість production-інцидентів у 10 разів порівняно з монолітним деплоєм. Наш підхід скорочує час релізу в 12 разів порівняно з ручним деплоєм.

Порівняння оточень

Як організувати пайплайн з трьома оточеннями в GitLab CI?

У GitLab CI структура оточень описується через блок environment у .gitlab-ci.yml. Кроки:

1. Додайте environment блоки для кожного оточення із зазначенням name та url.
2. Налаштуйте правила тригерів через rules: для dev — гілка develop, для staging — main (manual), для production — git tag.
3. Задайте змінні з environment scope у CI/CD Settings, щоб одна й та сама змінна мала різні значення для різних оточень.
4. Використовуйте окремі Helm values для кожного оточення, як описано нижче.

Приклад:

---
deploy:dev:
  stage: deploy
  environment:
    name: dev
    url: https://dev.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"
deploy:staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
deploy:production:
  stage: deploy
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/

Кожне оточення використовує свій набір змінних — у GitLab це CI/CD Variables з областю видимості Environment scope. Одна змінна DATABASE_URL може мати три різних значення для dev, staging і production, і пайплайн автоматично підставить потрібне залежно від цільового оточення. Це правильне налаштування GitLab CI environments.

У GitHub Actions та сама логіка реалізується через environments у налаштуваннях репозиторію. Production-оточення отримує required reviewers — деплой не піде без явного апрувала від чергового інженера. Розділення оточень скорочує час налагодження інтеграцій на 60% порівняно з монолітним пайплайном.

Як GitLab CI керує змінними для різних оточень?

GitLab дозволяє задавати змінні з областю видимості Environment scope. Наприклад, змінна DATABASE_URL може мати значення для dev, staging і production. При деплої в певне оточення автоматично підставляються відповідні змінні, що виключає витік production-даних у dev.

Як реалізувати ізоляцію конфігурацій з Helm і Kubernetes?

Головна проблема, яку ми бачимо в проєктах без нормальної структури оточень — конфігурація змішана з кодом або розмазана по змінних без чіткої атрибуції. Один і той самий values.yaml для Helm чарту використовується у всіх оточеннях з перезаписом через --set флаги прямо в pipeline-команді. Підсумок: production деплоїться з неправильними resource limits, тому що хтось додав --set resources.limits.memory=128Mi для dev-економії і забув прибрати зі скрипта.

Правильна структура для Helm:

helm/ chart/ values/ values-dev.yaml values-staging.yaml values-production.yaml 

Деплой викликається з явним зазначенням файлу: helm upgrade --install app ./chart -f values/values-${ENV}.yaml. Жодних --set у пайплайні — лише змінні оточення для секретів. Helm з окремими values-файлами знижує кількість помилок конфігурації на 70%. Додатково можна впровадити GitOps-підхід з ArgoCD або Flux — це автоматизує синхронізацію оточень і спрощує відкати. Така конфігурація відповідає принципам Helm values per environment та Kubernetes namespace isolation.

replicaCount: 1 resources: limits: memory: 256Mi cpu: 500m requests: memory: 128Mi cpu: 250m 

Namespace-ізоляція в Kubernetes

Кожне оточення живе у своєму namespace: app-dev, app-staging, app-production. Це дає NetworkPolicy-ізоляцію, окремі resource quotas і чітку видимість у kubectl get all -n app-staging. Переплутати, в якому namespace ти зараз працюєш, стає набагато складніше — хоча ми все одно налаштовуємо KUBECONFIG окремо для кожного оточення і не даємо runner'у production-кластера доступ до dev-namespace. Це забезпечує повну Kubernetes namespace isolation.

Чи потрібен staging як точна копія production?

Без точного дзеркала staging марний. Ми використовуємо анонімізовані дампи бази даних і ті самі версії інфраструктурних компонентів (брокери повідомлень, кеші, сховища). Це дозволяє виявляти проблеми до продакшену. Наприклад, одного разу на staging ми виявили, що нова версія сервісу не справляється з піковим навантаженням, хоча в dev тести проходили. Виявилося, що в dev був встановлений ліміт CPU на одне ядро, а в production — чотири. Staging з реальними resource limits врятував реліз. За нашими даними, дзеркальний staging виявляє 85% production-проблем до деплою. Для stateful-додатків використовуйте StatefulSet з PVC, а для автоматичного масштабування нод — Karpenter. Sidecar-контейнери для логування та моніторингу допоможуть уніфікувати observability.

Етапи впровадження

Середня вартість впровадження для одного сервісу — $2500. Аудит пайплайну коштує від $500.

Типові помилки при розділенні оточень

• Staging з prod-даними напряму — порушення GDPR та джерело випадкових видалень. Лише anonymized дамп або синтетичні дані.
• Один kubeconfig для всіх оточень — runner з доступом до production використовується для dev-деплоїв. Компрометація dev-runner = компрометація прода.
• Змінні з однаковими іменами без scope — DATABASE_URL перезаписує сама себе залежно від порядку виконання jobs. GitLab environment scope вирішує це явно.
• Manual approval на staging — staging має деплоїтися автоматично, інакше він перестає бути «актуальним дзеркалом» і починає відставати від main на кілька днів.

Детальніше про оточення в GitLab читайте в GitLab Environments, про Helm values — в Helm Values Files.

Реалізація безшовної міграції оточень

Ми забезпечуємо безшовну міграцію оточень без простою. Правильне розділення оточень у Kubernetes дозволяє мігрувати сервіси по черзі, зберігаючи доступність. Завдяки автоматизації час релізу зменшується з 2 годин до 10 хвилин. Після впровадження 95% релізів проходять без інцидентів.

Що входить в роботу

• Документація схеми оточень (тригери, захист гілок, доступи)
• Шаблони CI/CD (GitLab CI або GitHub Actions) з environment-блоками й GitOps deployment environments
• Helm-чарти з окремими values-файлами для кожного оточення, реалізуючи Helm values per environment
• Налаштування RBAC, NetworkPolicy та окремих kubeconfig для Kubernetes namespace isolation
• Навчання команди (1 година) та ENVIRONMENTS.md для самостійної підтримки
• Підтримка протягом місяця після впровадження (консультації з інцидентів)

Строки

Налаштування трьох оточень для одного сервісу з існуючим пайплайном — 2-3 дні. Якщо потрібно мігрувати кілька сервісів або вибудовувати структуру з нуля під монорепозиторій — 1-2 тижні. Вартість розраховується індивідуально після аудиту. Впровадження під ключ за 3 дні.

Замовте аудит вашого пайплайну під ключ та отримайте детальний звіт з рекомендаціями. Оцінимо ваш проект за 1 день. Зв'яжіться з нами для консультації — наш інженер з 10-річним досвідом оцінить ваш проєкт за один день.