Алгоритм для поиска и устранения неисправностей “Знатока не работает на меня” проблемы
Одной из наиболее распространенных и раздражающих проблем, с которыми я встречаюсь со Знатоком, является процесс здания, приводящий к сбою/передающий в зависимости от того, кто, когда и на котором машина выполняет процесс.
Более официально - в идеальном мире я ожидал бы, что процесс сборки будет повторяем. Как программист я сказал бы, что ожидаю, что процесс сборки будет похож на чистую функцию исходного кода и ресурсов, являющихся входом сборки и "средой" - я ожидал бы, что это возвратит тот же результат любое время, и где угодно я "оцениваю" его с помощью "зафиксированную среду", и я ожидаю (скорее желание), что у всех в команде есть та же "фиксированная среда".
В реальном мире или "среда" изменяется со временем или варьируется между машинами разработчика, возможно потому что это включает некоторые зависимости один не ожидает и не понимает.
То, что я пытаюсь достигнуть задавания этого вопроса, находит/определяет алгоритм/процедуру или контрольный список для поиска и устранения неисправностей не повторяемыми процессами сборки Знатока. Позвольте предполагают, что у нас есть две отдельных машины A и B с той же ОС и что мы создаем точно ту же версию нашего приложения на них, но они дают различные результаты (например, каждый успешен, и каждый перестал работать). Где/как нужно искать различия между этими двумя "средами".
Это некоторые шаги, которые я обычно использую:
- сравните эффективных АНГЛИЧАН, полученных через
mvn help:effective-pom - сравните mvn выполняемые версии + другие включенные инструменты (например, jdk)
- сравните параметры среды (полученный в соответствии с Windows с помощью командной строки
setкоманда) - выдержать сравнение
settings.xmlфайлы из корневых каталогов пользователя - сравните пути к классам генерировали использование
mvn dependency:build-classpath - удалите репозиторий или даже оба репозитория
Какие-либо идеи, что еще может дать ценную информацию? Возможно, существует лучший способ, которым я просто отсутствую...
4 ответа
Я видел много сборок Maven, которые не работали на разных машинах из-за разных версий Maven или Java и связанных с ними ошибок или функций. Я даже видел, как сборки терпят неудачу и проходят на одной и той же машине, когда, например, построенный на командной строке по сравнению со встроенным в IDE.
Если вызываются инструменты командной строки, вы можете обнаружить, что они зависят от платформы или машины. Я видел это в первую очередь в пакетных задачах, которые создают файлы .dmg на Mac или .msi на машинах Windows, и упаковка должна запускаться в этих ОС для создания определенных файлов.
Кодирование файлов как ресурсов, так и исходных файлов вызывало у меня проблемы в прошлом. Проверка того, что свойство project.build.sourceEncoding установлено, кажется полезной информацией. Как ни странно, похоже, что это используется при копировании или фильтрации ресурсов, но игнорируется при работе с исходными файлами, IIRC.
Давайте приготовим тосты по-американски: жги, я поскребу. - В. Эдвардс Деминг.
Вместо того, чтобы искать алгоритм для устранения неполадок в ваших неповторимых сборках, устраните основную причину , сделайте их повторяемыми, следуя передовым методам (сборки Maven на 100% воспроизводимы, если вы используете их правильно):
- использовать одну и ту же версию Maven на всех машинах данного проекта (распространять упакованную версию)
- использовать одну и ту же версию JDK (по крайней мере, ту же версию для данного проекта)
- заблокировать версии плагинов в вашем poms для воспроизводимости сборки
- обеспечивают соблюдение вышеуказанных правил, используя Maven Enforcer Plugin
- , используйте корпоративный репозиторий (и только корпоративный репозиторий)
- , избегайте создания непереносимых сборок, добавляя не специфичные для пользователя вещи в
] ~ / .m2 / settings.xml - поставить все под контроль версий (эффективный pom должен быть одинаковым на всех машинах)
- запустить чистую сборку на машине сборки (ссылка)
Я использовал Maven в организациях с сотнями разработчиков, не испытывающих описываемых вами проблем. На самом деле, и я с сожалением должен сказать, что проблемы, с которыми вы сталкиваетесь, не виноват Maven, они просто результат плохой практики разработки (я не хочу показаться грубым, но это правда).
Отслеживайте, что вы делаете, и у вас будет возможность отслеживать, что делают разработчики:
- Создайте машину сборки (для выпускных сборок), документируя каждую часть установленного программного обеспечения и каждый выбранный вариант конфигурации
- Частная сборка машины должны быть настроены таким же образом, чтобы гарантировать максимальную вероятность того, что сборка будет работать
- . В случае сбоя частной сборки перечислите программное обеспечение и конфигурации и сравните их с конфигурацией выпуска. Предполагается, что различия не поддерживаются и должны быть исправлены, чтобы достичь максимальной вероятности успешной сборки
На самом деле не ответ как таковой, но мы удаляем весь локальный репозиторий на компьютере сборки каждую неделю.
Машина сборки также ограничена небольшим набором локальных и прокси-репозиториев, которые разработчики не могут редактировать.
Сначала у нас было много сборок, которые просто перестают работать после удаления репозитория. Теперь это ежемесячная проблема. Его тенденция к проблеме раз в день месяца.
Это способствовало ряду хороших практик по блокировке номеров версий, версий плагинов, использованию профилей для локальных сборок, использованию исключений при необходимости и добавлению jar-файлов 3rd party в нужные места.