• Насколько надулся пузырь зарплат у программистов?
    0
    Вы налоги учли и прочие расходы на рекламу, амортизацию оборудования и проч?
  • Насколько надулся пузырь зарплат у программистов?
    +4
    ну как бы это уже и произошло — это и называется Долина.
    То, что у каждой отдельной деревушки есть свое название — дань традициям
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0

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

  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    Вот, например еще мнение:
    mastodon.technology/@robey/101349183169527275
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    Ну могу немного не согласиться.
    Слышали про twitter.com/monorepi?lang=en — это от Твиттера, у них было 2 монорепозитория :)
    Для справки www.gigamonkeys.com/flowers
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    У нас Typescript + Java :)
    Конфиг хороший — МакБук Про.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    Зачем ее решать, если можно не решать?
    И скорее всего мне нужен весь репозиторий (ведь если он весь собирается одним билд тулом), а не его часть
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    Да не нужно вам ходить по репам, в больших компаниях все равно у каждой команды свой сервис. В лучшем случае вам понадобится ваш репозиторий и, возможно, парочка соседних для интеграционного тестирования.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    Про ум все верно сказано! Это в любом деле так
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    Ха, а мы делаем squash&merge, все ветки на картинке — это временные фича-бранчи :)
    Мастер-то, ясно дело, линейный (почти:)
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    Ну а если Ц — это сторонняя библиотека?
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    В мое время распечатывали исходники в 4х экземплярах и сшивали :)
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +2
    Ну как, копируют в папочку и нарезают на диск :)
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +2
    Думаю, что это может быть связано, но далеко не всегда. Но в оригинальной статье автор говорит о том, что монорепозиторий провоцирует плохую архитектуру и отсутствие декомпозиции.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    В целом вы правы, но при подходе share nithing можно вообще ничего не хранить — каждый сервис содержит свою актуальную swagger-спецификацию, которую клиенты используют и обновляют.
    Я хочу отметить, что если разговор о больших компаниях, то чаще всего отдельные сервисы разрабатываются отдельными командами. Поэтому все равно, если вы решите изменить API своего сервиса, вы не сможете переписать код всех клиентов, просто потому, что вы его не знаете и не владеете им. Поэтому, вы просто сообщаете другим командам, что у вас появились новые методы в API, но оставляете старые как deprecated.
    А вообще ещё лучше делать все изменения обратно совместимыми. Если у вас API публичный, вы не владеете кодом клиентов и не можете заставить их его обновить, у вас собственно и нет других вариантов.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    Это правда, в этом и проблема, что такие инструменты как GitHub предназначены прежде всего для маленьких команд, коих сейчас огромное число. И так почти со всеми инструментами. И это неспроста — это диктует рынок.
  • Монорепозитории: пожалуйста не надо
    0
    А зачем???
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    В случае же кучи микрорепозиториев вы обрекаете себе на ад микроменеджмента зависимостей между ними.

    Я работал в парадигме share-nothing, там такой проблемы нет совсем. Т.к. зависимостей между микросервисами нет. А если сервисы тесно связаны, их нужно хранить вместе.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    если есть внешние подрядчики

    Это тоже хороший аргумент, хотя я бы не стал внешним подрядчикам давать доступ в любой репозиторий, пусть заведут отдельный и оттуда делают патчи.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    Никто не утверждает, что в репозитории должен лежать ровно один микросервис и все. В мою бытность использования полирепозиториев мы прекрасно складывали семейство тесно связанных микросервисов в один репозиторий.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +2
    Ну так maven делает такой резолв версий зависимостей уже примерно лет 100. Причем политику можно задать, или для конкретной библиотеки разрулить руками и зафиксировать версию.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    0
    Ну есть ещё софт, который работает 5*8 и обновляется по выходным с даунтаймом.
    Это не отменяет того, что я написал, что специфика вашего деплоя такова, что не накладывает на это ограничений. Что же, вам повезло, для вас этот недостаток неактуален.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    А как вы в монорепе сделаете, чтобы А и Б зависели от разных версий Ц? Точнее, вы сделаете, только непонятно, чем тут монорепозиторий помогает? Будет ровно такой же конфликт транзитивных зависимостей, который нужно решать.
    Тем, что он вам не позволит в библиотеках А и Б завязаться на разные версии Ц? Да позволит, куда денется. И точно также вы узнаете об этом в самый последний момент.
  • Монорепозитории: пожалуйста не надо
    +1
    Проблема в том, что когда проблемы начинают себя проявлять, разделить монорепозиторий уже скорее всего не получится по техническим, но прежде всего по идеологическим причинам (это будет выглядеть революцией по сравнению с накручиванием нового тулинга вокруг старого подхода). Именно с этой проблемой я столкнулся в своей текущей компании — проблемы видят все, но считают, что бороться надо с помощью инструментов
  • Монорепозитории: пожалуйста не надо
    0
    > Это зависит не от количества людей, а от сложности проекта.

    И от количества людей тоже (мало людей не смогут нагенерировать поток коммитов и создать проблемный размер для репозитория), так что если 2-3 человека, то основные проблемы монорепозитория не очень проявляют себя.

    > Одно из преимуществ, которое мне нравится — подмодули заставляют тебя так декомпозировать код,

    Это указано в статье, тоже считаю это преимуществом

    > Ещё одно преимещуство — это пакетирование.

    вот тут не вижу взаимосвязи с моно- или полирепозиторием, мы в своем монорепозитории собираем отдельные пакеты для каждого микросервиса под разные платформы, работало и на maven, работает и на bazel

    > Ещё одно преимущество — можно делать глобальный рефакторинг не по всему проекту сразу, а частями через подмодули

    ну прямо скажем, в монорепозитории тоже так можно. Даже более того, (об этом сказано в статье) другого варианта у вас нет даже в монорепозитории из-за неатомарности деплоя.
  • Монорепозитории: пожалуйста не надо
    0
    А как вы собираетесь деплоить эти связанные изменения?
    Я бы сказал, что если у вас есть сильная связь между репозитоиями, вы неправильно определили границы.
    Если все же границы определены верно, то не нужно писать этот код вместе — добавьте изменения в первый репозиторий, задеплойте его, потом добавьте во второй — задеплойте его.
  • Монорепозитории: пожалуйста не надо
    +1
    Именно это и говорится в статье — есть ровно 20+- компаний в мире, которые умеют в монорепо. Это гугл, фейсбук, твиттер, яндекс, может быть, кто-то еще.
    Остальным не надо даже пытаться, т.к. правильных инструментов у вас нет, как и ресурсов на их создание.
  • Монорепозитории: пожалуйста не надо
    +2
    Не поверите, но нет :)
    Это не ноды одного кластера, а независимые подсистемы
    В подробности вдаваться не буду, просто поверьте на слово ;)
  • Монорепозитории: пожалуйста не надо
    0
    Для решения такой проблемы монорепощиторщики придумали свой тулинг :) называется мерджбот
    Например prow от Goggle bentheelder.io/posts/prow или сервис mergify.io
  • Монорепозитории: пожалуйста не надо
    +1
    Проблема со всеми этими проектами описана в статье.
    Все они обладают очень сильной привязкой к специфике кодовой базы разработчика. Их просто невероятно сложно начать использовать. Говорю это, как человек, переведший монорепозиторий с мавена на bazel
  • Монорепозитории: пожалуйста не надо
    0
    Git Virtual File System en.wikipedia.org/wiki/Git_Virtual_File_System
    Это к вопросу о том, где хранятся исходники Windows
  • Монорепозитории: пожалуйста не надо
    0
    Что вы имеете в виду? Все исходники Windows хранятся в Гит, также как и ядро Linux.
  • Монорепозитории: пожалуйста не надо
    0
    Ну говорят, что Яндекс его и использует для своего монорепо в Поиске
  • Монорепозитории: пожалуйста не надо
    0
    По сути автор говорит именно об этом, но суть в том, что подход с монорепозиторием на определенном масштабе начинает добавлять проблем с производительностью VCS и не только, которые нужно как-то решать. Гугл может себе позволить иметь сотни разработчиков, работающих годами над этими проблемами. Может ли ваша компания?
  • Монорепозитории: пожалуйста не надо
    0

    Вы абсолютно правы :)

  • Монорепозитории: пожалуйста не надо
    0

    Частично да, но иногда, к сожалению, нужно протестировать интеграционные сценарии. А что того хуже, иногда их нужно ещё и продебажить. Так что хорошо иметь возможность запустить хотя бы часть системы (несколько сервисов, в зависимости от воспроизводимого сценария) локально из IDE в дебаг режиме

  • Монорепозитории: пожалуйста не надо
    +8

    Ну в статье и говорится не об одном разработчике, а о проекте с 100+ разработчиками.
    Могу сказать по своему опыту, про темы совсем невыдуманные. Особенно в части того, что некоторые компании бездумно копируют практики.
    В данный момент у нас 200+ инженеров работают над монорепозиторием. Более 100 коммитов в день, билд на CI занимает около 40 минут. Клонирование репозитория с Гитхаба (учитывая поганый Австралийский интернет) занимает больше 10 минут.
    Я уж не говорю про индекс в Идее

  • Монорепозитории: пожалуйста не надо
    0

    Проблема с сабмодули, что они ссылаются на конкретный коммит. Таким образом, держать такой репозиторий в актуальном состоянии довольно трудно. Можно, конечно, автоматизировать, чтобы всегда вытягивать, например, свежие релизные версии… Но не очень понятно, какую проблему это решает. Если хочется запускать полностью всю систему локально, то проще залить артифакты в registry/bintray/куда-то ещё и точно также запустить docker-compose

  • Монорепозитории: пожалуйста не надо
    +9

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

  • Монорепозитории: пожалуйста не надо
    +1

    Сабмодули можно использовать как раз для создания надрепозитрия (или мета-репозитория) вокруг нескольких независимых полиреп. В него можно положить compose для запуска всего проекта целиком как alexesDev любит