Работа с maven и несколькими git-репозиториями - уменьшает боль - PullRequest
0 голосов
/ 11 октября 2018

Мы недавно мигрировали из SVN с большим количеством кода в одном репо в git, с большинством проектов в собственных репо (около 70 из них).Мы создаем около десятка различных приложений из этого Java-источника.Все приложения работают на * nix серверах.Мы используем Maven и Nexus для сборки.Многие из нас борются с разработкой функций, когда эта функция затрагивает более одного репо.Вот несколько трудностей:

  • Разработчик должен разветвлять каждое хранилище отдельно - мы используем одно и то же имя для всех веток для одной функции, чтобы сделать отслеживание менее трудным.

  • Нужно обновить poms всех репо, чтобы они указывали на обновленные версии артефакта каждого репо.Если над одной и той же веткой работают несколько человек, может произойти объединение других изменений.Когда я фиксирую изменение в репо, то артефакт переименовывается в «-SNAPSHOT», что означает большее количество обновлений pom.

  • Изменения необходимо вводить в правильном порядке или наши автоматические сборкипотерпит неудачу, например: репо A зависит от изменения репо B;если репо А передано до того, как репо В будет создано и развернуто, то репо А не будет построено.

  • Лицо, рассматривающее функцию, должно посмотреть на изменения в нескольких репо.

  • Когда функция объединяется из ее ветви, скажем, в мастер, нужно помнить все репо, которые были затронуты.

Это похоже на переключениеподход, в основном, монорепо, может быть лучшим, но есть некоторые недостатки:

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

  • Каждый толчок запускает большой набор сборок и множество модульных тестов.чем просто создание и тестирование артефакта одного репо.

  • Разработчики, которые обычно работают в одном или двух репо, предпочитают этот новый мир мульти-репо и будут сопротивляться изменению обратно.

Я изучил подмодули и поддеревья git, которые, похоже, не решают многие из наших проблем (Не уверен насчет Google Repo).Некоторые из нас используют такие инструменты, как «му», чтобы помочь.Было бы здорово, если бы существовал инструментарий, который помог бы разработчикам поддерживать версии в poms и отслеживать изменения в репозиториях.

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

1 Ответ

0 голосов
/ 11 октября 2018

с большинством проектов в своих собственных репозиториях (около 70 из них) .`

Для меня это то, с чего начинаются проблемы.Мой голос состоит в том, чтобы значительно уменьшить это число.

Если вы действительно не хотите одного репо (1 репо получает мой голос), вы можете разделить кодовую базу на n * change_often репо с 1 * change_rarely репо.Держать русский маленький.Таким образом, вы избежали бы перестройки битов, которые меняются редко.

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

...