Альтернатива процессу Maven Release
Проблема:20 различных JAVA-проектов с множеством взаимозависимостей. Каждый раз, когда после блокировки кода происходит исправление ошибки, мы должны выпустить несколько артефактов по мере необходимости в зависимости от того, какой артефакт был изменен. Например, если артефакт 3 имел разблокировку и нуждался в исправлении ошибки, нам нужно выпустить (используя плагин релиза maven) проекты 3,4,5,6,7 и 10 (потому что 4,5,6,7 и 10 зависит от 3). Координация между командами для выполнения этой задачи требует времени. Плюс сборка каждого артефакта занимает добрых 20-40 мин.
Мы хотим сократить этот процесс. Мы думаем о следующем:
- Используйте снимки для артефактов с отметками времени
- Продвигайте отдельные артефакты в хранилище, используя задания jenkins и тег svn.
- Обновите зависимости, используя команду mvn version:set для каждого проекта, который нуждается в зависимости.
Кто-нибудь реализовал решение, подобное описанному выше? Если да, то с какими проблемами вы столкнулись?
Любые другие предложения, которые не восстановят артефакты и позволят нам выпустить 15-20 артефактов одним нажатием кнопки, будут полезны:)
1 ответ
К сожалению, вы должны восстановить свой артефакт, если вы измените файл pom. В противном случае ваше состояние в вашей системе VCS не соответствует состоянию, с которым вы работаете.
Давайте сделаем пример. Проект A, проект B, где B зависит от A:
Проект А: pom.xml
<version>1.0-SNAPSHOT</version>
Some dependencies etc.
Проект Б: pom.xml
<version>1.0-SNAPSHOT</version>
Some dependencies etc.
<dependency>
<groupId>project.a</groupId>
<artifactId>A</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
Теперь вы строите проекты A и B. Состояние в вашем репозитории представляет состояния файлов pom с их состоянием / зависимостями от SNAPSHOT.
Теперь вы измените "Проект А", чтобы "освободить" от него, но не восстановите свой артефакт. Чем ниже в вашем контроле версий и, возможно, вы делаете его пометки.
Проект А: pom.xml
<version>1.0</version>
Some dependencies etc.
Во-вторых, вы делаете то же самое с Проектом B: Проект B: pom.xml
<version>1.0</version>
Some dependencies etc.
<dependency>
<groupId>project.a</groupId>
<artifactId>A</artifactId>
<version>1.0</version>
</dependency>
Но вы также не восстанавливаете свой артефакт. В результате ваш репозиторий содержит артефакты, которые представляют состояние SNAPSHOT, но ваш контроль версий говорит что-то другое. Это только очень простой пример проблемы. Если у вас будет больше проектов и т. Д., Тем хуже станет.
Кроме того, я бы не стал думать об изменении структуры проекта, потому что, исходя из того, что вы написали о зависимостях, похоже, что эти проекты должны быть выпущены вместе, поэтому было бы неплохо создать из них многомодульную сборку.
Кроме того, восстановление может быть выполнено с помощью соответствующих заданий в Jenkins, которые могут обрабатывать зависимости, или вы можете рассмотреть возможность использования плагина конвейера сборки для обработки таких вещей.
Но у меня возникает еще один вопрос: почему ваши сборки так долго? Вы можете выяснить, почему они так долго занимаются, и сократить время выпуска.