Непрерывная интеграция в dbt Cloud

Чтобы реализовать рабочий процесс непрерывной интеграции (CI) в dbt Cloud, вы можете настроить автоматизацию, которая тестирует изменения в коде, запуская CI задачи перед слиянием в производственную среду. dbt Cloud отслеживает состояние того, что выполняется в вашей производственной среде, поэтому, когда вы запускаете CI задачу, только измененные данные в вашем pull request (PR) и их зависимые элементы строятся и тестируются в промежуточной схеме. Вы также можете просматривать статус проверок CI (тестов) непосредственно из PR; эта информация отправляется вашему Git-провайдеру сразу после завершения CI задачи. Кроме того, вы можете включить настройки в вашем Git-провайдере, которые позволяют одобрять PR только с успешными проверками CI для слияния.

Рабочий процесс непрерывной интеграции в dbt Cloud

Использование CI помогает:

• Обеспечить повышенную уверенность и гарантии, что изменения в проекте будут работать в производственной среде, как ожидалось.
• Сократить время, необходимое для внедрения изменений в код в производственную среду, благодаря автоматизации сборки и тестирования, что приводит к лучшим бизнес-результатам.
• Позволить организациям вносить изменения в код стандартизированным и управляемым образом, который обеспечивает качество кода без ущерба для скорости.

Как работает CI

Когда вы настраиваете CI задачи, dbt Cloud ожидает уведомления от вашего Git-провайдера, указывающего, что был открыт новый PR или обновлен новыми коммитами. Когда dbt Cloud получает одно из этих уведомлений, он ставит в очередь новый запуск CI задачи.

dbt Cloud строит и тестирует модели, семантические модели, метрики и сохраненные запросы, затронутые изменением кода, в временной схеме, уникальной для PR. Этот процесс гарантирует, что код строится без ошибок и соответствует ожиданиям, определенным тестами dbt проекта. Уникальное имя схемы следует соглашению об именовании dbt_cloud_pr_<job_id>_<pr_id> (например, dbt_cloud_pr_1862_1704) и может быть найдено в деталях запуска для данного запуска, как показано на следующем изображении:

Просмотр имени временной схемы для запуска, вызванного PR

Когда запуск CI завершен, вы можете просмотреть статус запуска непосредственно из pull request. dbt Cloud обновляет pull request в GitHub, GitLab или Azure DevOps с сообщением о статусе, указывающим результаты запуска. Сообщение о статусе указывает, были ли модели и тесты выполнены успешно или нет.

dbt Cloud удаляет временную схему из вашего при закрытии или слиянии pull request. Если в вашем проекте есть настройка схемы с использованием макроса generate_schema_name, dbt Cloud может не удалить временную схему из вашего хранилища данных. Для получения дополнительной информации обратитесь к разделу Устранение неполадок.

Различия между CI задачами и другими задачами развертывания

Планировщик dbt Cloud выполняет CI задачи иначе, чем другие задачи развертывания, в следующих важных аспектах:

• Параллельные проверки CI — Запуски CI, вызванные одной и той же CI задачей dbt Cloud, выполняются параллельно, когда это уместно.
• Умная отмена устаревших сборок — Автоматически отменяет устаревшие, выполняющиеся CI запуски, когда в PR появляются новые коммиты.
• Обработка слотов запуска — CI запуски не занимают слот запуска.
• SQL линтинг — При включении автоматически проверяет все SQL файлы в вашем проекте как шаг запуска перед сборкой вашей CI задачи.

Параллельные проверки CI

Когда ваши коллеги сотрудничают над одним и тем же dbt проектом, создавая pull requests в одном и том же dbt репозитории, одна и та же CI задача будет запускаться. Поскольку каждый запуск строится в выделенной, временной схеме, связанной с pull request, dbt Cloud может безопасно выполнять CI запуски параллельно, а не последовательно (в отличие от того, что делается с задачами развертывания dbt Cloud). Поскольку никому не нужно ждать завершения одного CI запуска, чтобы начать другой, с параллельными проверками CI вся ваша команда может быстрее тестировать и интегрировать dbt код.

Ниже описаны условия, при которых проверки CI выполняются параллельно и когда они не выполняются:

• CI запуски с разными номерами PR выполняются параллельно.
• CI запуски с одинаковым номером PR и разными SHA коммитов выполняются последовательно, так как они строятся в одной и той же схеме. dbt Cloud выполнит последний коммит и отменит все более старые, устаревшие коммиты. Для подробностей обратитесь к Умной отмене устаревших сборок.
• CI запуски с одинаковым номером PR и одинаковым SHA коммита, исходящие из разных проектов dbt Cloud, будут выполнять задачи параллельно. Это может произойти, когда две CI задачи настроены в разных проектах dbt Cloud, которые используют один и тот же dbt репозиторий.

Умная отмена устаревших сборок

Когда вы отправляете новый коммит в PR, dbt Cloud ставит в очередь новый CI запуск для последнего коммита и отменяет любой CI запуск, который (теперь) устарел и все еще выполняется. Это может произойти, когда вы отправляете новые коммиты, пока CI сборка все еще в процессе и не завершена. Отменяя запуски безопасным и обдуманным образом, dbt Cloud помогает повысить производительность и сократить расходы на платформу данных на бесполезные CI запуски.

Пример автоматически отмененного запуска

Обработка слотов запуска teamenterprise

CI запуски не занимают слоты запуска. Это гарантирует, что проверка CI никогда не заблокирует производственный запуск.

SQL линтинг teamenterprise

Доступно на релизных треках dbt Cloud и в аккаунтах dbt Cloud Team или Enterprise.

Когда включено для вашей CI задачи, dbt вызывает SQLFluff, который является модульным и настраиваемым SQL линтером, предупреждающим вас о сложных функциях, синтаксисе, форматировании и ошибках компиляции. По умолчанию он проверяет все измененные SQL файлы в вашем проекте (по сравнению с последним отложенным производственным состоянием).

Если линтер обнаруживает ошибки, вы можете указать, должен ли dbt остановить выполнение задачи при ошибке или продолжить выполнение при ошибке. При отказе от задач это помогает снизить затраты на вычисления, избегая сборок для pull requests, которые не соответствуют вашему CI проверке качества SQL кода.

Чтобы настроить линтинг SQLFluff:

Вы можете при необходимости настроить правила линтинга SQLFluff, чтобы переопределить поведение линтинга по умолчанию.

• Используйте Конфигурационные файлы SQLFluff, чтобы переопределить поведение линтинга по умолчанию в dbt.
• Создайте конфигурационный файл .sqlfluff в вашем проекте, добавьте в него свои правила линтинга, и dbt Cloud будет использовать их при линтинге.
  • При настройке вы можете использовать dbt в качестве шаблонизатора (например, templater = dbt)
  • Если вы используете dbt Cloud IDE, dbt Cloud CLI или любой другой редактор, обратитесь к Настройка линтинга для получения рекомендаций о том, как добавить dbt-специфичные (или dbtonic) правила линтинга, которые мы используем для собственного проекта.
• Для получения полной информации обратитесь к Пользовательское использование в документации SQLFluff.