Автоматизируем Elixir: Пошаговое построение CI/CD-конвейера с GitHub Actions и Docker

В мире разработки на Elixir, известном своей отказоустойчивостью и конкурентной моделью, стабильный и предсказуемый процесс поставки кода (CI/CD) — не роскошь, а необходимость. Он превращает рутинные задачи тестирования, сборки и деплоя в автоматизированный поток, минимизируя человеческие ошибки и ускоряя выход новых фич. В этой статье мы шаг за шагом построим полноценный CI/CD-конвейер для типичного Phoenix-приложения, используя GitHub Actions и Docker.

Начнем с основ. CI (Continuous Integration) — это практика автоматического тестирования каждого изменения в коде. CD (Continuous Delivery/Deployment) расширяет эту идею, автоматизируя сборку, упаковку и развертывание приложения. Для Elixir-проекта это особенно важно из-за особенностей компиляции, зависимостей (Mix) и необходимости работы с базой данных, например, PostgreSQL, в тестовом окружении.

Шаг 1: Подготовка проекта. Убедитесь, что ваш проект имеет стандартную структуру и ключевые файлы: `mix.exs` с прописанными зависимостями и `Dockerfile` для контейнеризации. Для тестов используем ExUnit. Важно настроить конфигурации (`config/test.exs`) для работы с тестовой БД, возможно, используя временные контейнеры или сервисы GitHub Actions.

Шаг 2: Создание базового Dockerfile. Многостадийная сборка — лучший практикс. Первая стадия использует образ `elixir:1.16-alpine` для компиляции релиза. Устанавливаем Mix, копируем конфиги, загружаем зависимости и компилируем проект. Вторая стадия создает минимальный образ на основе `alpine:latest`, куда копируются только скомпилированные артефакты и рантайм. Это значительно уменьшает итоговый размер образа.

Шаг 3: Настройка GitHub Actions. В каталоге `.github/workflows/` создаем файл `ci-cd-pipeline.yml`. Определяем три основных джобы: `test`, `build` и `deploy`. Джоба `test` запускается на каждом пуше в ветки `main` и `develop`. В ней мы настраиваем сервисы (например, контейнер с PostgreSQL), устанавливаем Elixir, восстанавливаем зависимости Mix (`mix deps.get`), создаем и мигрируем тестовую базу (`mix ecto.setup`), и запускаем тесты (`mix test`).

Шаг 4: Сборка и публикация Docker-образа. Джоба `build` зависит от успешного прохождения `test`. Здесь мы логинимся в Docker Hub (или другой Container Registry), используя секреты GitHub, собираем образ по нашему Dockerfile и пушим его с тегом, соответствующим хэшу коммита или номеру версии. Это создает артефакт, готовый к деплою.

Шаг 5: Деплой. Джоба `deploy` — самая вариативная часть. В качестве примера рассмотрим деплой на виртуальную машину через SSH. При успешной сборке мы можем подключиться к целевому серверу, остановить старый контейнер, скачать новый образ и запустить его с обновленными переменными окружения. Для более сложных сценариев можно интегрироваться с Kubernetes (Helm) или облачными платформами вроде Gigalixir, специализирующейся на Elixir.

Важные нюансы для Elixir: Кэширование зависимостей Mix и скомпилированных артефактов (`_build`, `deps`) между запусками пайплайна через `actions/cache` ускорит процесс в разы. Также стоит обратить внимание на статический анализ кода с помощью `credo` и проверку форматирования `mix format --check-formatted`, которые можно добавить в этап тестирования.

Отладка и мониторинг. Настройте уведомления о неудачных сборках в Slack или Telegram. В продакшене используйте инструменты мониторинга самого Elixir, такие как Telemetry, для интеграции с пайплайном (например, запуск нагрузочных тестов на этапе CD). Помните, что главная цель — создать надежный, повторяемый процесс, который освобождает команду от рутины и позволяет сосредоточиться на написании качественного кода для ваших Elixir-приложений.