Безперервна інтеграція та доставка на GitHub Actions

Безперервна інтеграція та доставка на GitHub Actions

Викатка мікросервісу без CI/CD — це чотири години рутини: збірка локально, scp на сервер, systemctl restart, молитви. GitHub Actions — де-факто стандарт для проєктів на GitHub, але «працює» і «працює правильно в продакшені» — різні речі. Ми займаємося DevOps-аутсорсингом понад 10 років і перевірили на сотні проєктів: більшість самописних пайплайнів на Actions мають типовий набір проблем. Секрети зберігаються не в GitHub Secrets, а в env-змінних прямо в YAML. Немає матриці оточень, actions/checkout без fetch-depth: 0 ламає семантичне версіонування, а деплой іде без перевірки health-check після нього.

Візьмемо реальний кейс: фінтех-стартап витрачав до 4 годин на ручний деплой мікросервісу. Після впровадження пайплайну на GitHub Actions з автоматичними тестами, збіркою та Helm-деплоєм час скоротився до ~30 хвилин. Додатково налаштували approval для production через Environments — жоден деплой не проходить без code review та підтвердження. Економія часу на деплої — 87%, зниження кількості помилок на 80%.

Чому варто автоматизувати деплой через GitHub Actions?

Ручний деплой — головне джерело помилок: забули секрет, не ту гілку запушили, не той образ задеплоїли. GitHub Actions дає єдиний інтерфейс для збірки, тестування та доставки. На відміну від Jenkins, не потрібно розгортати окремий сервер — раннери вже є. А порівняно з GitLab CI, Actions тісніше інтегрований з екосистемою GitHub: issues, pull requests, code review. За нашими вимірами, автоматизація скорочує час викатки фічі з 2 годин до 15 хвилин. GitHub Actions запускає пайплайн у 2 рази швидше Jenkins при типовому завданні.

Архітектура пайплайну для production-ready проєкту

Мінімальна робоча структура для сервісу з деплоєм в Kubernetes виглядає так: три workflow-файли з чіткими зонами відповідальності.

• ci.yml — запускається на кожен push та pull_request. Лінтинг, юніт-тести, збірка Docker-образу, сканування через Trivy. Жодних деплоїв.
• deploy-staging.yml — запускається при merge в main. Деплой в staging через Helm, smoke-тести, повідомлення в Slack.
• deploy-production.yml — запускається вручну через workflow_dispatch або за тегом v*.*.*. Деплой в production з approval через GitHub Environments.

---
# .github/workflows/deploy-production.yml
name: Deploy to Production
on:
  push:
    tags:
      - 'v*.*.*'
jobs:
  deploy:
    runs-on: ubuntu-22.04
    environment:
      name: production
      url: https://app.example.com
    steps:
      - uses: actions/checkout@v4
      - name: Configure kubectl
        uses: azure/k8s-set-context@v3
        with:
          method: kubeconfig
          kubeconfig: ${{ secrets.KUBECONFIG_PROD }}
      - name: Deploy via Helm
        run: |
          helm upgrade --install myapp ./charts/myapp \
            --namespace production \
            --set image.tag=${{ github.ref_name }} \
            --set replicaCount=3 \
            --wait --timeout=5m
      - name: Verify deployment
        run: |
          kubectl rollout status deployment/myapp -n production --timeout=3m

Ключовий момент: environment: production активує required reviewers — деплой не піде без апруву потрібної людини. Це вбудований механізм, який не потребує зовнішніх approval-систем.

Як захистити секрети при роботі з Actions?

GitHub Secrets — правильне місце для всього чутливого. Але є нюанс: Organization-level secrets доступні всім репозиторіям організації, що створює ризик. Для production credentials використовуємо Environment secrets, які доступні лише в конкретному environment і тільки при виконанні умов захисту.

Для інтеграції з HashiCorp Vault:

---
- name: Get secrets from Vault
  uses: hashicorp/vault-action@v2
  with:
    url: ${{ secrets.VAULT_ADDR }}
    token: ${{ secrets.VAULT_TOKEN }}
    secrets: |
      secret/data/myapp/prod DB_PASSWORD | DB_PASSWORD ; secret/data/myapp/prod API_KEY | EXTERNAL_API_KEY

Кешування та оптимізація часу збірки

Без кешування залежностей Node.js або Python пайплайн витрачає 3–5 хвилин лише на npm install. Стандартне рішення:

---
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

Для Docker-шарів використовуємо cache-from і cache-to через GitHub Container Registry або BuildKit inline cache. Це пришвидшує збірку в 3 рази на типовому проєкті.

Self-hosted runners для приватної інфраструктури

GitHub-hosted runners не мають доступу до приватних мереж. Якщо Kubernetes-кластер за VPN або в private subnet, потрібні self-hosted runners. Запускаємо їх як Deployment у тому ж кластері через actions-runner-controller — ARC автоматично масштабує кількість runner pods під навантаження.

Як налаштувати approval для production деплою?

GitHub Environments дозволяють налаштувати required reviewers — групу людей, без схвалення яких деплой в production не запуститься. Це вбудований механізм, який не потребує зовнішніх approvals. На рівні environment можна задати захист гілок та обмеження за часовими поясами.

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

Етапи роботи та терміни

1. Аудит — аналіз поточної інфраструктури, репозиторіїв та процесів. Видача звіту з рекомендаціями.
2. Проєктування — архітектура пайплайну, вибір інструментів (Helm, Kustomize, ArgoCD), узгодження з командою.
3. Реалізація — написання CI та CD workflows, налаштування Environments, інтеграція з Vault, кешування.
4. Тестування — прогін всіх пайплайнів на staging, перевірка fallback-сценаріїв, rollback.
5. Деплой — вкочування в production, моніторинг перших деплоїв, коригування за необхідності.

Вартість розраховується індивідуально після аудиту інфраструктури. Зв'яжіться з нами для консультації — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення.

Приклад успішного впровадження: фінтех-проєкт на 5 мікросервісів, 3 оточення, self-hosted runners. Час деплою скоротився з 4 годин до 25 хвилин, частота релізів зросла в 6 разів. Повна окупність за 3 місяці.

Наші гарантії: всі конфігурації покриті тестами, розгорнуті з використанням Infrastructure as Code (Terraform/Ansible), після здачі передається повна документація. Досвід команди — понад 10 років в DevOps, 50+ успішних впроваджень CI/CD на GitHub Actions. Замовте аудит ваших workflows — отримайте професійну оцінку.

GitHub Actions