Лучшая практика знатока для генерации артефактов для нескольких сред [напоминание, тест, dev] с поддержкой CI/Гудзона?
У меня есть проект, который должен быть развернут в несколько сред (напоминание, тест, dev). Основные отличия главным образом состоят в свойствах/файлах конфигурации.
Моя идея состояла в том, чтобы использовать профили и оверлейные программы для копирования/настраивания специализированного вывода. Но в меня вонзаются, если я должен генерировать несколько артефактов со специализированными классификаторами (исключая: "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar"), или я должен создать несколько проектов, один проект для каждой среды?!
Я должен использовать плагин блока знатока для генерации нескольких артефактов для каждой среды? Так или иначе я должен буду генерировать все их сразу так это швы, которым профили не соответствуют... все еще озадаченный :(
Любые подсказки/примеры/ссылки будут больше, чем одобрены.
Как второстепенный вопрос, я также задаюсь вопросом, как достигнуть этого в CI Гудзон/Бамбук, чтобы генерировать и развернуть эти сгенерированные артефакты для всех сред к их надлежащим серверам (исключая: использование SCP Гудзонский плагин)?
4 ответа
Я бы использовал элемент версии (например, 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) и, таким образом, теги / ветки на уровне VCS в сочетании с профилями (для конкретных сред, таких как имена машин , пароли имени пользователя и т. д.) для создания различных артефактов.
Мы используем профили для этого, но у нас есть только профиль по умолчанию, который мы называем профиль «разработка», и в нем есть файлы конфигурации, и у нас есть профиль «выпуска», в который мы не включаем файлы конфигурации (чтобы их можно было правильно настроить при установке приложения).
Я бы использовал для этого профили, и я бы добавил профиль в имя артефакта, если вам нужно его развернуть. Я думаю, что это несколько похоже на то, что предлагал Паскаль, только вы будете использовать профили, а не версии.
PS: Еще одна причина, по которой у нас есть только профили разработки / выпуска, заключается в том, что всякий раз, когда мы отправляем что-то для UAT или PROD, оно было выпущено, поэтому, если есть ошибка, мы можем отследить, в каком состоянии был код, когда приложение было выпущено - проще пометить его в SVN, чем пытаться найти его состояние из истории коммитов.
Я предпочитаю упаковывать конфигурационные файлы отдельно от приложения. Это позволяет запускать ТОЧНО такое же приложение и предоставлять конфигурацию во время выполнения. Это также позволяет генерировать конфигурационные файлы постфактум для среды, о необходимости которой вы не знали во время сборки. Например, CERT. Я использую инструмент "сборка", чтобы заархивировать конфигурационные файлы каждого домена в именованные файлы.
Прошлым летом у меня был именно такой сценарий.
В итоге я использовал профили для каждой более высокой среды с классификаторами. Профилем по умолчанию была разработка "не навреди". У меня был профиль DEV, INT, UAT, QA и PROD.
В итоге я определил несколько заданий в Hudson для создания артефактов, специфичных для региона.
Единственное, что я сделал бы по-другому, - это немного по-другому спроектировать проекты, чтобы сборка для конкретного региона находилась вне модульного основного проекта. То есть он просто извлекал самые последние артефакты для каждой конкретной сборки, а не перестраивал весь проект для каждого региона.
На самом деле, когда я настраивал задания, задания QA и PROD всегда настраивались на основе тега. Ясно, что это то, что вы могли бы адаптировать к правилам вашего рабочего места при развертывании.