Maven + SSDM Автоматизация среды сборки и выполнения

Question

Предисловие:

Моя компания, как и большинство, имеет несколько сред выполнения и несколько версий выпуска, которые сами состоят из разных версий различных jar-файлов.

Например, давайте рассмотримверсии программного обеспечения X, версии 1.1, 1.2 и 1.3, которые могут быть развернуты на компьютере разработчика, тестировании или производстве.

Software-x-1.1 сам по себе состоит из jarA-0.9.1 и jarB-0.7.5, но software-x-1.3 состоит из jarA-1.7.31 и jarB-0.8.1.

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

Мы также используем Maven 2 POM версии 4, чтобы указать, какие версии нашего кода необходимо использовать.Мы помещаем номера версий наших jar-файлов как свойства в профили (dev, test, prod) внутри родительского pom, а затем ссылаемся на эти номера версий во всех poms проекта.

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

-

Вопросы:
Есть лиКакие процедуры / инструменты мы можем использовать для создания нашего продукта, просто предоставив среду выполнения и номер версии?IE "build 1.1 dev"?

Можно ли в любом случае сохранить требуемые версии jar для каждой сборки выпуска?В настоящее время мы создаем версии всех файлов, включая родительский pom, но простое управление версиями родительского pom не записывает, какая версия выпуска имеет отношение к этому родительскому pom.

Что еще мы можем сделать для дальнейшей автоматизации процесса сборок?

Например, если бы мы могли управлять конфигурациями времени выполнения в родительском модуле, это было бы шагом в правильном направлении, но это выглядит как нарушение области действия.

Любой инструмент вненаша структура на данный момент немыслима, но не в далеком будущем.

Резюме:

Как мы можем максимально автоматизировать процесс сборки, не подвергаясь ошибкам?

Answer 1

Если я резюмирую вашу проблему: вы хотите управлять выпуском версий в нескольких средах, и вы выпускаете дистрибутив как совокупность исполняемых файлов (jar), а также свойств сред. Различные версии этих развертываемых развертываний распространяются в разные среды env на разных этапах с собственным набором свойств env, и вы ищете способ общего развертывания (или процесса выпуска) для обработки всего этого.

Похоже, что первая проблема, с которой вы столкнулись, заключается в том, что вы запускаете сборку для каждого выпуска при распространении выпуска. Если я не ошибаюсь, вы должны сначала попытаться взглянуть на архитектуру своего приложения, чтобы увидеть, есть ли способ создать двоичные файлы, не зависящие от среды, в некоторых случаях проекты предпочитают хранить свойства в виде отдельного модуля, который развертывается вместе с jar-файлами, и Что-то вроде диспетчера свойств, который читает файлы, поэтому у вас может быть модуль maven, называемый свойствами, который связывает один zip-файл для каждого набора файлов свойств env. В этом случае сценарию развертывания может быть задан параметр, при котором файл zip извлекается в место, откуда свойства могут быть считаны в приложение. Таким образом, вы получаете то, что «вы создаете один выпуск релиза на релиз, в котором есть содержимое для запуска во всех средах».

Кроме того, так ли это, что вы выпускаете версию "не" той версии, которая у вас есть в POM? если не выровняете свою версию релиза с POM, следует сделать это. то есть POM должен быть 1,3-SNAPSHOT, когда вы работаете над фазой разработки этого выпуска, и быть пониженным до 1,3 в ветке, когда вы выпускаете его.

Не существует единого размера, подходящего для всех решений для таких вещей, но практика, подобная этой, помогает в значительной степени.

PS Дайте мне знать, если я правильно понял вашу проблему, или все закончилось тем, что били по кустам ;-) DS.

Answer 2

Основываясь на части для выпущенных версий 1.1, 1.2 и 1.3 Программного обеспечения X, казалось, что это был правильный способ использовать профили для обработки различий между средами тестирования, производства и т. Д. Само программное обеспечение - это другая история. Я предполагаю, что вы используете инструмент контроля версий (VCT) для хранения состояния вашей разработки. Поэтому во время подготовки Software-x-1.1 вы меняете свой корневой pom и определяете зависимости (jarA-0.9.1, jarB-0.7.5). Сделать тег релиз 1.1. и затем продолжите выпуск 1.2 ... во время разработки выпуска 1.3 вы решили изменить зависимости (на jarA-1.7.31 и jarB-0.8.1), что приведет к изменению только для pom или вашего корневого pom). Может быть, я над вашей реальной проблемой.