Автоматизація деплою через GitHub Actions

Вступ

Сучасна розробка програмного забезпечення неможлива без автоматизації процесів доставки коду. Ручний деплой давно став вузьким місцем у життєвому циклі продукту: він збільшує ризик помилок, уповільнює релізи та ускладнює масштабування командної роботи. Саме тому підхід CI/CD (Continuous Integration / Continuous Deployment) став стандартом для більшості IT-команд.

Одним із найпопулярніших інструментів для реалізації CI/CD є GitHub Actions. Це вбудована платформа автоматизації, яка дозволяє запускати сценарії (workflows) прямо в репозиторії GitHub без необхідності піднімати окремий CI-сервер. GitHub Actions підтримує побудову, тестування, збірку та деплой застосунків у будь-яке середовище: від VPS до Kubernetes або хмарних платформ.

У цій статті розглядається архітектура GitHub Actions, принципи побудови pipeline, практичні приклади автоматизації деплою та типові підходи до організації CI/CD у реальних проєктах.

Що таке GitHub Actions і як він працює

GitHub Actions - це подієво-орієнтована система автоматизації. Вона базується на тригерній моделі: кожна дія (push, pull request, tag, schedule) запускає workflow, який складається з набору job’ів і step’ів.

Основні компоненти GitHub Actions

• Workflow - основний файл автоматизації у форматі YAML
• Job - логічний блок виконання (наприклад, build або deploy)
• Step - окрема команда або action всередині job
• Runner - середовище виконання (Ubuntu, Windows або self-hosted)
• Action - перевикористовуваний модуль (готовий скрипт або інтеграція)

Типова структура виглядає так:

Repository 
└── .github/
     └── workflows/
              └── deploy.yml

Основи CI/CD у контексті GitHub Actions

CI/CD - це набір практик, спрямованих на автоматизацію життєвого циклу застосунку.

CI (Continuous Integration)

Безперервна інтеграція включає:

• автоматичну перевірку коду
• запуск тестів
• збірку проєкту
• аналіз якості коду (lint, static analysis)

CD (Continuous Delivery / Deployment)

CD поділяється на два підходи:

• Continuous Delivery - готовий до деплою артефакт, але реліз вручну
• Continuous Deployment - автоматичний реліз після проходження всіх перевірок

GitHub Actions дозволяє реалізувати обидва сценарії залежно від вимог бізнесу.

Архітектура процесу деплою

Типовий pipeline виглядає наступним чином:

1. Push у гілку main або develop
2. Запуск workflow
3. Встановлення залежностей
4. Запуск тестів
5. Збірка проєкту
6. Формування артефакту (build)
7. Деплой на сервер або хмару
8. Перевірка стану системи

Приклад базового workflow для Node.js застосунку

Розглянемо простий приклад CI pipeline.

name: CI Pipeline

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      - name: Build project
        run: npm run build

Цей pipeline забезпечує базовий рівень якості: код не потрапить у main без проходження тестів.

Автоматичний деплой на сервер через SSH

Один із найпоширеніших сценаріїв - деплой на VPS через SSH.

Підготовка сервера

На сервері необхідно:

• встановити Node.js або інше середовище
• налаштувати SSH доступ
• створити користувача для деплою
• налаштувати директорію проєкту

GitHub Secrets

Для безпечного доступу використовуються secrets:

• SSH_HOST
• SSH_USER
• SSH_PRIVATE_KEY

Workflow для деплою

name: Deploy to Production

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

      - name: Deploy to server
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
            cd /var/www/app
            git pull origin main
            npm install
            npm run build
            pm2 restart app
          EOF

Docker-based деплой через GitHub Actions

Docker значно спрощує процес доставки застосунків, оскільки забезпечує ізольоване середовище виконання.

Приклад Dockerfile

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

RUN npm run build

CMD ["npm", "start"]

Workflow зі збіркою Docker образу

name: Docker CI/CD

on:
  push:
    branches: [ "main" ]

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Login to DockerHub
        run: echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin

      - name: Build Docker image
        run: docker build -t myapp:latest .

      - name: Tag image
        run: docker tag myapp:latest mydockerhubuser/myapp:latest

      - name: Push image
        run: docker push mydockerhubuser/myapp:latest

Деплой у Kubernetes через GitHub Actions

У складних системах використовується Kubernetes.

Приклад workflow

name: Kubernetes Deploy

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup kubectl
        uses: azure/setup-kubectl@v4

      - name: Configure kubeconfig
        run: echo "${{ secrets.KUBE_CONFIG }}" > ~/.kube/config

      - name: Deploy to cluster
        run: kubectl apply -f k8s/

Практичний кейс: деплой Laravel застосунку

Laravel часто використовується як приклад серверного PHP-фреймворку.

Pipeline для Laravel

name: Laravel CI/CD

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.2

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run tests
        run: php artisan test

      - name: Deploy via SSH
        run: |
          ssh user@server << 'EOF'
            cd /var/www/laravel
            git pull origin main
            composer install --no-dev
            php artisan migrate --force
            php artisan config:cache
          EOF

Кращі практики використання GitHub Actions

1. Розділення workflow

Рекомендується розділяти:

• CI (build + test)
• CD (deploy)
• security scanning

2. Використання environments

GitHub підтримує environments:

• staging
• production

Це дозволяє контролювати доступ і approval process.

3. Мінімізація часу виконання

• кешування dependencies (npm, composer)
• паралельні job’и
• використання lightweight runners

4. Безпека

• не зберігати секрети в коді
• використовувати GitHub Secrets
• обмежувати доступ SSH ключів
• використовувати least privilege принцип

Типові помилки при налаштуванні CI/CD

• відсутність тестів у pipeline
• надмірно складні workflow
• відсутність rollback механізму
• деплой напряму без staging середовища
• ігнорування логування та моніторингу

Моніторинг і відкат змін

CI/CD не завершується на етапі деплою. Важливо забезпечити:

• логування (ELK, Grafana)
• health checks
• автоматичний rollback при помилках

Приклад простого rollback сценарію:

if [ $? -ne 0 ]; then
    git reset --hard HEAD~1
    pm2 restart appfi
fi

Висновки

GitHub Actions є потужним інструментом для побудови сучасних CI/CD процесів. Він дозволяє автоматизувати весь життєвий цикл застосунку: від перевірки коду до деплою в production.

Правильно побудований pipeline забезпечує:

• стабільність релізів
• зменшення людських помилок
• швидкий цикл розробки
• масштабованість процесів доставки коду

Впровадження CI/CD через GitHub Actions є обов’язковим кроком для будь-якої сучасної IT-команди, яка прагне ефективності та контрольованості процесів розробки.