Критическое размышление о монорепозиториях и почему это нездоровая инженерная практика

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

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

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

Обращение к крупным техническим властям

Один из самых распространенных аргументов сторонников монорепозиториев — апелляция к авторитету крупных технологических компаний, которые их приняли. Если Google, Facebook и т. д. используют монорепозитории, разве не должны и мы?

Этот аргумент игнорирует уникальные ресурсы и проблемы, с которыми сталкиваются эти компании. Проще говоря, компания с сотнями инженеров (или меньше) вряд ли будет располагать ресурсами производительности разработчиков, необходимыми для масштабирования монорепозиториев.

Например, внутри Google есть инструмент под названием Rosie. -single-repository/fulltext), который помогает управлять процессом просмотра и слияния запросов на вытягивание между командами в монорепозитории. Поскольку такие инструменты, как Rosie, не являются общедоступными, многие команды инженеров на собственном горьком опыте поняли, что у них нет ресурсов для поддержки таких архитектурных шаблонов. Согласно твитам бывшего вице-президента по архитектуре в Monzo (британский стартап онлайн-банкинга), [они столкнулись именно с этой проблемой] (https://twitter.com/obeattie/status/1080496955753750533).

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

Монорепозитории создают тесно связанный код

Отчет Google [DORA State of DevOps Report] (https://www.usehaystack.io/blog/the-accelerate-book-the-four-key-devops-metrics-why-they-matter) состоит из семи лет исследований. и данные от более чем 32 000 профессионалов отрасли в компаниях разного размера. Их исследовательские отчеты в 2021 и 2019 были ясны; Слабосвязанная программная архитектура является одним из самых сильных предикторов успешной непрерывной доставки.

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

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

Нет архитектуры лучше, чем плохая архитектура

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

Закон Конвея — это пословица, которая гласит: «Любая организация, разрабатывающая систему (определяемую в широком смысле), создаст дизайн, структура которого является копией коммуникационной структуры организации».

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

Персонаж Архитектора в фильмах Матрица во многом напоминает мне то, как в конечном итоге ведут себя безответственные архитекторы программного обеспечения. Не задаваясь вопросом, соответствует ли их система результатам того, для чего она была создана, они просто в конечном итоге пытаются построить грандиозные структуры ради нее.

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