Предыстория: мой основной бэкграунд - Java бэкенд. В какой-то момент стала интересна Scala. Я поработал около года в маленьком стартапе, где мы переписывали бэкенд с Python на Scala. Затем через некоторое время я начал искать варианты с переездом в цивилизованные страны и получил 4-5 офферов на Scala в нескольких Европейских странах и 1 оффер на Java… Так я оказался в Австралии. И без Scala.
Сложно сказать, почему я сделал такой выбор, но естественно через некоторое время я задумался, а не стоит ли попытаться воплотить свою мечту и все же найти компанию, которая бы использовала Scala не только для Data-Science, но и для разработки бэкенда.
В общем, открыл я ЛинкедИн в надежде посмотреть и повыбирать вакансии, и был просто шокирован...
Итак, новая порция обещанного холивара про монорепозитории. В первой части мы обсуждали перевод статьи уважаемого инженера из Lyft (и ранее Twitter) о том, какие есть недостатки у монорепозиториев и почему они нивелируют почти все достоинства этого подхода. Лично я во многом согласен с доводами, приведенными в оригинальной статье. Но, как и обещал, чтобы поставить точку в этом обсуждении, я бы хотел озвучить еще несколько моментов, на мой взгляд даже более важных и более практических.
От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.
Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.
В данном посте я буду называть такой подход «полирепозиторий».
