2016-11-05 8 views
0

В моей компании у нас есть команды, работающие над службами, которые создаются с использованием скриптов сборки maven pom и gradle. Проблема заключается в том, что когда команда создает свои веб-приложения, файлы jar, которые создаются одним членом команды, должны быть доступны для других членов команды в своих файлах pom.Рекомендации по хранению артефактов maven в nexus

Мы думали, что мы должны иметь локальное репозиторию nexus, а затем вставлять построенные файлы jar в nexus, чтобы при создании любого другого члена группы они также могли ссылаться на один и тот же файл jar.

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

Что бы я хотел знать, это их наилучшая практика при выполнении этих типов сборок и версий.

ответ

0

Существует много разных мнений и стратегий относительно того, как управлять этим процессом. Однако некоторые аспекты относительно распространены.

Я бы сказал, что есть два ключевых элемента: * Правильное использование определений версий и ссылок * автоматизированная сборка и развертывание связующей

Если у вас есть работа постоянной для конкретного артефакта, для конкретного выпуска, то эти изменения должны входить в определенную нумерованную версию артефакта. Пока работа продолжается, эта версия должна заканчиваться на «-SNAPSHOT». Когда работа над выпуском завершена, этот номер версии должен удалить «-SNAPSHOT». Вероятно, вы также захотите иметь отдельные хранилища на сервере Nexus для «моментальных снимков» и «выпустить» артефакты.

Что касается толкания артефактов к Nexus, это всегда должно выполняться с помощью автоматизации. Ручное нажатие артефактов должно быть очень редким. Когда регулярная сборка выполняется для текущей работы, это должно автоматически развернуть артефакт «-SNAPSHOT» для репозитория моментальных снимков. Когда ваша автоматизация сборки работает «release», эти артефакты будут разворачивать артефакт выпуска в репозиторий выпуска.

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

+0

Спасибо, Дэвид, в то время как разработчик разрабатывает, мы будем использовать локальный сценарий градиента, который будет строить для репозитория nexus. Поэтому, если у нас есть «-SNAPSHOT-» repo, чтобы идентифицировать отдельного разработчика, который мог бы строить тот же банку, было бы неплохо добавить имя разработчика в эту банку. как «-SNAPSHOT-JAMES_E -...»? – IndikaM

+0

Нет, я не вижу в этом никакой ценности. Исходный контроль имеет тождества для изменений, но команда совместно создает двоичные артефакты. –

+0

Хорошо, понял. Спасибо Дэвиду. Обсудите с командой и придумайте процесс вокруг того, что вы упомянули. – IndikaM