Здравствуйте, SkyDance, Вы писали:
S>>Например? SD>У каждой компании свой колхоз. Почти всегда этот колхоз работает только на жестко контролируемой виртуалке, на которой, собственно, и ведется разработка. Компьютеры, которые дают сотрудникаам, очень часто есть просто монитор для терминала этого сервера. Вся разработка — удаленно.
1) Имел в виду пример вот этого -- "Распределенные кэширующие билд-системы"?
2)А у вас в фб также, т.е. термнал дают?
S>1) Имел в виду пример вот этого -- "Распределенные кэширующие билд-системы"?
Bazel, buck, прочие аналоги. Сами по себе инструменты простейшие, сложность живет в том, чтобы их хоть как-то надежно использовать.
Идея очень простая: есть большое хранилище, где лежат ответы на вопросы "дай мне скомпилированный файл с таким-то хешом". В твоем репо ты меняешь 1-2 файла, компилируешь только их, остальные миллионы просто скачиваются в готовом виде из того хранилища. После того как ты скомпилировал свои 1-2 файла, результат компиляции складывается туда же, в хранилище (его зовут CAS, content addressable storage).
По сути это получается этакая мемоизация всех компиляций. Хорошо работает для тормозных компиляторов типа С++. Плохо работает для быстрых, типа Erlang, где скомпилировать бывает быстрее, чем вытащить по сети.
Здравствуйте, vsb, Вы писали:
vsb>В том, что нет возни с версиями, версия всегда ровно одна — последняя.
Это уже не просто про репы. Это, буквально, означает возможность только больших релизов всего сразу. С такими идеями во многих конторах тебя сразу пошлют, без разговоров.
M>>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного. vsb>Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю.
Это у гугла то с его любовью к микросервисам получается огромный реп?
Здравствуйте, Miroff, Вы писали:
M>Я не встречал чтобы из идеи разделять общий код между командами хоть раз вышло что-нибудь хорошее.
Это отличное решение при условии что тебе не нужны независимые релизы отдельных частей. Потому что раскидывание по репам это дорого, очень дорого и для программеров и для девопсов.
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>В том, что нет возни с версиями, версия всегда ровно одна — последняя.
НС>Это уже не просто про репы. Это, буквально, означает возможность только больших релизов всего сразу. С такими идеями во многих конторах тебя сразу пошлют, без разговоров.
Релизы делаются постоянно и непрерывно. Что закоммитил в главную ветку, то ушло на релиз. Конечно со всякими фич-флагами, канарейками и тд.
M>>>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного. vsb>>Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю.
НС>Это у гугла то с его любовью к микросервисам получается огромный реп?
Здравствуйте, vsb, Вы писали:
НС>>Это уже не просто про репы. Это, буквально, означает возможность только больших релизов всего сразу. С такими идеями во многих конторах тебя сразу пошлют, без разговоров. vsb>Релизы делаются постоянно и непрерывно.
Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком.
НС>>Это у гугла то с его любовью к микросервисам получается огромный реп? vsb>Да.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком.
А что мешает?
НС> НС>>Это у гугла то с его любовью к микросервисам получается огромный реп? НС> vsb>Да. НС> Нет.
Здравствуйте, Anton Batenev, Вы писали:
НС>> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком. AB>А что мешает?
Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> НС>> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком. НС> AB>А что мешает? НС> Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Не, это про маркетинг. Технически в монорепозитории ничего не мешает собирать и выпускать продукт с отсутствующей фитчей хоть по 100 раз в день. Конкретный feature set сборки может определяться как в compile так и в runtime — с этим обычно ни у кого не возникает сложностей.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> AB>Не, это про маркетинг. НС> Не, это не про маркетинг, а про product management.
Да без разницы как это называть — к техническим аспектам сборки релиза/билда из кодовой базы в любой конфигурации репозиториев это не имеет никакого отношения.
Здравствуйте, Anton Batenev, Вы писали:
AB>Да без разницы как это называть — к техническим аспектам сборки релиза/билда из кодовой базы в любой конфигурации репозиториев это не имеет никакого отношения.
Крайне важно, чтобы у общего компонента был ответственный.
1) Это может быть команда. Например, в одной компании у нас все общие модули были поделены между командами: каждая команда отвечала за 1 или несколько общих компонентов. Соответственно, мержи/фиксы проверяются этой командой, либо же новые фичи/фиксы реквестятся у этой команды.
2) Можно назначить конкретного одного человека мейнтейнером 1 компонента. Обычно в компании есть люди, которые хотят больше ответственности/больше зп/апнуть левел/стать тим-лидом и прочее. Вот тут и можно совместить: дать человеку порулить и отвечать за небольшой кусок, а там и опыта наберется, и понятно будет, тянет или нет (например, на сеньора), а то и глади вокруг него сформируется команда и будет тим-лидить, и компонент поддерживаемый будет.
А как этот компонент будет встраиваться в другие — это зависит от множества факторов: у кого-то SVN; у кого-то монорепа; у кого-то микросервисы; где-то плюсовые компоненты; где-то все в докерах. Важно, в любом случае, иметь API, поддерживать его в рабочем состоянии, не ломать его, обновлять доку, ну и прочие подобные вещи. Как, собсно, и у внешнего продукта. Только в данном случае клиенты — твои коллеги.
Здравствуйте, Miroff, Вы писали:
M> Единственное, хоть сколько-то разумное решение это выделить общий код в отдельный продукт с собственным циклом релизов и собственными разработчиками.
Обычно это первый шаг к провалу. Команда, которая занимается общим кодом очень быстро перестает понимать за чем этот общий код нужен, и улетает в космос от реальных проблем. Правильно расставить приоритеты по фичам такая команда тоже не может, у нее просто данных нет.
В такой ситуации спасает либо "inner source" — у общего сервиса есть владелец от бизнеса, но остальные могут в него контрибутить, если горит. Но только через пул-реквесты и ревъю изменений от владельца. Либо менеджерская обвязка у такой команды в виде матерого продакта, програм-менеджера и прочих людей, которые приносят понимание за чем этот продукт нужен, и выравнивают его по реальным бизнес-требованиям. На практике, второй вариант требует особенной дисциплины от всех участников и в живой природе встречается довольно редко.
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Так это ж они как раз и рассказывали про дерево репозиториев, в котором от коммита в ядро новых фич шатдауна винды до возможности использовать их в меню кнопочки Start проходило три месяца.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Anton Batenev, Вы писали:
M>> Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск. AB>Его чекаутят или селективно (нужное подмножество директорий) или лениво (подгружая / кэшируя по мере необходимости).
И этим вся идея монорепы в принципе устраняется — каждый работает над своим субкомпонентом.
AB>Не очень понятно почему не можешь. Зависимость по исходникам (вместо зависимости по артефактам) — твой код собирается с текущей версией исходного кода другого проекта.
Что точно так же можно сделать и по нескольким репам. Всё равно из полного терабайта (чуть-чуть утрирую) исходников выбирается только подмножество.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Anton Batenev, Вы писали:
НС>>> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком. AB>>А что мешает?
НС>Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Это проблема исключительно МС и feature-based подхода.
С их маркетингом, да, нужно, чтобы выходил полностью новый продукт со 100500 новшествами, а не раз в неделю по 2-3 новым фичам. Но далеко не у всех такие проблемы.
Здравствуйте, SkyDance, Вы писали:
R>>В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями
SD>Без шансов, можно даже не пытаться. Слишком сложно научить среднего разработчика.
Что сложного в задаче добавить пару строк определённого формата в исходник и пару строк в linker script?
SD> И в тестировании тот еще ад.
Здравствуйте, Barbar1an, Вы писали:
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится?
В яндексе — монорепка на всё-всё-всё. Система версионирования там какая-то своя, что-то вроде на базе SVN, как я понял. Система сборки — тоже своя
N>Что сложного в задаче добавить пару строк определённого формата в исходник и пару строк в linker script?
Речь не о linker script, а о том, что в современном мире код обычно очень распределенный. То есть библиотека часто попросту делает вызов к сетевому сервису, который уже что-то там делает. Почему так? Потому что это позволяет владельцу библиотеки сохранять полный контроль, и выкатывать изменения без каких-либо действий с твоей стороны.
Обеспечивать совместимость — очень трудно.
N>Чем? Есть тест на новую версию и тест на старую.
Это и называется ад, когда у тебя 100 старых версий, и надо поддерживать совместимость всего со всем. Я поддерживал некоторое количество open source библиотек, которые должны были работать с разными версиями компилятора, и разными версиями билд-тула. Геморрой был тот еще. Спасениям явилось включение этих библиотек в стандартную библиотеку языка (хотя и это прошло не без проблем, все еще мне аукается).
Мы уже победили, просто это еще не так заметно...
