Построение непрерывной интеграции - управление версиями

Question

У меня возник вопрос относительно использования номеров версий, версий RELEASE и непрерывной интеграции.

До сих пор в наших сборках мы использовали RELEASE в качестве версии для всех компонентов в каждой сборке.

<dependency>
    <groupId>com.mycompany</groupId>
    <artifactId>mydependency</artifactId>
    <version>RELEASE</version>
</dependency>

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

Если мы перейдем к использованию фиксированных номеров выпусков, мы получим воспроизводимые сборки, но не потеряем преимущество ContinuousИнтеграция говорит нам, что сейчас сломалось?Разве это не точка непрерывной интеграции?

Каков стандартный способ сделать это?

С уважением, D

Answer 1

Прежде всего, планируйте прекратить использование RELEASE. больше не поддерживается в Maven 3 для версий плагинов;Похоже, что ссылки на него были удалены из онлайн-книг о Maven, и я ожидаю, что со временем они будут устаревшими для зависимых версий, если это не так (я не могу найти достоверную информацию, так или иначе).Просмотрите / спросите список рассылки для подтверждения, если вы не уверены в этом.Вы уже освоили сложный способ воспроизводимости сборки.

Во-вторых, я согласен с ответом, что вы обычно захотите определить фиксированные версии для зависимостей ваших проектов, если вы не вносите изменения в несколько проектов одновременно., в этом случае вы хотите версию зависимости SNAPSHOT.Но это должно быть только до тех пор, пока они не будут готовы к выпуску.В этот момент вы должны выпустить нижний уровень, переключить спецификаторы зависимостей на новую фиксированную версию в других проектах и ​​повторять для каждого проекта до завершения.Выпускать новую версию проекта следует только в том случае, если все зависимости являются фиксированными версиями. релиз-плагин может помочь с этим.

В-третьих, все еще может быть очень полезно или интересно узнать, работают ли текущие "подсказки" нескольких проектов вместе, даже если они независимыРасписание релизов!Планирование обратной / прямой совместимости, верно?С большим количеством проектов это становится более важным.Я думаю, что это «непрерывная интеграция», о которой вы говорите (хотя в наши дни CI обычно подразумевает непрерывную сборку и тестирование изменений от нескольких разработчиков, работающих в одной ветви).

В этом случае вы должны создать агрегаторный проект верхнего уровня, который определяет все связанные проекты как модули.Вы можете сделать это в рабочей области, не внося изменений в систему управления версиями, или вы можете создать специализированную ветку для каждого проекта, которая отслеживает основные изменения.В любом случае вы захотите использовать цель version : use-latest-version для автоматизации обновлений POM, или используйте диапазоны версий , чтобы позволить maven выбирать аналогично тому, каквы в настоящее время используете 'RELEASE' (хотя я предпочитаю, чтобы версия была как можно более явной).

(Строго говоря, вам не нужен агрегатор верхнего уровня, но в противном случае вам придется делать это скаждый проект самостоятельно, когда действительно вам интересно, как они работают вместе.)

Answer 2

Существует несколько возможных решений вашей проблемы, наиболее распространенными из которых являются:

1) Вы можете объединить несколько проектов, если они все равно должны построить и сформировать дерево зависимостей, в согласованный набор модулей. Это использует Maven

<modules>
    <module>submodule-A</module>
    <module>submodule-B</module>
</modules>

формат, который является кратким, и это полезно при группировании проектов, которые должны быть все версионированы как группа. Тогда вам просто нужен скрипт, который обновляет номера версий всех дочерних файлов pom.xml до правильной ревизии всякий раз, когда вы делаете релиз (или, мой гораздо менее предпочтительный вариант, используйте maven-release-plugin). Таким образом, каждая часть проекта перемещается и объединяется в одно целое; затем вы можете начать добавление реальных номеров редакций (т. е. 1.3.2).

2) Если вы не можете объединить общие подпроекты в согласованное решение с модулями, следующим лучшим вариантом будет использование SNAPSHOTS. Установив версию в проекте зависимостей что-то вроде:

<project>
    ...
    <artifactId>dependency-A</artifactId>
    <groupId>com.company</groupId>
    <version>1.3.2-SNAPSHOT</version>
    ...
</project>

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

<dependencies>
    ...
    <dependency>
        <artifactId>dependency-A</artifactId>
        <groupId>com.company</groupId>
        <version>1.3.2-SNAPSHOT</version>
    </dependency>
    ...
</dependencies>

или вы можете рассчитывать на более старую версию, чтобы продолжить текущий цикл разработки (т. Е. С использованием 1.3.1), а затем обновить зависимость после выпуска версии 1.3.2.

Эта опция немного сложнее при отслеживании нескольких независимых проектов, но она сохраняет ясность того, что зависит от какой версии, явно в источнике. Это недостаток по сравнению с версиями модулей вместе. С другой стороны, в большинстве систем CI (включая Hudson) в конце раздела конфигурации есть флажок для задания, которое запрашивает «Построить зависимые проекты?» (или что-то типа того). При проверке и запуске в виде сборки maven, когда ваша зависимость SNAPSHOT-A ​​выполняет перестройку, Hudson может автоматически запустить сборку любого проекта, который зависит от зависимости-A. Это может быть очень удобно, если у вас есть общая постоянно обновляемая зависимость.

Answer 3

Если мы перейдем к использованию фиксированной версии числа, мы получаем воспроизводимые сборки, но мы не теряем преимущество Непрерывная интеграция говорит нам, что сейчас сломался? Разве это не точка непрерывной интеграции?

Нет, я не согласен. У каждого проекта, на который есть ссылка, должна быть своя собственная сборка CI, и она должна сообщать о том, что сломано.

Если ваш проект CI является проектом a и имеет зависимость от проекта b, сборка a должна проверять правильность проекта a, а не b. Поэтому единственное, что интересно для Build a, - это то, что Project a работает вместе с указанной версией Project b. (То, что делает самая последняя версия Project b, не имеет значения)