Требуется прослеживаемость артефактов без отказа от квалификатора моментального снимка
фон. моя организация использует Maven, Bamboo и Artifactory для поддержки непрерывного процесса интеграции. Мы полагаемся на квалификатор моментальных снимков Maven, чтобы помочь управлять хранилищем в Artifactory (поворачивать старые сборки моментальных снимков), а также поддерживать текущую интеграцию между командами (Maven проверяет наличие обновлений зависимостей моментальных снимков автоматически для каждой сборки).
проблема. одна из проблем, с которой мы сталкиваемся, - это правильное продвижение сборок из среда к среде, продолжая использовать SNAPSHOT. Скажем, тестер развертывает версию 1.8.2-SNAPSHOT в функциональной тестовой среде, и она находится в rev 1400 в Subversion. Допустим также, что он проходит функциональный тест. К тому времени, когда тестер решает вытащить 1.8.2-SNAPSHOT из Artifactory в среду тестирования производительности, разработчик мог бы внести изменения в Subversion, поэтому фактический двоичный файл в Artifactory находится в другом REV. как мы гарантируем, что rev не изменится из-под нас при использовании SNAPSHOT builds?
ограничения. мы, очевидно, не хотим развертывать разные сборки неосознанно. Мы также не хотим перестраивать из источника, поскольку мы хотим проверить точный двоичный файл в тесте производительности, который мы тестировали в функциональном тесте.
подходы, которые мы рассмотрели. мысль в том, что мы хотим отметить версии с четвертым компонентом, например 1.8.2.1400, где четвертый компонент является Subversion REV. (как боковой вопрос, есть ли плагин Maven или что-то еще, что делает это автоматически?) Но если мы это сделаем, то по существу мы потеряем функцию моментального снимка, так как Maven и Artifactory думают, что это разные версии.
мы используем Scrum, поэтому мы развертываем в тестовых средах очень рано (например, день два или около того). Я не думаю, что имеет смысл удалять квалификатор моментального снимка в начале цикла разработки, потому что мы снова теряем преимущества моментального снимка.
был бы признателен зная, как другие orgs решить эту проблему.
3 ответов
просто чтобы вернуться к этому, я хотел поделиться тем, что мы делаем.
в основном мы развертываем сборки моментальных снимков, такие как 1.8.2-SNAPSHOT, в среду разработки. Другим командам не нужно использовать эти сборки,поэтому можно оставить снимок на них.
но любая сборка, которую мы развертываем в тестовой среде (например, функциональный тест, системный тест) или другое производство, должна включать ревизию; например, 1.8.2.1400. Мы называем их "квадроциклами". Причина настаивания на квадроциклах в тесте мы можем прикрепить проблемы (функции, исправления ошибок и т. д.) к конкретным изменениям, чтобы тестировщики знали, что тестировать. Для производства это просто потому, что мы хотим развернуть точно такой же артефакт, который мы тестировали, так что это означает, что мы развертываем quad.
в любом случае надеюсь, что информация кому-то полезна.
Если вы включите" uniqueVersion " для сборки моментальных снимков, каждый развернутый моментальный снимок будет иметь уникальный идентификатор. это можно использовать для обеспечения правильного развертывания сборок promote в различных средах.
и, в качестве примечания, вы можете использовать buildnumber-maven-plugin для добавления Subversion buildnumbers к артефактам.
вместо того, чтобы вставлять номер сборки версии VCS в версию артефакта, мы вставляем номер сборки CI в .
см., например,использование переменных среды Hudson для идентификации ваших сборок . Хотя статья применима к Дженкинсу / Хадсону, я считаю, что тривиально переносить на бамбук.