Хотите отслеживания артефактов, не отказываясь от классификатора SNAPSHOT

Question

Справочная информация. Моя организация использует Maven, Bamboo и Artifactory для поддержки непрерывного процесса интеграции. Мы полагаемся на спецификатор SNAPSHOT Maven, который помогает управлять хранилищем в Artifactory (отключать старые сборки SNAPSHOT), а также поддерживать актуальность межгрупповых интеграций (Maven проверяет наличие обновлений для зависимостей SNAPSHOT автоматически при каждой сборке).

Проблема. Одна из проблем, с которыми мы сталкиваемся, связана с правильным продвижением сборок из среды в среду при продолжении использования SNAPSHOT. Предположим, что тестер развертывает версию 1.8.2-SNAPSHOT в среде функционального тестирования, а версия Subversion - на 1400-й версии. Скажем также, что он проходит функциональную проверку. К тому времени, когда тестировщик решит вытащить 1.8.2-SNAPSHOT из Artifactory в среду тестирования производительности, разработчик мог бы внести изменения в Subversion, поэтому фактический двоичный файл в Artifactory находится на другом обороте. Как мы можем гарантировать, что версия не изменится из-под нас при использовании сборок SNAPSHOT?

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

Подходы, которые мы рассмотрели. Мысль заключается в том, что мы хотим пометить версии четвертым компонентом, например 1.8.2.1400, где четвертый компонент - это версия Subversion. (В качестве дополнительного вопроса, есть ли плагин Maven или что-то еще, что делает это автоматически?) Но если мы сделаем это, то по сути мы потеряем функцию SNAPSHOT, так как Maven и Artifactory считают, что это разные версии.

Мы используем Scrum, поэтому мы развертываем в тестовых средах очень рано (например, на второй день или около того). Я не думаю, что имеет смысл удалять классификатор SNAPSHOT в начале цикла разработки, потому что мы снова теряем преимущества SNAPSHOT.

Хотелось бы знать, как другие организации решают эту проблему.

Answer 1

Просто, чтобы вернуться к этому, я хотел бы поделиться тем, что мы делаем.

По сути, мы внедряем сборки моментальных снимков, такие как 1.8.2-SNAPSHOT, в среду разработки. Другим командам не нужно использовать эти сборки, поэтому можно оставить на них -SNAPSHOT.

Но любая сборка, которую мы развертываем в тестовой среде (например, функциональный тест, системный тест) или в производственном процессе, должна включать ревизию; например, 1.8.2.1400. Мы называем эти "четверки". Причиной настаивания на тестировании квадов является то, что мы можем прикреплять проблемы (функции, исправления и т. Д.) К конкретным изменениям, чтобы тестировщики знали, что тестировать. Для производства это на самом деле просто потому, что мы хотим развернуть точно такой же артефакт, который мы тестировали, так что это означает, что мы разворачиваем квад.

В любом случае, надеюсь, что информация кому-нибудь пригодится.

Answer 2

Вместо того, чтобы вставлять номер сборки ревизии VCS в версию артефакта, мы встраиваем номер сборки CI в файл META-INF/MANIFEST-MF.

См., Например, Использование переменных среды Hudson для идентификации ваших сборок . Хотя статья применима к Jenkins / Hudson, я считаю, что портировать ее на Bamboo тривиально.

Answer 3

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

и, как примечание, вы можете использовать buildnumber-maven-plugin для добавления номеров сборки subversion к артефактам.