Обновление версий проектов веток Maven, автоматизация рабочего процесса выпуска - PullRequest
7 голосов
/ 30 января 2012

У меня сложный вопрос, связанный с управлением версиями автоматизированных проектов Maven, надеюсь, я найду подходящее решение на основе вашего опыта и советов.

Проблема в следующем: У нас есть огромный Java-продукт, состоящий из 200 различных проектов. Мы договорились, что каждый проект должен разрабатываться независимо, чтобы у каждого из них был свой жизненный цикл. На стадии разработки все работает нормально, проблем нет. Проблема возникает, когда мы готовим релиз для этих проектов: так как очень много проектов, ручные изменения - это боль, поэтому мы решили найти автоматизированное решение для решения процесса выпуска.

Необходимые условия: Мы все согласились, что политика выпуска с точки зрения SVN должна быть такой: - вся разработка должна выполняться на соединительной линии SVN, релизы должны создаваться и поддерживаться на ветках. Каждый исполняемый релиз должен автоматически создавать тег.

Политика с точки зрения MAVEN такова: - перед выпуском проекта мы сначала копируем ствол в ветку, чтобы иметь возможность контролировать ведение проектов в разветвленном коде. Выбранная нами система управления версиями: Major.Minor.BuildNumber-SNAPSHOT (например, 1.0.0-SNAPSHOT) . При переходе кода мы хотим изменить номер версии проекта, увеличив значение MinorVersion (например, trunk-1.0.0-SNAPSHOT станет 1.1.0-SNAPSHOT, а 1.0.0-SNAPSHOT будет скопировать и опубликовать в новой созданной ветке) - когда мы решаем, что проект достаточно зрел, чтобы его можно было выпустить, мы выпускаем его с помощью maven-release-plugin ( mvn release: чистый выпуск: подготовить выпуск: выполнить ) так что версия нашего проекта будет преобразована из Major.Minor.BuildVersion-SNAPSHOT (например, 1.0.0-SNAPSHOT) в Major.Minor.BuildVersion (например, 1.0.0) , затем будет подготовлен для следующей итерации разработки, например: Major.Minor.BuildVersion + 1-SNAPSHOT (например, 1.0.1-SNAPSHOT)

Проблемы, с которыми мы сталкиваемся, связаны с версионностью проектов. Таким образом, на этапе разработки магистральной линии все проекты используют последние версии своих зависимостей SNAPSHOT ( версии mvn: use-latest-version -DallowSnapshots = true -DupdateDependencies = true ), но когда мы Подумайте о том, что пришло время запустить процедуру выпуска и подготовиться к ветвлению кода. Проблемы начинаются: мы начинаем ветвиться

  1. Parent-Pom

    ( mvn -B выпуск: чистый выпуск: branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel . $ {идентификатор_группы}: $ {ProjectID} = 1.0.0-SNAPSHOT -Dproject.dev. $ {GroupId}: $ {projectId} = 1.1.0-SNAPSHOT )

    • копировать проект из транка в новую созданную ветку, преобразовывать версию pom в транке из 1.0.0-SNAPSHOT в 1.1.0-SNAPSHOT
  2. независимые проекты

    ( mvn -B выпуск: чистый выпуск: branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel . $ {идентификатор_группы}: $ {ProjectID} = 1.0.0-SNAPSHOT -Dproject.dev. $ {GroupId}: $ {projectId} = 1.1.0-SNAPSHOT версии: update-parent -DallowSnapshots = истина )

    • копировать проект из ствола в новую созданную ветку,
    • преобразование магистральной версии ПОМ 1.0.0-SNAPSHOT в 1.0.1-SNAPSHOT
    • update parent-pom.version: 1.0.0-SNAPSHOT становится 1.1.0-SNAPSHOT
  3. зависимые проекты:

    ( mvn -B выпуск: чистый выпуск: branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel . $ {идентификатор_группы}: $ {ProjectID} = 1.0.0-SNAPSHOT -Dproject.dev. $ {GroupId}: $ {projectId} = 1.1.0-SNAPSHOT версии: update-parent -DallowSnapshots = true версии: использовать-последние версии -DallowSnapshots = true-DupdateDependencies = true )

    • копировать проект из транка в новую созданную ветку
    • преобразовать версию pom в транке из 1.0.0-SNAPSHOT в 1.1.0-SNAPSHOT
    • обновить parent-pom в транке с 1.0.0-SNAPSHOT до 1.1.0-SNAPSHOT
    • обновить уже разветвленные проекты зависимостей с 1.0.0-SNAPSHOT до 1.1.0-SNAPSHOT

Первая проблема заключается в том, что пока нет способа аргументировать увеличение MinorVersion при ветвлении проекта, плагин maven-release-2.2.2 не увеличивает pom MinorVersionв стволе при ветвлении, поэтому нам нужно использовать -Dproject.rel. $ {groupId}: $ {projectId} = 1.0.0-SNAPSHOT -Dproject.dev. $ {groupId}: $ {projectId} =1.1.0-SNAPSHOT аргументы и изменение их вручную для каждого проекта, так что 200 раз каждый раз, когда мы готовимся к новому выпуску.

Мне интересно, если это не способ сделать все описанные процедурыкак-то в автоматическом режиме и не нужно перфорироватьorm все эти изменения вручную все время.Мы принимаем во внимание даже модульность этого продукта, так что, вероятно, свести эти 200 проектов в 100, но это неприемлемо, поскольку идея состоит в том, чтобы иметь детализированное управление версиями проектов и иметь все проекты со своим собственным жизненным циклом, поэтому агрегатор(Я имею в виду классический) здесь не обсуждается.

Мы используем SVN в качестве VCS, Maven в качестве инструмента для сборки (вероятно, вы уже поняли об этом :)) и Bamboo в качестве CI-сервера (на самом делевместо функции «Maven Dependency Processor» Bamboo мне мало чем помогает в проблеме с версиями).

У вас, ребята, есть идеи, чтобы найти правильное решение для этой проблемы, возможно, другой плагин, которыйпомогло бы (version-maven-plugin не изменяет версии автоматически при переходе), может быть, другая точка зрения для этого, я не знаю ..., любая помощь или предложение приветствуются.

Спасибо!

1 Ответ

0 голосов
/ 25 мая 2012

Я стараюсь не хранить внутренние версии проектов в разделе <properties> родительского модуля, поскольку каждый раз, когда я выпускаю проект, переменная <version>${project.version}</version> будет переключаться с явной версией проекта, например:

<properties>
        <project_A.version>1.0.0-SNAPSHOT</projectA.version>
</properties>

хранится в родительском pom, переводится в pom проектов следующим образом: $ {project.version} , станет 1.0.1-SNAPSHOT при выпуске этого проекта и перезапишет версию <project_A.version> из родительского -пом <properties>. Таким образом, этот прием сохранения версий проектов в качестве свойств в централизованном расположении, подобном parent-pom, действителен до тех пор, пока вы не освободите проекты. Это вопрос, строго связанный с вопросом ветвления.



Теперь, если вы хотите, я могу рассказать вам больше о выпуске проектов с использованием этой замены <properties>: Допустим, вы хотите выпустить свой project_A , что вы будете делать с <projectA.version>, хранящимся в родительском помпе <properties>, который является версией -SNAPSHOT, когда вы начнете выпускать родительского помпа, верно? Я имею в виду, что для того, чтобы выпустить проект, вы сначала освободите все его зависимости и связанные с ними родительские пометки, верно? в противном случае ваш проект не удастся, поскольку он указывает на версию -SNAPSHOT родительского pom. Теперь вы выпускаете parent-pom, сохраняя версию -SNAPSHOT project_A внутри его <properties>, затем, когда вы выпустите project_A , ваш проект будет ссылаться на новая созданная версия вашего родительского pom, версия которого родительского pom ссылается на версию -SNAPSHOT вашего project_A , но это не проблема, так как ваш родительский pom сохраняет истинную версию вашего project_A , пока ваша projectA выпущенная версия (скажем, 1.0.0) не будет ссылаться на ту же версию, выпущенную родительским pom, которая содержит версию 1.0.0-SNAPSHOT вашего project_A , и теперь у вас уже есть проблема, потому что ваш родительский pom <properties> хранит неверную информацию. Конечно, вы можете взломать родительский pom при его выпуске и сохранить версию релиза project_A , но это противоречит правилам, и я бы с этим не согласился, а также другие сценарии, когда этот "взлом" будет вызвать больше проблем, чем помочь.

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

...