К содержанию
hegai.media
Workflows

Минимальный CI/CD для сервиса: GitHub → Docker → тесты → staging → Cloud Run

Практический пайплайн деплоя небольшого сервиса, собранный одиночным разработчиком: от push в GitHub до сборки, тестов и выкладки в Cloud Run через staging‑окружение.

Для кого

  • Соло‑разработчики, которые собирают небольшой сервис и хотят минимальный production‑контур
  • Фаундеры, делающие продукт в режиме вайбкодинга и выкатывающие его самостоятельно
  • Инженеры, которым нужен простой автоматизированный деплой без сложной DevOps‑инфраструктуры
  • Команды ранней стадии, где важно автоматизировать тестирование перед релизом
  1. 1
    Ручная проверка перед релизом

    Разработчик локально запускал сервис и вручную проверял функции интерфейса и сценарии работы.

  2. 2
    Ручная выкладка сервиса

    После проверок код выкладывался так, чтобы сервис начал работать для пользователей.

  3. ✓
    Повторение проверки после измененийhuman review

    Каждое изменение приходилось снова проверять вручную, проходя по функциям сервиса.

  1. 1
    Push кода в репозиторий

    Новая версия сервиса отправляется в репозиторий.

    GitHub
  2. 2
    Автоматический запуск пайплайна сборки

    После push автоматически триггерится процесс сборки проекта.

    Cloud Build
  3. 3
    Сборка контейнера

    Код собирается в Docker‑контейнер, чтобы обеспечить одинаковую среду выполнения локально и в облаке.

    Docker
  4. ✓
    Запуск тестовhuman review

    Контейнер проходит несколько уровней тестирования: unit‑тесты, интеграционные тесты и end‑to‑end сценарии через эмуляцию действий пользователя в браузере.

    Playwright
  5. 5
    Создание артефакта сборки

    После прохождения проверок формируется итоговый контейнер‑артефакт для развёртывания.

  6. 6
    Деплой в staging

    Контейнер выкатывается в staging‑окружение — полное зеркало продакшена со всеми настройками, секретами и инфраструктурой.

  7. ✓
    Проверка версии в staginghuman review

    В staging тестируется версия сервиса перед переносом в production.

  8. 8
    Выкатка в production

    После успешных проверок сервис разворачивается в production‑окружении.

    Cloud Run

Use cases

› Деплой небольшого сервиса одним разработчиком

Как было: Код проверяется вручную, разработчик кликает интерфейс и вручную убеждается, что всё работает.

Как с AI: Push в GitHub автоматически триггерит пайплайн сборки и запуск проверок; после прохождения тестов версия проходит через staging и затем может быть выкачена в Cloud Run.

KPI: Снижение ручных проверок и автоматический контроль ошибок перед релизом

› Проверка пользовательских сценариев перед релизом

Как было: Функции проверяются вручную в браузере.

Как с AI: End‑to‑end тесты через Playwright эмулируют действия пользователя: создание встречи, ввод данных и получение ссылки.

KPI: Автоматическое воспроизведение пользовательских сценариев

› Контроль поломок при добавлении новых функций

Как было: После изменений разработчик вручную проверяет, не сломались ли старые функции.

Как с AI: Регрессионные тесты автоматически проходят по существующим функциям и проверяют, не нарушилась ли их работа.

KPI: Раннее обнаружение регрессий

⛔ Что не сработало

  • Ручная проверка сервиса перед релизом оказалась слишком трудоёмкой — приходилось «сидеть тыкать руками» все сценарии.
  • Канареечный деплой не имеет смысла для совсем новых продуктов с небольшим числом пользователей.

★ Опыт сообщества

В эфире разобран конкретный рабочий пайплайн деплоя небольшого сервиса, который собрал разработчик без DevOps‑бэкграунда примерно за полтора месяца изучения темы. Код хранится в GitHub и при push автоматически триггерит Cloud Build. Сервис собирается в Docker‑контейнере и проходит несколько уровней тестирования (unit, integration, end‑to‑end через Playwright). После этого версия проходит через staging — зеркало продакшена с теми же настройками и инфраструктурой — и затем может быть перенесена в production в Cloud Run. При добавлении новых функций также выполняются миграции базы данных (используется Supabase).

«докер контейнер это такой маленький компьютер который везде одинаковый типа он меня на компьютере одинаковый облаке одинаковые»
Эксперт сообщества heg.aiучастник эфира, heg.ai community

Ограничения

  • Подход описан как личная реализация и не претендует на универсальный стандарт DevOps.
  • Канареечный деплой становится полезным только при заметном количестве пользователей.
  • Требуется поддерживать тесты и миграции базы данных при добавлении новых функций.

Частые вопросы

Зачем использовать Docker в пайплайне деплоя?
Контейнер обеспечивает одинаковую среду выполнения: сервис работает одинаково на локальной машине разработчика и в облаке.
Какие типы тестов используются перед деплоем?
В пайплайне используются unit‑тесты, интеграционные тесты и end‑to‑end тесты через Playwright. Отдельно упоминаются также smoke‑ и регрессионные тесты.
Что такое staging‑окружение?
Это среда, полностью повторяющая продакшен — со всеми настройками, секретами и инфраструктурой — где тестируется версия перед релизом.
Зачем запускать тесты до выкладки?
Если тесты падают раньше, сборка не отправляется дальше и не тратятся ресурсы на запуск заведомо сломанной версии.
Где в этой схеме запускается сервис для пользователей?
После прохождения тестов и проверки в staging версия может быть развернута в Cloud Run, где и работает продакшен‑версия сервиса.

Источники

  • Эфир сообщества heg.ai «Production-ready для вайбкодинга» (запись доступна участникам сообщества) — heg.ai · 2026-02-16

Business AI brief

Раз в неделю — честный AI business brief

Кейсы, цифры, провалы и workflows для предпринимателей. Без вендорского хайпа.

Нажимая, вы соглашаетесь с обработкой данных (152-ФЗ).

Предпочитаете Telegram? Читать в Telegram