Maven + SSDM Автоматизация среды сборки и выполнения
Предисловие:
У моей компании, как и у большинства, есть несколько сред выполнения и несколько версий выпуска, которые сами состоят из разных версий различных jar-файлов.
Например, давайте рассмотрим версии 1.1, 1.2 и 1.3 Программного обеспечения X, которые могут быть развернуты на компьютере разработчика, тестировании или производстве.
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 version 4, чтобы указать, какие версии нашего кода необходимо использовать. Мы помещаем номера версий наших jar-файлов как свойства в профили (dev, test, prod) внутри родительского pom, а затем ссылаемся на эти номера версий во всех poms проекта.
На данный момент у нас нет возможности указать, какие версии проекта относятся к данному выпуску, кроме самой последней. Кроме того, мы развертываем наши конфигурации во время выполнения для датчика SSDM, который затем настраивает и создает службы, определенные встроенными версиями нашего программного обеспечения.
-
Вопросы:
Есть ли какая-либо процедура / инструмент, который мы можем использовать для создания нашего продукта, просто предоставив среду выполнения и номер версии? IE "построить 1.1 dev"?
Есть ли в любом случае мы можем хранить необходимые версии JAR для каждой сборки выпуска? В настоящее время мы создаем версии всех файлов, включая родительский pom, но простое управление версиями родительского pom не записывает, какая версия выпуска имеет отношение к этому родительскому pom.
Что еще мы можем сделать для дальнейшей автоматизации процесса сборки?
Например, если бы мы могли управлять конфигурациями во время выполнения в родительском pom, это было бы шагом в правильном направлении, но это выглядит как нарушение области действия.
Любой инструмент за пределами нашей структуры немыслим на данный момент, но не в далеком будущем.
Резюме:
Как мы можем автоматизировать процесс сборки в полной мере, не подвергаясь ошибкам?
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). Может быть, я над вашей реальной проблемой.
Если я резюмирую вашу проблему: вы хотите управлять выпуском версий в нескольких средах, и вы выпускаете дистрибутив как совокупность исполняемых файлов (jars), а также свойств сред. Различные версии этих развертываемых развертываний распространяются в разные среды env на разных этапах с собственным набором свойств env, и вы ищете способ общего развертывания (или может быть процесса выпуска) для обработки всего этого.
Похоже, что первая проблема, с которой вы столкнулись, заключается в том, что вы запускаете сборку для каждого релиза при распространении релиза. Если я не ошибаюсь, сначала попробуйте взглянуть на архитектуру своего приложения, чтобы увидеть, есть ли способ создания двоичных файлов, не зависящих от среды, в некоторых случаях проекты предпочитают хранить свойства в виде отдельного модуля, который развертывается вместе с jar-файлами, и Что-то вроде диспетчера свойств, который читает файлы, поэтому у вас может быть модуль maven, называемый свойствами, который связывает один zip-файл для каждого набора файлов свойств env. В этом случае сценарию развертывания может быть задан параметр, при котором файл zip извлекается в место, откуда свойства могут быть считаны в приложение. Таким образом, вы получаете "один дистрибутив выпуска на каждый релиз, в котором есть содержимое для запуска во всех средах".
Кроме того, так ли это, что вы выпускаете версию, которая "не" является версией, которая у вас есть в POM? если не выровняете свою версию релиза с POM, следует сделать это. т. е. POM должен быть равен 1,3-SNAPSHOT, когда вы работаете на этапе разработки этого выпуска, и быть пониженным до 1,3 в ветви, когда вы выпускаете его.
Не существует единого размера, подходящего для всех решений для таких вещей, но практика, подобная этой, помогает в значительной степени.
PS Дайте мне знать, если я правильно понял вашу проблему, или в конечном итоге бился в кустах;-) DS.