Комментарии 8

Подведя итог можно сказать, что монорепозитории это перекладывание ответственности devops на разработчика.
В результате это только создаёт проблемы разработчику, так как разработчик всё равно не сможет полностью заменить devops.

Вы не правильно понимаете акроним devOps.
Это не какой-то сверх человек вроде сис админа, который еще и в коде понимает. Это набор практик для интеграции разработки и эксплуатации, что бы уменьшить проблемы в сопровождении релизов до стабильной стадии. Т.е разработчик, когда пишет код должен задумываться как этот код будет работать в бою и как его эксплуатировать.
Я прекрасно понимаю что такое devops, и я согласен что разработчик должен знать как это все собрать и запустить. Так вот монорепозиториий это упрощение CI\CD. Не нужно думать какие версии библиотек брать, откуда их брать, так как это все лежит в монорепозитории. А вот как потом брать из монорепозитория для других проектов библиотеки тут начинаются танцы с бубном. То что мне предлагали, это скопировать исходный код в другой монорепозиториий.
Это только звучит очень удобно, на самом деле это только увеличивает time to market при росте как команды, так и сложности проекта.
Ваша проблема решается вынесением общего кода в пакеты и обязательного соблюдения семантического версионирования
Автор верно замечает, что это нетехническая проблема, инструментарий, в том числе репозиторий, должен отражать реальный мир, в реальном мире даже внутри компании есть изолированные друг от друга проекты (это конечно поднимает вопрос о том что есть проект, мой ответ, это то что самостоятельно может приносить деньги, что можно выделить в отдельный бизнес, продать) и вполне логично иметь один репозиторий на проект, однако есть некие универсальные модули, общие для всех (в основном такие которые имело бы смысл выложить в общий доступ т.е. общие не только для проектов внутри компании), такие модули вполне могут существовать отдельно и использоваться как зависимость, остаётся общее, но специфичное для компании, вероятно это один репозиторий на компанию.
У автора каким-то магическим образом использование монорепозитория решает проблему внесения ломающих изменений в API системы.

Вот допустим, что в случае монорепозитория разработчик обновил весь код репозитория на измененное API. Сборка проходит нормально, тесты тоже. Что мы получим при деплое обновленного приложения? Правильно, всё развалится, если мы не выкатываем ВСЕ приложения синхронно.

Во-вторых, почему вообще внесение ломающих изменений в используемый API рассматривается как норма? Обычно наоборот — если у API появились пользователи, то можно только расширять совместимым образом, но не изменять то, что есть.
А ведь правильно сказали — ответственность во главе угла! Поэтому я за полирепозитории разделенные по ответственности. А иначе получается как правильно отметили — коллективная ответственность, которая быстро скатывается на коллективную безответственность, непрерывные мерж конфликты доходящие до мордобоя (и это не метафора), и потеря управляемости системы через отсутствие спецификаций ее работы. А зачем их писать, код посмотри да? Ну и вишенкой на торте постоянные разборки в стиле коммунальной квартиры кто чей API поломал. ИМХО все что деплоится отдельными артефактами и взаимодействует через «общие» протоколы (REST, очереди, журналы) должно жить в отдельных репо. Единственное где я вижу смысл монорепозитария — это в старом добром JEE REJB
Мне кажется проблема не в монорепозитории, а в системе контроля версий и системе Continuious Testing, которые не могут сами разобраться, что некоторые части кода являются независимыми семантически. В результате каждое изменение в «монорепозиторий» считается задевающим весь код по умолчанию, а вот это какраз и не верно.
С другой стороны, ТРИЗ-овское противоречие тут какое: это должен быть монорепозиторий чтобы отслеживать кросс связи, и это должен быть полирепозиторий, чтобы отдельные компоненты не мешали друг другу.
Как на счет семантической системы контроля версий, которая бы понимала границы семантически независимых частей кода и таким образом разрешала это противоречие?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

1 апреля 2017 г.

Местоположение

Россия

Сайт

otus.ru

Численность

31–50 человек

Дата регистрации

22 марта 2017