Maven профили - разработка и производство

Question

Мне было интересно узнать, как настроить профили разработки против производственных maven.Должен ли я помещать репозиторий моментальных снимков только в профиль разработчика, а другие артефакты (локальное репо, для выпусков и т. Д.) - в рабочий профиль?

Каковы основные характеристики различных профилей этих типов?

Answer 1

Разница, очевидно, заключается в настройках профилей Prod, Test и Dev. Такие вещи, как

• Подключение к базе данных
• Свойства, такие как настройки ресурса, конфигурация пула потоков, расположение файла журнала и его размер
• Настройки хранилища, такие как локальные, у вас может быть /mnt/media, но для Prod вы можете захотеть S3

варьируется в этих профилях.

Теперь приходят к релизу, обычно у Test profile / s есть релизы SNAPSHOT (например, ночные сборки), которые настроены для перехода в ваш репозиторий SNAPSHOT. И профиль Prod выпускается, как правило, с помощью Maven Release Plugin, который автоматически выбивает SNAPSHOT из вашей релизной версии / артефактов. И настроен на хранение артефакта в РЕЛИЗЕ РЕПО. Конфигурация этих репозиториев выглядит как

    <profile>
        <id>test</id>
        <distributionManagement>
            <snapshotRepository>
                <id>snapshotrepo</id>
                <name>Repository for snapshots only</name>
                <layout>default</layout>
                <uniqueVersion>false</uniqueVersion>
                <url>http://repo.company.com/snapshots</url>
            </snapshotRepository>
        </distributionManagement>
        .....
        .....
        .....

    <profile>
        <id>prod</id>
        </distributionManagement>
            <repository>
                <id>releaserepo</id>
                <name>Final release artifacts</name>
                <layout>default</layout>
                <uniqueVersion>false</uniqueVersion>
                <url>http://repo.company.com/releases</url>
            </repository>
        </distributionManagement>
        ....
        ....

Учетные данные для этих репозиториев входят в settings.xml.

Профиль Dev обычно не настроен для публикации в репозитории компании (так как он будет слишком загроможден бесполезными артефактами), он просто устанавливается в локальном репо, как SNAPSHOT, и перезаписывается при каждой сборке.

Answer 2

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

Пример профиля по умолчанию:

<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
    <repository>
        <id>central</id>
        <url>http://some_url/content/groups/public</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
    <repository>
        <id>snapshots</id>
        <url>http://some_url/content/groups/public-snapshots</url>
        <releases>
            <enabled>false</enabled>
        </releases>
    </repository>
</repositories>

Если вас беспокоит наличие зависимостей SNAPSHOT в ваших выпусках, вы можете использовать такие инструменты, как maven-release-plugin , чтобы убедиться, что в вашем проекте нет зависимостей SNAPSHOT.

Назовите основные вещи, которые отличаются профилями этих типов?

Вы часто используете профили для разделения между различными средами сборки. Например, используя CI, вы часто помещаете плагины для статического анализа кода, отчетов, покрытия тестами и т. Д. В профиль, который активируется только при сборке на сервере CI (поскольку для его запуска требуется больше времени при включенных этих инструментах).

Другое использование - это выделение определенной части приложения, например, вы не хотите, чтобы подмодуль приемочного теста выполнялся при каждом тесте mvn, но только иногда, когда вы включаете mvn test -p acceptTests профиль

Проблема с конкретными сборками среды

Теперь профили иногда используются для разделения конфигураций, таких как строки соединений, точки присоединения и т. Д. На мой взгляд, это не идеально, так как в итоге вы получаете сборки, специфичные для среды. Иногда этого трудно избежать, но в большинстве случаев это можно решить путем экстернализации конфигурации (убедитесь, что у вас есть правильное управление конфигурацией), и используйте тот же двоичный артефакт в dev / test / prod. Таким образом, вы уверены, что сборка, прошедшая системный тест, такая же, как в prod и т. Д.