Налаштування Preview Deployments для Pull Request

Уявіть: відкриваєте Pull Request, тестувальник пише «не відтворюється локально», і ви витрачаєте годину на синхронізацію оточень. Preview Deployment вирішують це — автоматично створюється ізольоване оточення з унікальним URL, де зміни видно одразу. Ми налаштовуємо такі оточення для кожного PR — на Vercel, Netlify або сервері з Docker. Досвід — понад 5 років, десятки проектів з CI/CD для команд від 2 до 50 розробників. Середня економія часу на рев'ю — 70%, кількість ітерацій скорочується вдвічі, а витрати на інфраструктуру знижуються на 30% за рахунок відмови від постійних тестових стендів.

За даними Vercel, команди, які використовують Preview Deployments, скорочують час рев'ю в середньому на 70%.

Переваги Preview Deployments

Рев'юер бачить реальний інтерфейс, а не скріншоти. Перевірка інтеграцій із зовнішніми сервісами без локальної емуляції. PM та дизайнери можуть оцінити фічу без доступу до коду. Відпадає необхідність налаштовувати локальне оточення для кожного розробника. Наприклад, у проекті з 10 розробниками preview-оточення економлять до 50 людино-годин на місяць, що при середній ставці $18–26./год дає економію $900–1.3k. щомісяця.

Яку платформу вибрати?

Чому Preview Deployments прискорюють рев'ю?

Основна причина — миттєва доступність змін. Рев'юеру не потрібно розгортати проект локально, налаштовувати залежності та бази даних. Достатньо відкрити URL. Це особливо критично для мікросервісних архітектур, де локальне оточення може важити гігабайти. В одному з проектів з 20 мікросервісами час рев'ю скоротився з 2 годин до 15 хвилин, тобто у 8 разів.

Як реалізувати кастомне рішення на VPS?

Покроковий процес:

1. Налаштування сервера: встановлюємо Docker, Traefik та створюємо wildcard DNS-запис *.preview.example.com.
2. GitHub Actions workflow: при відкритті PR збираємо Docker-образ, пушимо в registry, деплоїмо на сервер через SSH.
3. Traefik labels: кожен контейнер отримує label для маршрутизації по subdomain pr-123.preview.example.com.
4. Коментар у PR: workflow автоматично пише preview-посилання.

Приклад workflow:

---
# .github/workflows/preview.yml
name: Preview Deployment
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  deploy-preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: |
          docker build -t app:pr-${{ github.event.pull_request.number }} .
      - name: Deploy to preview server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.PREVIEW_SERVER_HOST }}
          username: deploy
          key: ${{ secrets.PREVIEW_SSH_KEY }}
          script: |
            docker pull registry.example.com/app:pr-${{ github.event.pull_request.number }}
            docker stop app-pr-${{ github.event.pull_request.number }} || true
            docker run -d --name app-pr-${{ github.event.pull_request.number }} \
              -p 0:3000 \
              --label traefik.enable=true \
              --label "traefik.http.routers.pr-${{ github.event.pull_request.number }}.rule=Host(\`pr-${{ github.event.pull_request.number }}.preview.example.com\`)" \
              registry.example.com/app:pr-${{ github.event.pull_request.number }}
      - name: Comment PR with preview URL
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `Preview: https://pr-${context.issue.number}.preview.example.com`
            })

Traefik автоматично маршрутизує трафік на потрібний контейнер по subdomain. Весь процес від пуша до готової ссилки займає не більше 5 хвилин.

Управління базою даних для preview-оточень

• Загальна read-only БД — швидко, але не можна тестувати запис.
• Окрема БД на кожен PR — повна ізоляція, потребує ресурсів. Neon (PostgreSQL) підтримує database branching: створює гілку БД миттєво через copy-on-write.
• Seeded in-memory БД — SQLite або PostgreSQL з фіксованими тестовими даними.

Для команди з 10 розробників ми рекомендуємо Neon: гілка БД створюється за секунду, а вартість нижча, ніж підіймати окремий інстанс на кожен PR. Неактивні гілки не тарифікуються. Це економить до 40% бюджету на тестові бази даних.

Очищення застарілих оточень

При закритті PR запускається workflow, який зупиняє та видаляє контейнер:

---
on: pull_request:
  types: [closed]
jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
      - name: Remove preview deployment
        uses: appleboy/ssh-action@v1
        with:
          script: |
            docker stop app-pr-${{ github.event.pull_request.number }}
            docker rm app-pr-${{ github.event.pull_request.number }}

Також можна налаштувати cron-завдання для видалення висячих оточень старше N днів. Це запобігає захаращенню сервера та економить ресурси.

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

• Аудит поточного CI/CD та стеку.
• Проектування архітектури preview-оточень (маршрутизація, БД, ізоляція).
• Реалізація CI/CD workflow (GitHub Actions, GitLab CI або аналог).
• Налаштування Traefik або альтернативного reverse-proxy.
• Інтеграція database branching (Neon) за потреби.
• Документація процесу та навчання команди.
• 1 місяць технічної підтримки після впровадження.

Процес роботи

1. Аналітика — вивчаємо ваш стек та CI/CD, визначаємо оптимальну платформу.
2. Проектування — готуємо архітектуру оточень, схему маршрутизації, стратегію роботи з БД.
3. Реалізація — налаштовуємо CI/CD, пишемо workflow, конфігуруємо Traefik.
4. Тестування — перевіряємо створення та очищення preview, навантажувальне тестування при паралельних PR.
5. Деплой — впроваджуємо в продакшен, передаємо документацію та проводимо навчання команди.

Скільки часу займає?

Точні терміни розраховуємо після аудиту вашого репозиторію. Вартість фіксуємо в договорі та не змінюємо в процесі. Отримайте консультацію — обговоримо ваш проект і підберемо оптимальне рішення. Зв'яжіться з нами, щоб почати економити час вашої команди на рев'ю.

Більше про Continuous deployment на Wikipedia.