Альтернатива процессу Maven Release

Проблема:20 различных JAVA-проектов с множеством взаимозависимостей. Каждый раз, когда после блокировки кода происходит исправление ошибки, мы должны выпустить несколько артефактов по мере необходимости в зависимости от того, какой артефакт был изменен. Например, если артефакт 3 имел разблокировку и нуждался в исправлении ошибки, нам нужно выпустить (используя плагин релиза maven) проекты 3,4,5,6,7 и 10 (потому что 4,5,6,7 и 10 зависит от 3). Координация между командами для выполнения этой задачи требует времени. Плюс сборка каждого артефакта занимает добрых 20-40 мин.

Мы хотим сократить этот процесс. Мы думаем о следующем:

  1. Используйте снимки для артефактов с отметками времени
  2. Продвигайте отдельные артефакты в хранилище, используя задания jenkins и тег svn.
  3. Обновите зависимости, используя команду 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, которые могут обрабатывать зависимости, или вы можете рассмотреть возможность использования плагина конвейера сборки для обработки таких вещей.

Но у меня возникает еще один вопрос: почему ваши сборки так долго? Вы можете выяснить, почему они так долго занимаются, и сократить время выпуска.

Другие вопросы по тегам