Середовище розробки та CI
Я намагаюся автоматизувати всі завдання проекту і використовувати для локальної розробки та CI один і той самий набір рішень. Не тільки те, що стосується test/build/deploy, а й усі інші повторювані завдання, типу ініціалізації оточення розробника, підготовки даних, генерації документації тощо. Це дає незалежність від поточної реалізації CI, відсутність дублювання функцій, постійний догфудінг розробниками і стимулює команди самостійно управляти та розвивати CI свого продукту. У такого рішення є і очевидна зворотна сторона — доводиться в межах одного рішення задовольняти всі вимоги для обох світів. Найчастіше від цього страждає швидкість збірки, читабельність результатів та простота.
Основні вимоги:
- Ізоляція: Запуск усіх інструментів у Docker-контейнерах
- Скриптинг: Підтримка сучасних мов (TS/Go/Py) замість чистого bash/YAML
- Open Source: Без прив’язки до SaaS, можливість форку
- Мовна агностичність: Один фреймворк незалежно від стеку проекту
- Seamless CI: Запуск тих самих скриптів локально та в CI
- Кешованість: BuildKit-кеш, remote-cache, Depot?, паралелізм
- Безпека: rootless-user, secrets-mounts
- Мультиплатформеність: arm64/amd64, macOS + Linux (OrbStack/WSL-2)
- Низький поріг входу: мінімум концепцій та необхідних команд
Я періодично повертаюся до цієї теми, і цього разу натрапив на Dagger.io. І більшій частині вимог зі списку він відповідає.
| Вимога | Наскільки підходить Dagger |
|---|---|
| Ізоляція | ✅ Усі етапи виконуються в контейнерах через BuildKit |
| Низький поріг входу | ⚠️ CLI проста, але потрібні нові абстракції (Graph, функції) |
| Скриптинг (TS/Go/Py) | ✅ Підтримка Go, Python, TypeScript SDK |
| Open Source | ✅ Рушій та SDK мають MIT-ліцензію, можна форкнути |
| Мовна агностичність | ✅ Контейнеризований підхід не залежить від стеку додатка |
| Seamless CI | ✅ Один і той самий код працює локально і в більшості CI (Docker-in-Docker или sibling) |
| Кешованість | ✅ BuildKit-кеш та автоматичне кешування функцій; ⚠️ Remote-cache потребує Dagger Cloud |
| Безпека | ⚠️ Є rootless-mode та secrets-mounts, але сканування образів доведеться підключати вручну |
| Мультиплатформеність | ✅ Працює на macOS (arm64/amd64) та Linux; Windows поки в беті |
Плюси
- Єдиний код для CI та локальної розробки — «no more push & pray».
- Програмованість: повноцінні мови замість YAML дозволяють робити умови, цикли, функції, що повторно використовуються.
- Кешування та паралелізм з коробки завдяки BuildKit.
- Модульність: Daggerverse та власні модулі спрощують повторне використання пайплайнів.
- Гарна DX: інтерактивне виконання
dagger run, вбудоване трасування.
Мінуси
- Крива навчання: потрібно зрозуміти модель графа та принципи BuildKit.
- Молодий проект: API ще може змінюватися, менше прикладів, ніж у GitHub Actions.
- Залежність від Docker: без контейнерного демона не запуститься (OrbStack/Colima/WSL-2).
- Windows: офіційна підтримка у бета-стадії.
Підводні камені та рекомендації
- Remote Cache = Dagger Cloud. Для повноцінного віддаленого кешу потрібен SaaS-аккаунт; offline-режим — тільки локальний кеш.
- Secrets. Потрібна окрема логіка для передачі секретів (env/secrets API), інакше вони випадково потраплять у логи.
- Перформанс на macOS ARM. BuildKit у контейнері може працювати повільніше через емуляцію x86, обережно з multi-arch.
- Доставка артефактів. Сам Dagger не пушить у реєстри/сториджі — потрібно явно описувати кроки або підключати модулі.
- Налагодження. При помилках іноді допомагає
dagger sessionс увімкненим--debug, інакше стек викликів неочевидний.
У підсумку Dagger добре закриває більшість моїх вимог і виглядає перспективно як єдиний інструмент для dev-env та CI. Критичні ризики — молодість екосистеми та залежаність від Dagger Cloud для віддаленого кешу. Якщо команда готова інвестувати час в освоєння нових концепцій і влаштовує поточний рівень стабільності, Dagger може стати основою майбутньої інфраструктури.