Автоматический деплой (CD)

Continuous Deployment — автоматическая доставка кода из main-ветки на сервер. От простого rsync до Docker-based деплоя с Kamal, Fly.io или Kubernetes.

Почему это важно: Ручной деплой — источник ошибок и стресса. Автоматический деплой делает релиз рутинной операцией, а не событием. Это позволяет деплоить часто (несколько раз в день) и маленькими порциями — каждый релиз менее рискован.

Главная идея

CD-пайплайн запускается после успешного CI. Он собирает артефакт (Docker-образ, бандл), отправляет на сервер и перезапускает приложение. Ключевые принципы: идемпотентность, rollback, zero-downtime.

Как это выглядит на практике

CI прошёл: тесты зелёные, линтер чист
CD job запускается: собирает Docker-образ приложения
Образ публикуется в registry (Docker Hub, GHCR)
CD подключается к серверу и запускает новый контейнер
Health check подтверждает, что новая версия работает
Старый контейнер останавливается (zero-downtime swap)
При ошибке health check — автоматический rollback к предыдущей версии

Примеры кода

CD с Docker и Kamal

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    # ... (CI шаги из предыдущего урока)

  deploy:
    needs: test  # только после успешных тестов
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1

      - name: Install Kamal
        run: gem install kamal

      - name: Deploy
        env:
          KAMAL_REGISTRY_PASSWORD: ${{ secrets.DOCKER_TOKEN }}
        run: kamal deploy

Простой деплой на VPS через SSH

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /app/myproject
            git pull origin main
            bundle install --deployment
            bin/rails db:migrate
            bin/rails assets:precompile
            sudo systemctl restart myapp

      - name: Health check
        run: |
          sleep 10
          curl --fail https://myapp.com/health || exit 1

Что происходит под капотом

Docker-образ — неизменяемый артефакт: на staging и production запускается одинаковый образ
Health check: CD проверяет /health endpoint после деплоя, rollback при ошибке
Zero-downtime: новый контейнер запускается рядом со старым, трафик переключается после health check
Rollback: откат к предыдущему Docker-образу занимает секунды, не минуты
Секреты (SSH-ключи, токены) хранятся в GitHub Secrets, не в коде

Типичные ошибки и заблуждения

«Деплой — это страшно» — с автоматическим CD и rollback деплой становится безопасной рутиной
«Нужен Kubernetes для CD» — для одного сервера достаточно Kamal, Capistrano или простого SSH-скрипта
«git pull на сервере — это деплой» — это работает, но не идемпотентно и не поддерживает rollback

Ключевые выводы

CD запускается после успешного CI — никогда не деплоить непроверенный код
Docker-образ — идемпотентный артефакт: одинаковый на всех окружениях
Health check + rollback — обязательные компоненты надёжного CD

Термины урока

{:term=>"Zero-downtime deployment", :definition=>"Деплой без перерыва в обслуживании — старая и новая версии работают параллельно во время переключения"}

{:term=>"Rollback", :definition=>"Откат к предыдущей рабочей версии при обнаружении проблемы после деплоя"}

{:term=>"Health check", :definition=>"Автоматическая проверка работоспособности приложения после деплоя (обычно HTTP-запрос к /health)"}

Связь с работой backend-разработчика

Автоматический деплой — финальный элемент CI/CD конвейера. Для малых проектов достаточно SSH + git pull + systemctl restart. Для средних — Kamal или Fly.io. Для крупных — Kubernetes. Но принципы одинаковы: артефакт, health check, rollback.

Мини-разбор реальной ситуации

Стартап деплоил через SSH вручную. Однажды разработчик забыл запустить db:migrate — приложение упало на 2 часа. После внедрения GitHub Actions CD с health check подобные ситуации стали невозможны: при ошибке health check пайплайн автоматически откатывает деплой.

Что запомнить

CD = автодеплой после успешного CI, не вместо него
Health check обязателен — проверяйте, что приложение действительно работает после деплоя
Rollback должен быть автоматическим и занимать секунды

Итог

Continuous Deployment замыкает цикл: код → тесты → деплой → проверка. Автоматический деплой с health check и rollback превращает релиз из стрессового события в рутинную операцию, которая происходит несколько раз в день.