Комментарии 12
Отличная статья, Роза, настройка пайплайнов для MLOps - достаточно творческая задача, полезно почерпнуть интересные подходы из твоего решения, которые, что очень ценно, были опробованы на практике.
Хорошая статья.
Единственное, непонятно, почему линты не проводить до билда, нулевым стейджом? Вы же проверяете _только_ свой код, чужие зависимости не нужны. Контейнер с pylint\flake8 статичен\редко обновляется. Инженеры сразу получают результат.
Ну и всякие gitleaks тоже обычно в нулевой стейдж пихают, чтобы контейнер с паролем не упал в реджестри
Спасибо!)
В начале так и было - линтеры были с отдельным образом в отдельной джобе, которая ни от чего не зависела. Но мы в итоге столкнулись с несколькими проблемами:
некоторым линтерам нужно окружение проекта (типа mypy)
в линтерах у нас так же запускается часть сканеров безопасности, которым тоже нужны зависимости
В итоге линтеры мы стали поставлять вместе с окружением сервиса. То есть они описаны в платформенных дев-зависимостях в pyproject.toml проекта и обновляются платформой у каждого отдельного проекта.
Также замечу, что линтеры собираются только первый раз, потом они редко меняются и поэтому фактически в рамках одного проекта почти "статичны" и запускаются сразу, так как джоба сборка кешей завершается почти мгновенно (после поднятия раннера).
Еще вопрос по makefile, почему использовали его а не pre-commit? DS может забыть его вызвать, а pre-commit не даст закомитить/запущить код который имеет проблемы.
Pre-commit не является полной заменой Makefile, это фактически два разных инструмента, которые решают две разные проблемы.
Pre-commit у нас разрабы могут поставить из проекта. Как раз как вы описали - чтобы не закоммитить плохо написанный код (с т.зр. линтеров).
Его полноценная настройка также есть в Makefile, чтобы можно было удобно настроить или чтобы чел, который не знает, как им пользоваться, тоже смог его заюзать.
Но в CI/CD мы не используем пре-коммит, а только напрямую линтеры вызываем. И в Makefile мы тоже повторили это действие, чтобы разраб мог один в один запустить так же линтеры, как они в пайплайне запускаются.
Ну и еще конечно в Makefile у нас там дофигаллион команд, от настройки окружения до поднятия докеров/миникубов и вот это все)
У меня сложилось впечатление, что пре-коммит - это как бы дело вкуса конкретного разрабочика, он если его хочет - настроит.
дополню про pre-commit - для того, чтобы его прогнать в ci нужно тянуть дополнительную зависимость в виде самого гита
плюс при разработке не всегда удобно, чтобы на каждый коммит у тебя прогонялись все линты. например, я при разработке делаю несколько промежуточных коммитов перед тем как что-то запушить в ремоут. ну и как правило перед тем, как что-то финально уже получается я сквошу свои коммиты в один и над ним прогоняю линты и форматы. так что это дело вкуса и нервов разработчика)
Ещё подскажите, а какие инструменты mlops и как вы используете на этапе исследований? Mlops это не только про продакшен, это и про работу исследователя и тд. Было бы интересно узнать это, потому что сам сейчас копаюсь в этой теме и интересен опыт коллег по несчастью
А почему про статью MLOps мало сказано про MLOps? Тут в целом про разработку..
Почему вы не используете pre-commit на стороне сервера, push с "плохими" коммитами не удастся пропустить?
Именно для таких целей и подходит pre-commit, в Makefile необходимо вызывать команды и тд, pre-commit же автоматически делает проверку
А в чем сложность установить Jupyter руками?
Готовим по рецепту: CI/CD в MLOps