Continuous integration in dbt
Чтобы реализовать процесс непрерывной интеграции (CI) в dbt, вы можете настроить автоматизацию, которая проверяет изменения кода, запуская CI jobs перед слиянием изменений в production. dbt отслеживает состояние того, что выполняется в вашем production‑окружении, поэтому при запуске CI job собираются и тестируются только изменённые data assets из вашего pull request (PR) и их downstream‑зависимости — в staging‑схеме.
Вы также можете просматривать статус CI‑проверок (тестов) прямо из PR; эта информация публикуется в вашем провайдере Git сразу после завершения CI job. Кроме того, вы можете включить настройки в вашем провайдере Git, которые разрешают одобрение PR для слияния только при успешном прохождении CI‑проверок.
Workflow of continuous integration in dbtИспользование CI помогает:
- Обеспечить повышенную уверенность и гарантии, что изменения в проекте будут работать в производственной среде, как ожидалось.
- Сократить время, необходимое для внедрения изменений в код в производственную среду, благодаря автоматизации сборки и тестирования, что приводит к лучшим бизнес-результатам.
- Позволить организациям вносить изменения в код стандартизированным и управляемым образом, который обеспечивает качество кода без ущерба для скорости.
Как работает CI
Когда вы настраиваете CI jobs, dbt ожидает уведомление от вашего провайдера Git о том, что был открыт новый PR или в существующий PR были добавлены новые коммиты. Когда dbt получает такое уведомление, он ставит в очередь новый запуск CI job.
dbt собирает и тестирует модели, семантические модели, метрики и сохранённые запросы, на которые повлияло изменение кода, во временной схеме, уникальной для конкретного PR. Этот процесс гарантирует, что код собирается без ошибок и соответствует ожиданиям, определённым dbt‑тестами проекта. Уникальное имя схемы формируется по соглашению dbt_cloud_pr_<job_id>_<pr_id> (например, dbt_cloud_pr_1862_1704) и может быть найдено в деталях запуска соответствующего run, как показано на изображении ниже:
Просмотр имени временной схемы для запуска, вызванного PRКогда выполнение CI завершится, вы сможете посмотреть статус запуска прямо в рамках pull request. dbt обновляет pull request в GitHub, GitLab или Azure DevOps, добавляя статусное сообщение с результатами запуска. В этом сообщении указывается, были ли модели и тесты выполнены успешно или нет.
dbt удаляет временную схему из вашего data warehouse при закрытии или слиянии pull request. Если в вашем проекте используется кастомизация схем с помощью макроса generate_schema_name, dbt может не удалить временную схему из вашего хранилища данных. Подробнее см. в разделе Troubleshooting.
Доступность функций в зависимости от Git‑провайдера
-
Если ваш git‑провайдер имеет нативную интеграцию с dbt, вы можете без лишних усилий настраивать задания continuous integration (CI) прямо в dbt.
-
Для провайдеров без нативной интеграции вы всё равно можете использовать метод Git clone, чтобы импортировать git URL, и задействовать Administrative API dbt для запуска CI‑заданий.
В следующей таблице приведены доступные варианты интеграции и соответствующие им возможности.
| Loading table... |
Различия между CI задачами и другими задачами развертывания
Планировщик dbt выполняет CI‑задачи иначе, чем другие задачи деплоя, по следующим важным причинам:
- Параллельные CI‑проверки — CI‑запуски, инициированные одной и той же CI‑задачей dbt, при необходимости выполняются одновременно (параллельно).
- Умная отмена устаревших сборок — Автоматически отменяет устаревшие, уже запущенные CI‑запуски, когда в PR появляются новые коммиты.
- Использование run slot — CI‑запуски не занимают run slot.
- SQL‑линтинг — При включении автоматически выполняет линтинг всех SQL‑файлов в вашем проекте как шаг запуска перед сборкой CI‑задачи.
Параллельные CI‑проверки StarterEnterpriseEnterprise +
Когда несколько участников команды работают над одним и тем же dbt‑проектом и создают pull request’ы в одном репозитории dbt, будет запускаться одна и та же CI‑задача. Поскольку каждый запуск выполняет сборку в выделенной временной схеме, привязанной к конкретному pull request’у, dbt может безопасно выполнять CI‑запуски параллельно, а не последовательно (в отличие от deployment‑задач dbt). Так как нет необходимости ждать завершения одного CI‑запуска перед началом другого, параллельные CI‑проверки позволяют всей команде быстрее тестировать и интегрировать dbt‑код.
Ниже описаны условия, при которых проверки CI выполняются параллельно и когда они не выполняются:
- CI-запуски с разными номерами PR выполняются параллельно.
- CI-запуски с одинаковым номером PR и разными commit SHA выполняются последовательно, потому что они собираются в одну и ту же схему. dbt запустит сборку для последнего коммита и отменит все более старые, устаревшие коммиты. Подробности см. в разделе Smart cancellation of stale builds.
- CI-запуски с одинаковым номером PR и одинаковым commit SHA, запущенные из разных проектов dbt, будут выполнять задания параллельно. Такая ситуация возможна, если два CI-задания настроены в разных проектах dbt, которые используют один и тот же репозиторий dbt.
Умная отмена устаревших сборок StarterEnterpriseEnterprise +
Когда вы отправляете новый коммит в PR, dbt ставит в очередь новый CI-запуск для последнего коммита и отменяет любой CI-запуск, который стал (к этому моменту) устаревшим и всё ещё выполняется. Это может происходить, если вы отправляете новые коммиты, пока предыдущая CI-сборка ещё находится в процессе выполнения и не завершилась. Отменяя такие запуски безопасным и контролируемым образом, dbt помогает повысить продуктивность и сократить затраты на платформу данных за счёт уменьшения числа бесполезных CI-запусков.
Пример автоматически отмененного запускаОбработка run slot StarterEnterpriseEnterprise +
CI запуски не занимают слоты запуска. Это гарантирует, что проверка CI никогда не заблокирует производственный запуск.
SQL‑линтинг StarterEnterpriseEnterprise +
Доступно для треков релизов dbt и аккаунтов dbt уровней Starter или Enterprise.
Когда включено для вашего CI‑задания, dbt вызывает SQLFluff — модульный и настраиваемый SQL‑линтер, который предупреждает о сложных функциях, ошибках синтаксиса, форматирования и компиляции.
По умолчанию SQL‑линтинг проверяет все изменённые SQL‑файлы в вашем проекте (по сравнению с последним отложенным состоянием production). Обратите внимание, что snapshots могут быть определены как в YAML, так и в .sql файлах, однако их SQL не подлежит линтингу и может вызывать ошибки во время проверки. Чтобы SQLFluff не проверял файлы snapshots, добавьте директорию snapshots в файл .sqlfluffignore (например, snapshots/). Подробнее см. в разделе линтинг snapshots.
Если линтер обнаруживает ошибки, вы можете указать, должен ли dbt остановить выполнение задачи при ошибке или продолжить выполнение при ошибке. При отказе от задач это помогает снизить затраты на вычисления, избегая сборок для pull requests, которые не соответствуют вашему CI проверке качества SQL кода.
Чтобы настроить линтинг SQLFluff:
Вы можете при необходимости настроить правила линтинга SQLFluff, чтобы переопределить поведение линтинга по умолчанию.
- Используйте файлы конфигурации SQLFluff, чтобы переопределить поведение линтера по умолчанию в dbt.
- Создайте файл конфигурации
.sqlfluffв своём проекте, добавьте в него правила линтинга, и dbt будет использовать их при проверке.- При настройке вы можете указать
dbtв качестве шаблонизатора (например,templater = dbt) - Если вы используете Studio IDE, CLI dbt или любой другой редактор, обратитесь к разделу Customize linting, где описано, как добавить специфичные для dbt (или dbtonic) правила линтинга, которые мы используем в собственных проектах.
- При настройке вы можете указать
- Подробную информацию см. в разделе Custom Usage документации SQLFluff.
