CI/CD для вайбкодинга: деплой без простоя и откат за 1 минуту

Ты можешь генерировать код ИИ хоть каждый час, но без CI/CD любой релиз в прод становится лотереей. Пока выкладка делается «руками», у тебя всегда есть риск: забыли миграцию, не проверили health, затёрли .env, получили даунтайм.

Ниже рабочая схема, которая подходит для вашего формата сайта: быстро, без переусложнения и с реальным контролем качества.

## Короткий ответ

CI/CD нужен даже соло-разработчику, если проект уже в проде и на нём есть пользователи. Минимум для взрослого релиза:

1. Автосборка и автотесты на каждый push.
2. Деплой в неактивную среду (blue/green или аналог).
3. Обязательный health-check перед переключением трафика.
4. Явный rollback-скрипт (одна команда).

Если этих четырёх пунктов нет, «релиз без простоя» фактически не гарантирован.

## Где CI/CD даёт максимум пользы

• Когда обновления выходят чаще 1 раза в неделю.
• Когда есть авторизация, платежи, вебхуки, интеграции.
• Когда проект поддерживается через ИИ-ассистентов и легко допустить регрессию.
• Когда нужен предсказуемый откат без ночных аварий.

## Минимальная архитектура релиза

Для большинства проектов на Node/Python/Go достаточно:

• GitHub Actions как orchestration layer.
• Docker-образ как единый артефакт.
• Две runtime-среды (blue и green).
• Reverse proxy (Nginx/Traefik) для переключения трафика.
• Проверка /health перед switch.

## Готовый промпт для ИИ (копируй)

Ты senior DevOps.
Нужен production-ready CI/CD пайплайн для веб-приложения.

Контекст:
- стек: [укажи стек]
- деплой: Docker на VPS
- стратегия: blue-green
- цель: zero-downtime + rollback за 1 команду

Сделай:
1) .github/workflows/deploy.yml
2) Dockerfile (multi-stage, non-root)
3) docker-compose.prod.yml с blue/green сервисами
4) switch.sh и rollback.sh
5) health-check сценарий до переключения
6) короткую инструкцию запуска

Требования:
- не хранить секреты в репозитории
- fail-fast на тестах
- отключение деплоя при падении health-check
- логирование шагов без утечки токенов

## Пример workflow (база, которую можно адаптировать)

name: Deploy Production

on:
  push:
    branches: ["main"]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build image
        run: docker build -t registry.example.com/app:${{ github.sha }} .

      - name: Push image
        run: docker push registry.example.com/app:${{ github.sha }}

      - name: Deploy to inactive slot
        run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./deploy-to-inactive.sh ${{ github.sha }}"

      - name: Health check
        run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./health-check.sh"

      - name: Switch traffic
        run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./switch.sh"

## Антипаттерны, которые убивают релизы

• Деплой напрямую на единственный инстанс без промежуточной проверки.
• Отсутствие rollback-команды (откат «руками» = долго и рискованно).
• Проверка только «контейнер поднялся», без реального HTTP health-check.
• Секреты в .env внутри репозитория.
• Миграции БД, несовместимые с предыдущей версией приложения.

## Чеклист перед продом

1. Есть отдельные секреты для staging и production.
2. Docker-образ собирается повторяемо (multi-stage, pinned base image).
3. /health проверяет не только процесс, но и доступ к БД/кэшу.
4. Rollback проверен на практике минимум один раз.
5. После релиза отслеживаются 4 DORA-метрики.

## Что читать дальше

• Docker для новичка: полный гайд по запуску, образам и контейнерам
• Чистая архитектура: как не превратить проект в спагетти
• Подключение домена к Cloudflare: рабочая схема без ошибок
• Почему «оно работает» не равно качеству: проверка кода от ИИ