maven: развернуть зависимости в альтернативном хранилище - PullRequest
Новая
       5

maven: развернуть зависимости в альтернативном хранилище

2 голосов
/ 14 декабря 2011

Я пытаюсь сделать что-то вроде настройки продвижения сборки с нашей сборкой maven.Я делаю это сам, потому что менеджеры репозитория, которые я нашел, не совсем соответствуют требованиям.

Я хочу, чтобы процесс работал следующим образом:
1. При разработке файлы ear и jar используются в репозитории dev.
2. Команда сборки запускает сборку, чтобы получить этот файл, добавляет шаблоны конфигурации, определенные для обеспечения качества, упаковывает результат в zip-файл
3. Используя опцию <altDeploymentRepository>, команда сборки развертывает файл zip наРепозиторий QA
4. Разверните зависимые файлы ear и jar в репозиторий QA 5. После завершения цикла QA команда по сборке запускает сборку для загрузки (теперь протестированных) файлов jar и ear, добавляя шаблоны предварительной настройки для preprod,и упаковывает результат в zip-файл
6. Используя опцию <altDeploymentRepository>, команда по сборке развертывает zip-файл в репозиторий Preprod
... и повторяет процесс снова для развертывания в рабочем режиме

Все отлично работает до шага 4. Похоже, нет способа сказать maven развернуть зависимости на всехternate location.

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

Переключение исходного и целевого репозиториев выполняется через профиль maven: 

<profile>
  <id>qa</id>
  <distributionManagement>
    <repository>
      <id>prddeploy</id>
      <name>build server repository</name>
      <url>${repoHost}/dev_repo</url>
    </repository>
  </distributionManagement>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-deploy-plugin</artifactId>
        <configuration>
         <altDeploymentRepository>qadeploy::default::${repoHost}/qa_repo</altDeploymentRepository>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

Где профиль 'dev' является значением по умолчанию, поэтому разработка не требует специальных шаговони просто бегут mvn deploy.Команда сборки запускает: mvn deploy -P qa, чтобы запустить цикл развертывания qa.

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

Я знаю, что nexus предлагает функцию продвижения сборки в своей профессиональной версии, но на основании документации ключевым моментом является то, что поэтапные репозитории должны быть closed, прежде чем их можно будет использовать.Наше программное обеспечение имеет множество различных компонентов, и при исправлении ошибки в QA нам необходимо иметь возможность повторно развертывать только измененные компоненты, а не всю систему.Постановочная установка хранилища Nexus, похоже, не позволяет этого.Если я читаю это неправильно, кто-нибудь, пожалуйста, направьте меня в правильном направлении.

1 Ответ

0 голосов
/ 16 декабря 2011

Вам следует пересмотреть, почему комплект Nexus Pro , по-видимому, ограничивает вас.

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

Я бы порекомендовал одно из следующих решений:

  • Вырезать меньшую версию патча, разработанную для применения поверх текущей версии в QA.
  • Если ваши компоненты полностью отделены друг от друга, рассмотрите возможность их выпуска в качестве компонентов с независимой версией.

Обновление

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

...