Классический флоу выглядит так: закоммитил → запушил → подождал раннер → подождал установку зависимостей и тесты → переключил контекст на другую задачу → вернулся, увидел красный крестик и пытаешься вспомнить, что вообще делал.
Автор предлагает концепцию Local-First CI. Идея в том, что вся пайплайн-логика должна быть описана так, чтобы она могла локально выполниться на машине разработчика до пуша в репозиторий.
Какие плюсы у локального CI:
— Скорость. Рабочие машины разработчиков (особенно современные Mac) часто гораздо мощнее стандартных бесплатных раннеров (у тех же GitHub Actions всего 4 vCPU и 16 GB RAM).
— Фокус. Вы не переключаете контекст. Ошибка падает сразу, и вы фиксите её, оставаясь в потоке.
— Отсутствие вендор-лока. Если весь ваш CI — это условный баш-скрипт
./ci.sh в корне проекта, вам всё равно, где его запускать. Вы не привязаны к специфичным YAML-файлам конкретного провайдера.— Локальная воспроизводимость. Больше не нужно делать коммиты с названиями
fix ci, try again, maybe now?, пытаясь вслепую угадать, почему тест падает на сервере, но работает у вас.Есть и минусы, конечно.
Главная проблема наивного подхода с
./ci.sh — рассинхрон сред. У вас локально macOS и gcc 15, а на сервере Ubuntu и gcc 14. У вас замусоренная папка с билдами и завалявшийся .env, а CI стартует с чистого листа.Решением автор логично называет воспроизводимые сборки (reproducible builds), в частности — использование Nix. Команда
nix flake check гарантирует, что локальное и удалённое окружение будут абсолютно идентичными вплоть до версий системных библиотек . Но даже без Nix, максимальный перенос логики проверок в локальную среду (например, через Docker) — это отличная практика для ускорения разработки.Полная статья: https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-your-machine-first
@prog_stuff