Налаштування 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.