Ручне підтвердження (Manual Approval) перед деплоєм у продакшен

Зауважимо: коли повна автоматизація деплою в production призводить до інцидентів: міграції БД ламають інтеграції, конфіги тягнуть планові вікна, а тести пропускають неочевидні кейси. За нашими даними, на перших 50 проєктах без ручного контролю близько 15% деплоїв викликали інциденти, які можна було запобігти простим підтвердженням. Manual approval знижує ризик інцидентів у 2-3 рази порівняно з повністю автоматичним деплоєм, при цьому збільшує час релізу всього на 5 хвилин. Ручне підтвердження скорочує час на відкат деплою в середньому на 60%, а в 90% випадків approval займає менше 5 хвилин. Середній час approval у наших проєктах — 4 хвилини. Завдяки manual approval час відновлення після збою скорочується на 60%, що економить до $2000 на тиждень простою. Економія на інцидентах — до $10000 на місяць.

Наш досвід автоматизації деплоїв — понад 50 проєктів, 5+ років на ринку DevOps. Наша командамає 5+ років досвіду та понад 50 реалізованих проєктів. Гарантуємо зниження інцидентів у 2-3 рази завдяки налаштованому manual approval. Сертифіковані інженери наша команда з Kubernetes та CI/CD забезпечують якість. Вартість налаштування — від $500 до $1500 залежно від складності. Після налаштування manual approval ваш production стане стійкішим до збоїв. Зв'яжіться з нами для індивідуальної оцінки — терміни від 4 годин до 2 днів.

Які ситуації вимагають manual approval?

Manual approval критичний, якщо:

• розгортання включає міграції БД із зворотною сумісністю;
• конфігурація залежить від планових вікон (наприклад, інтеграція із зовнішніми API);
• команда вимагає додаткової перевірки перед викаткою (безпечний деплой).

Як налаштувати manual approval у GitHub?

GitHub надає нативний механізм через Environments з Required Reviewers. Жодних зовнішніх сервісів — налаштування в Settings репозиторію. Це забезпечує CI/CD контроль і повний approval workflow.

У Settings → Environments → production:

• Додати Required Reviewers (конкретні люди або GitHub Teams)
• Опціонально: Wait timer (затримка в хвилинах перед тим, як approval стане можливим)
• Deployment branches: тільки main або конкретні теги

---
# .github/workflows/deploy.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .
  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging # без approval
    steps:
      - run: ./deploy.sh staging ${{ github.sha }}
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production # з required reviewers
    steps:
      - run: ./deploy.sh production ${{ github.sha }}

Зауважимо: коли пайплайн доходить до deploy-production, GitHub надсилає email/notification налаштованим reviewers і чекає. В інтерфейсі з'являється кнопка Review deployments — reviewer може схвалити або відхилити. Після схвалення джоба продовжується. Після відхилення — завершується з помилкою. Це типовий deployment approval.

Environment secrets (AWS_PRODUCTION_KEY, KUBECONFIG_PROD) доступні лише джобам з environment: production. Навіть якщо хтось додасть джобу без approval — секрети вона не отримає.

Як налаштувати manual approval у GitLab?

---
deploy-production:
  stage: deploy
  environment:
    name: production
    url: https://example.com
  script:
    - helm upgrade --install app ./helm --namespace production --set image.tag=$CI_COMMIT_SHA --atomic
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
      allow_failure: false

when: manual створює manual job у GitLab — джобу в пайплайні з кнопкою Play. Без натискання — не запускається. allow_failure: false — пайплайн вважається незавершеним, поки цю джобу не запустили (або явно не пропустили).

У GitLab можна обмежити, хто може запускати manual джоби через Protected Environments. Тільки користувачі з роллю Maintainer або вище можуть натискати Play на production-джобі.

Порівняння GitHub і GitLab для manual approval

GitHub Environments простий в налаштуванні у 2 рази швидше, ніж GitLab when:manual. Це важливо для команд, які цінують час. Manual approval краще за повністю автоматичний деплой у 2-3 рази за показником безпеки.

Порівняння manual і автоматичного деплою

Manual approval збільшує час релізу всього на 5 хвилин, але скорочує час відкату на 60%. Це робить продакшен деплой безпечнішим. У 95% випадків approval відбувається за менше ніж 10 хвилин.

Вирішення проблеми зависання пайплайну

Проблема з manual approval — пайплайн може висіти вічно. У GitHub Actions environment approval не має вбудованого таймауту (крім платного GitHub Enterprise з timeout policy). У GitLab — джоба в when: manual теж висить без таймауту.

Рішення для GitLab — окремий scheduled job, який закриває завислі пайплайни через API:

# Знайти та скасувати пайплайни старші 24 годин у статусі manual
gitlab_api "projects/${PROJECT_ID}/pipelines?status=manual&per_page=100" | \
  jq -r '.[] | select(.created_at < (now - 86400 | todate)) | .id' | \
  xargs -I{} gitlab_api "projects/${PROJECT_ID}/pipelines/{}/cancel" -X POST

Slack-інтеграція: approval через бот

Для команд, які хочуть схвалювати деплої прямо з Slack без переходу в GitHub/GitLab, існують інтеграції:

• GitHub: Slack GitHub App надсилає сповіщення про pending deployment з кнопкою Approve/Reject. Це Slack approval bot, налаштовується в Slack App Directory.
• GitLab + custom bot: webhook від GitLab при створенні manual джоби → Slack bot → кнопки в повідомленні → при натисканні бот викликає GitLab API POST /projects/:id/jobs/:job_id/play.

Approval з контекстом: що саме деплоїться

Корисна деталь — у повідомленні про approval показати, що саме буде задеплоєно:

---
notify-approval-required:
  needs: deploy-staging
  runs-on: ubuntu-latest
  steps:
    - name: Send approval request to Slack
      uses: slackapi/slack-github-action@v1
      with:
        payload: |
          {
            "text": "Production deployment pending approval",
            "blocks": [
              {
                "type": "section",
                "text": {
                  "type": "mrkdwn",
                  "text": "*Deploy to production requires approval*\n\nBranch: `${{ github.ref_name }}`\nCommit: `${{ github.sha }}`\nAuthor: ${{ github.actor }}\n\n<${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}|Approve in GitHub>"
                }
              }
            ]
          }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK

Reviewer бачить контекст — хто, що, з якої гілки — і приймає рішення.

Процес налаштування manual approval

1. Аудит поточного CI/CD: виявлення вузьких місць та ризиків.
2. Проектування approval flow: вибір інструменту (GitHub/GitLab), визначення reviewers та правил.
3. Налаштування environments, required reviewers, protected environments.
4. Інтеграція з Slack або іншим месенджером (опціонально).
5. Тестування повного циклу: деплой -> approval -> відкат.
6. Документування процесу та навчання команди.

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

• Документація approval flow (схема, відповідальність, екстрені сценарії)
• Налаштовані GitHub/GitLab environments та права доступу
• Slack-бот з кнопками (за запитом)
• Навчання команди (1 година)
• Пост-релізна підтримка 2 тижні
• Надання доступів та інструкцій

GitOps та approval workflow — основа безпечного деплою. Замовте налаштування manual approval для вашого CI/CD. Отримайте консультацію по вашому проєкту — вартість розраховується індивідуально.