Что такое «слоеные» диффы (Stacked Diffs) и почему они важны?
Для инженера ИИ-систем глубокое понимание рабочих процессов Git, включая принципы DevOps и MLOps, является критически важным навыком. Эффективное управление кодом, моделями и данными - это основа для успешного развертывания AI-решений.
Продолжаю работу над методологией конвейера по генерации release notes (сильно отвлекся, но закрыть тему надо), нашел интересную статью о том, как организован процесс работы в Git в Google, Uber и других крупных компаниях. Краткое описание - ниже.
“Stacked Diffs (and why you should know about them)”
Замедляется ли ваш цикл разработки из-за огромных и сложных пулл-реквестов (PR)? Концепция «слоеных диффов» (Stacked Diffs), при которой большое изменение разбивается на серию мелких, зависимых и индивидуально проверяемых коммитов, меняет методы работы ведущих инженерных команд.
В этой статье от The Pragmatic Engineer объясняется рабочий процесс со слоеными диффами, включая:
Как он устраняет узкие места в процессе ревью и ускоряет обратную связь.
Необходимые инструменты и практики для управления зависимостями и ребейзингом (самой сложной частью).
Почему такие компании, как Meta (признана запрещенной в России) и Google, внедрили эту модель для повышения продуктивности разработчиков.
Если вы программист или руководитель команды и ищете способ повысить эффективность код-ревью и сократить переключение контекста при работе над крупными фичами, эта статья обязательна к прочтению.
https://
Мое мнение по поводу прочитанного
Указанные компании работают с моно-репами, поэтому частое изменение ветки main для них является серьезным “бутолочным горлышком” в движении кода, для них описанная методология является спасением. IBM в своих курсах по DevOps, наоборот, настоятельно рекомендует отказаться от монореп в пользу большого количества мелких репо - каждому сервису свое репо (все под микросервисную архитектуру). У меня свой CI/CD еще в стадии разработки, чтобы я мог дать взвешенную оценку, поэтому пока только фиксирую, что сторонники есть у обоих подходов.
По описанной методике. Автор статьи говорит, что git rebase становится ежедневной нормальной практикой как раз из-за того, что ветка main в монорепе постоянно меняется и необходимо свои локальные ветки подгонять под эти изменения. Подход кажется в принципе логичным, потому что даже в небольшом репо, где работает одновременно несколько разработчиков или даже ты сам над несвязанными задачами одновременно, проблема ровно такая же и ее нужно как-то решать. Я старался всегда использовать merge, чтобы сохранять историю и иметь возможность проследить, что откуда и когда пришло, тем не менее даже в моих личных репозиториях история очень скоро становится нечитаемой.
Я точно поразмышляю, как внедрить описанный подход в собственную культуру разработки. Но к моно-репе морально-психологически пока не готов, потому что управление таким репозиторием в принципе требует особого подхода, даже без stacked-diffs. Мне пока достаточно и того, что приходится осваивать и внедрять на текущий момент: conventional commits, тэги, префиксы и т.д. для простой, казалось бы, задачи автоматизации генерации release notes для одного репо. Разберемся с этим, дальше посмотрим. Статья отличная, потому зафиксировал в посте.
#git #MLOPs #DevOps #Google #IBM