Ну что ребятки, финалим эту серию про CI, какие задачи лучше не делать в CI.

Присаживайтесь поудобнее мы погружаемся в инфраструктурный хардкор.

Лакмусовой бумажкой того, что задаче не место в CI — если в Job не нужно получать последнюю версию кода. Если для ускорения выполнения Job вы хотите отключить клонирование мастера, задачу точно нужно выносить в другую систему.

Например вы хотите пинговать разработчика, если у него упал пайплайн на МРе. Это не CI-задача, и нет смысла занимать под неё целый runner.

В идеале я бы советовал развернуть на серверах компании какой-нибудь n8n. Вы тогда получаете гибкий инструмент в котором можете развлекаться как хотите без влияния на пайплайны.

Требуется гибкая логика повторных запусков. В Gitlab и похожих системах есть retry, но весьма тупой. Он не позволяет задать условия повторного запуска, основанные на типах ошибок или внешнем состоянии.

Нельзя например сказать: «Повтори, если ошибка 500», «Повтори с экспоненциальной задержкой».

В этом случае лучше подойдут системы c возможностью описывать, при каких условиях и сколько раз нужно повторять шаг вроде Airflow, Prefect или Temporal.

Вас не устраивает линейная структура. Если у вас возникает желание, ах вот если бы сюда поставить if или какой-нибудь while, то это явно не про CI. Платформы вроде GitLab CI поддерживают только линейное выполнение без предусловий. Airflow, Prefect и Dagster позволяют описывать не только последовательность действий, но и условия, при которых они должны выполняться.

Вам нужен гибкий cron с историй запусков. В CI системах есть примитивный cron вроде: «запускай вот этот пайплайн каждый день в 12 ночи». Однако в задачах вроде дообучения моделей или каких-то бизнес процессах могут возникнуть потребность: «выполнять cron только по будням», «пропускать запуск, если нет входных данных», «догнать пропущенные даты если была ошибка».

Помимо этого в Gitlab CI еще и историю запусков по cron нельзя просмотреть, показывается только последний запуск, а этого может быть мало.

Пайплайн должен реагировать на внешнее событие. Поступление файла, вебхук, изменение записи в базе — CI не предназначен для этого. Он реагирует только на изменения в коде или cron.

Если логика основана на событиях извне, её проще и надёжнее реализовать в n8n или Prefect, где предусмотрены подписки на события, задержки и отложенные действия.

Подводя итог: CI нужен для тестов, сборок и деплоя. Всё, что выходит за рамки «выполни скрипт и проверь результат», особенно если это связано со временем, входными данными, внешними событиями или сложными зависимостями — должно выполняться в отдельных специализированых системах.

Если же данный пост показался вам слишком перегруженным и вы потерялись в названии кучи сервисов записывайтесь на мой авторский курс «Батя инфры» на котором я научу вас работать с данными системами и зарабатывать миллионы.