Git workflow

Лев Коваленко — Senior DS Engineer

Какие workflow существуют?

Gitflow

Gitflow одна из первых методологий управления проектом направленное на периодические, не частые релизы. В ней есть основная ветка master, в которой хранятся все релизы. До релиза разрабатываемый код находится в ветке develop. Каждое нововведение (фичу) один разработчик разрабатывает в отдельной ветке, после этого она сливается с веткой develop. Когда выполнен весь объем фич для релиза, из develop создается ветка release, в которой ведется доработка релиза и потом она вливается в master и тегируется, а также вливается в develop. Теги отвечают за версии релизов. В случае обнаружение багов в релизе появляется ветка hotfix в которой исправляются ошибки и она снова вливается в master и develop.

Как видите, методология достаточно тяжеловесная и применима в основном в enterprise разработке, так как она подстраивается под большинство фреймворков управления проектов по водопадной модели. Она хорошо используется в проектах, у которых есть несколько стендов, сложная инфраструктура и несколько этапов тестирования. В исследования применить такую методологию можно, но в результате вы получите очень много overhead для проекта по управлению ветками.

Github flow

Github flow это модификация gitflow предложенная github. Она направлена на снижение количества веток и упрощение поддерживания проекта. В ней оставаться две ветке - master и feature. Разработка новой функциональности проводится в отдельной фича-ветке, после этого происходит merge в master, после этого происходит новый релиз проекта.

Эта методология построена для проектов, управляемых в различных гибких методологиях. Одной из важных рекомендаций авторов, является открытие merge request заранее и обсуждение в нем различных моментов заранее, до окончания работ. В целом методология достаточно легковесная и гибкая, может подойти для проведения исследований, но в исследовании нет потребности в такой частоте релизов на начальных этапах.

Forking workflow

Forking workflow это методология поверх github workflow для разработки opensource проектов. Основная сложность в opensource связана с тем, что изначально доступа к изменению в репозитории проекта у потенциального контрибьютора нет, поэтому ему предлагается следующая последовательность шагов:

Разработчик «разветвляет» «официальный» серверный репозиторий. Это создает их собственную копию на стороне сервера.
Новая серверная копия клонируются в их локальную систему.
В локальный клон добавлен удаленный путь Git для «официального» репозитория.
Создана новая локальная ветка функции.
Разработчик вносит изменения в новую ветку.
Для изменений создаются новые коммиты.
Ветвь помещается в собственную серверную копию разработчика.
Разработчик открывает запрос на перенос из новой ветки в «официальный» репозиторий.
Запрос на перенос утверждается для слияния и объединяется в исходный серверный репозиторий.

Таким образом организована разработка в opensource проектах. Могу сказать, что данная методология для исследований подходит плохо, из нее можно позаимствовать идею раздельных репозиториев, что если в команде много исследователей, то возможно их нужно разнести по разным репозиториям и периодически вытаскивать полезные нововведения в “официальный” репозиторий.

Почему эти flow не подходят DS?

Мы вкратце посмотрели основные методологии видения гита, и остается открытый вопрос, а зачем DS-ам придумывать что-то для себя? Почему нельзя переиспользовать какую-то существующую методологию?

Основной ответ в том что порядка 70-85% кода DS не будет использоваться больше чем в одном исследовании. Большая часть кода, который вы пишете, выбрасывается; его ценность заключается в полученных знаниях, а не в самой функциональности или переиспользуемости. То нет необходимости задумываться как организовать код, разделить его на модули и функции, что бы ими было удобно пользоваться и тд, так как ваш код зачастую будет использоваться один раз в вашем исследовании.

Так же можно выделить несколько дополнительных поинтов:

DS-ам часто бывает сложно заранее узнать, как выглядит готовое решение.
Результат эксперимента сильно зависит от данных и их качества.
Хотя мы, как DS-ы, не хотим объединять весь наш код в основной ветке, мы не хотим и выбрасывать его.

Поэтому существует несколько workflow, которые пытаются решить эту проблему.

Data Science Lifecycle Process

Data branch

Explore and experiment branches

Для исследования данных предлагается использовать explore branches. Эти ветки остаются висеть в истории гита без мерджа, потому что код, который проводит исследование нужен разово, чтобы подтвердить или опровергнуть гипотезу.

Для экспериментов есть две стратегии, если эксперимент опроверг подход, то такая ветка не получает merge request и просто оставаться висеть в истории, так как знания о неудачных экспериментах тоже важны и влияют на принятие следующих решений в развитии проекта.

Для успешного эксперимента ветка переходит в ветку моделей.

Model branches

Хорошая методология?

Плюсы

В основной ветке только важный код.
Сохраняется информация о всех исследованиях.
Имеет “логичные” разделения веток для разных задач.

Минусы

Сложно автоматизировать воспроизведение всех исследований.
Информация об исследованиях “размазана” по репозиторию.
В теории выглядит хорошо, а на практике…

Методология конечно неплохая, но сильно оторвана от реальности. По факту в проекте большая часть работы связана с обработкой и подготовкой данных, так как чистые датасеты вы встретите только на kaggle, в реальности придется очень долго разбираться с данными и возвращаться к ним постоянно. Поэтому хотелось бы как-то просто обновлять результаты уже проведенных исследований.

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

Альтернативы..?

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

Для решения этого мы предложили свою методологию на уровне гита: А что если разделить исследования и пайплайн обработки данных и поставки модели?

То есть исследования ведутся в отдельных репозиториях, каждый исследователь ведет их изолировано, а код, который в результате исследования показал хорошие результаты по обработке данных/обучению модели переносить в основной репозиторий?

У нас получается два типа репозиториев - репозиторий исследователя - репозиторий data инженера

Это один из возможных подходов, который решал боль нашей команды, не факт, что он вам подойдет в таком состоянии, но можете попробовать его организовать под себя ил вообще предложить свой подход.

Репозиторий исследователя

Ведется по github flow
Большое количество тетрадок
Одна тетрадка - одно исследование
Каждое исследование в своей ветке
Ревью в первую очередь результатов исследования, а не кода
Поддерживается воспроизводимость исследований
Данные получаются из централизованного хранилища
Новых данных не порождает

В исследовательском репозитории основной принцип - быстрое получение ответа на вопрос, то есть быстрая, не затратная проверка гипотезы. алгоритм работы следующий:

исследователь получает задачу на проверку гипотезы на данных
создает новую ветку под нее
в ней создает новую тетрадку
в этой тетрадке выгружает нужные ему данные из источников или предыдущих результатов работы ETL
проводит описание данных и проверку гипотезы на них в тетрадке
формирует в отчет
открывает merge request c отчетом и ожидает ревью
при необходимости дополняет исследование и вносит правки
вливает merge request в основную ветку

Получается, что при проведении исследования накладывается маленький оверхед, так как исследования изолированы, каждое остается воспроизводимым. Исследователь остается в выигрыше, так как ему не нужно расширять и поддерживать код, а он может сконцентрироваться на отдельном исследовании. Получается некоторая модульность, каждое исследование отдельный модуль, который минимально зависит от других исследований

Но возникает проблема, как же делиться своими наработками? Например, когда нужно передать какой-то способ обработки или препроцсинга данных? Что же делать тогда ctrl+c ctrl+v?

Репозиторий дата инженера

Ведется по git flow
Разрабатывается как пайплайн обработки данных
Порождает данные в централизованное хранилище
Высокие требования к качеству кода

Репозиторий дата инженера — это терминология авторов, он может называться и подругому. Смысл в том, что он является центральным и в нем создается некоторый единый пайплайн обработки данных.

В целом нам, как исследователям не так часто нужен чужой код, как артефакты пораждаемые кодом, зачем нам тащить кусок чужого кода, если мы можем использовать данные которые он породит? В этом и ответ на то как передавать сво результаты — строить пайплайн обработки данных.

Для этого существует общий репозиторий или репозиторий дата инженера, в котором выстраивается пайплайн обработки данных. Репозиторий ведется по git flow, есть ветки фич, develop и master ветки и тд. Если какое-то исследование подтвердило гипотезу и это позволяет улучшить пайплайн обработки данных, то создается задача на обновление пайплайна. Каждое обновление сначала создается в отдельной фича-ветке, так же его данные которые оно порождает складируются в отдельную папку. Этими данными другие исследователи могут пользоваться но на свой страх и риск. После завершения разработки, создается merge request в develop ветку, проводится ревью кода, а затем merge request вливается или правится. Данные порожденные пайплайном так же переносятся в другую директорию, где они находятся в состоянии stage, то есть ими уже можно пользоваться с минимальными рисками, так как код был проверен и все хорошо.

После того как накопилось достаточно изменений, команда сама для себя определяет это значение “достаточно”, готовится релиз пайплайна, вносятся дополнительные правки, рефакторится тех долг и тд, затем код попадает в master.

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

В итоге исследователи между собой могут делится данными и другими артефактами в репозитории дата инженера, при этом сами исследования минимально зависят друг от друга, и не требуется перепроверять, а действительно ли все воспроизводится, если я расширил сигнатуру функции на один аргумент. Весь процесс становится гибким и модульным.

Плюсы и минусы

Плюсы

Быстрое проведение исследований
Исследования и исcледователи независимы
Все исследования воспроизводимы
Единый пайплайн обработки данных
В пайплайне только нужный код

Минусы

Нужно следить и за данными и за кодом
Иногда появляется копипаста в исследованиях
Нужно поддерживать пайплайн обработки данных

Методология позволяет сократить время на проведение исследования, так как нет необходимости интегрировать его с уже написанным кодом, а это избавляет от необходимости рефакторить и поддерживать все исследования сразу. Из-за изолированности исследования не зависят от общего кода, и их проще сделать воспроизводимыми. Правда появляется новая зависимость — данные, исследования очень сильно привязаны к определенной структуре и версии данных, что требует использовать специальные инструменты для работы с данными. Так же к минусам можно отнести что некоторые куски кода копируются из одного исследования в другое, что может привести к потенциальным ошибкам.

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