Этап 6 - Profiles: разные конфигурации сборки
Один и тот же код может требовать разных сборка settings в development, CI, legacy JDK или OS-specific environment. Профили позволяют сборке осознанно переключать выбранную настройка.
Профиль - это именованный набор сборка настройка, который может менять свойства, зависимости, плагин settings или репозитории. Его не используют, чтобы скрывать случайные различия между машинами.
Какую проблему это решает
Maven profiles можно активировать вручную через -P, по operating system, по JDK версия, по property или environment variable. Manual activation наиболее явная и проще всего читается.
Profile может добавить зависимость только для определенной сборки, изменить property вроде skipITs или иначе настроить плагин. Это полезно, но при злоупотреблении сборка становится трудно воспроизводимым.
В Gradle нет полностью такого же механизма профилей, как в Maven. Похожее поведение обычно делают через свойства проекта, переменные окружения, отдельные задачи, convention plugins или разные source sets.
Главное правило - не переносить запуск приложения environment настройка в сборка profile без причины. Database passwords, сервис URLs и feature flags обычно живут в приложение настройка, а не в сборка file.
Profiles лучше всего подходят для сборка-time differences: запускать integration тесты или нет, включать сгенерированный client, использовать special publishing репозиторий или активировать native-image сборка.
Последовательность шагов
- profile activation.
- свойства.
- зависимости/плагины.
- selected сборка behavior.
Эта последовательность - картинка в голове, с которой нужно читать файлы сборки. Названия в Maven и Gradle отличаются, но практический вопрос одинаковый: какой входные данные используется, какая задача запускается, какой результат получается и где этот результат хранится.
Конкретный пример
<profile>
<id>ci</id>
<properties>
<skipITs>false</skipITs>
</properties>
</profile>
Полезная таблица
| Понятие | Значение |
|---|---|
| Manual | mvn package -Pci |
| OS | Активируется только на Linux, macOS или Windows. |
| JDK | Активируется для конкретной JDK версия. |
| Property | Активируется при наличии Maven property. |
| Environment | Активируется по environment variable. |
Где это встречается в работе
Используй profiles умеренно и документируй их. Build, который молча меняется в зависимости от разработчик machine, - это будущий production incident.
В командной разработке знание сборки - не необязательная теория. Оно влияет на локальный development, время CI, зависимость upgrades, стабильность релиз и debugging. Когда Spring сервис не стартует после изменения зависимость, CI скачивает другую библиотека версия или артефакт не получается deployed, ответ обычно находится в сборка настройка, зависимость graph, упаковка step или репозиторий setup.
Частые ошибки
- Копировать настройка, не понимая, на какой слой сборка она влияет.
- Считать локально успешный сборка доказательством, что CI и production delivery тоже сработают.
- Игнорировать зависимость trees, сгенерированный результат и репозиторий rules до момента failed релиз.
- Смешивать приложение запуск приложения настройка и сборка-time настройка.
Чеклист понимания
- Я могу объяснить главные terms этой статьи, не перечитывая сборка file вслух.
- Я могу нарисовать последовательность от исходный код до артефакт для этой темы.
- Я могу назвать command или file, который первым проверю при сборка problem.
Вопросы для самопроверки
- Какую проблему этот сборка concept решает в реальном Java или Spring проект?
- Какой file или command быстрее всего даст evidence, когда что-то ломается?
- Какая ошибка заставит сборка работать локально, но падать в CI или у другого разработчик?
Практика перед следующим уроком
Добавьте небольшой профиль или вариант сборки, который меняет одно безопасное свойство: например classifier артефакта или выводимое значение. Запустите сборку с профилем и без него, затем проверьте, что обычная сборка работает без специальных флагов.