В мои годы программирования на Java и в последнее время на Scala я никогда не использовал Ant, Maven, Gradle или какие-либо из этих инструментов для сборки Java. Везде, где я работал, был менеджер сборки, который позаботился обо всем этом - я собирал локально с IDE для разработки и модульного тестирования, затем проверял исходный код и уведомлял менеджера сборки, который сделал то, что было необходимо для скомпилировать все файлы для общей среды.
Теперь, когда я нахожусь между контрактами, я работаю над своим собственным самофинансируемым проектом, и он подходит к тому моменту, когда он может быть достаточно хорошим, чтобы реально зарабатывать деньги. У меня даже есть потенциальный инвестор, и я планирую показать им бета-версию в ближайшие несколько недель.
Но все время я просто нажимаю кнопку сборки в IDE, и он создает файл Jar, и он работает просто отлично. Конечно, общепринятая мудрость предполагает, что я «должен» писать свои собственные сценарии Ant / Maven / Gradle и использовать их вместо IDE, но каковы конкретные преимущества этого в моей ситуации (работая в одиночку)?
Я немного прочел о том, как использовать эти инструменты сборки, и похоже, что я написал бы сотни строк XML (или Groovy или чего-то еще), чтобы сделать то, что IDE делает в один клик (сгенерированный IDE Ant XML для проекта составляет более 700 строк). Это просто выглядит подверженным ошибкам, трудоемким и ненужным для моей ситуации. Не говоря уже о кривой обучения, которая отнимает время у всей другой работы, которую я делаю, чтобы подготовить продукт, чтобы показать людям.
источник
Ответы:
Я бы посоветовал вам использовать Maven, а не Ant. Если ваша IDE может создать ваш проект в один клик, то, вероятно, Maven также может построить ваш проект практически без пользовательской конфигурации.
И чтобы ответить на вопрос, упрощение процесса развертывания является одним конкретным примером. Если вы создаете локально распространяемый дистрибутив, это означает, что вам необходимо вручную развернуть этот дистрибутив в вашей производственной системе, и подразумевает, что вам, вероятно, пришлось выполнить немало ручной настройки в производственной системе, чтобы подготовить его к развертыванию (установка Tomcat). , возможно, или копирование зависимостей и ресурсов, необходимых вашему приложению). Это может занять много времени и может сделать развертывание обновлений утомительным, ручным процессом. Это также дает возможность для любых незначительных различий в конфигурации между вашей производственной платформой и вашей средой разработки, чтобы вызвать неясные, трудно отследить ошибки.
Так или иначе, что я делаю, чтобы избавиться от этой ручной рутины, так это то, что я настраиваю свой проект для сборки с Maven, и я настраиваю свой
pom.xml
файл со всей информацией, необходимой для (в случае веб-приложения Java) поиска и загрузки правильная версия Tomcat, установите ее локально, настройте правильные файлы конфигурации Tomcat, разверните все зависимости проекта и сам файл WAR проекта, а затем запустите Tomcat. Затем я создаю простой сценарий оболочки (а также.bat
версию для Windows), который использует Maven для сборки и запуска сервера:Таким образом, вместо того, чтобы упаковать развертываемое в моей среде разработки и затем вручную передать его в производство, все, что мне нужно сделать, - это синхронизировать систему управления версиями с рабочим сервером, а затем сама производственная система строит, устанавливает и запускает развертываемый (и делает это способом, идентичным тому, как это делается в любой системе разработки, сводя к минимуму вероятность ошибок или неправильной конфигурации для конкретной платформы). И будь то в среде разработки или производства, все, что я делаю, чтобы собрать и запустить сервер, это:
И для развертывания обновления в производственной среде процесс просто:
svn update -r<target_release_revision>
../startServer.sh
.Это просто, легко запомнить и сделать это невозможно, если бы я полагался на использование среды IDE для создания развертываемой для меня версии. Это также делает возврат к последнему известному удачному развертыванию несложным, если когда-либо понадобится откат.
Я даже не могу сосчитать, сколько времени этот подход спас мне от попыток вручную управлять процессом развертывания и настройки.
И, конечно же, еще один ответ на ваш вопрос - автоматическое управление зависимостями, но я думаю, что это уже охватывалось другими ответами.
источник
Пока ваш код находится в управлении исходным кодом, использование IDE для создания распространяемых файлов - это нормально.
Если вы работаете в одиночку, лучше ли вам тратить время на добавление новых функций в свой продукт или написание сценариев сборки? Что-то говорит мне, что он не пишет сценарии сборки.
источник
Конечно, труднее увидеть преимущества, когда ты работаешь один. Лично я работал над множеством сольных проектов, и я не только написал сценарий сборки, но и столкнулся с проблемой настройки CI Server (например, Jenkins).
Конечно, есть накладные расходы, почему это того стоит?
Для моего текущего проекта скрипт собирает, запускает инструменты статического анализа, сжимает js / css, модульные тесты и пакеты в веб-архив. Jenkins запускает его после каждого коммита и развертывает проект на тестовом сервере.
Я потратил время на настройку ( кстати, сценарий сборки может быть 300 строк, не затрагивал его месяцами) и могу сказать, что это того стоит, даже для одного человека. Для более чем одного человека это необходимо. Мое участие в процессе сборки / развертывания состоит из команд "hg commit" и "hg push".
источник
Преимущества инструментов сборки
Это краткое резюме, просто показывающее верхушку айсберга, и вы не обязательно заметите важность всего этого, если вам не нужно объединять множество проектов, крупные проекты и среднюю или большую команду. Но если у вас есть вера и попытка, вы будете пожинать плоды .
Они облегчают ваш жизненный цикл разработки и позволяют:
Если мы применим это к Maven ...
Для тех из вас, кто живет в мире Java и использует Maven , прочитав это, вы естественным образом связали каждую точку с:
И, конечно же, Maven (но также и другие инструменты) обеспечивает управление зависимостями , и это экономит время и пространство для вас (с учетом количества людей в вашей команде) и вашего SCM.
Все относительно
Я использую Maven в качестве примера, потому что я думаю, что это самая полная и «встроенная система батарей», но это не значит, что она обязательно «лучшая». Он подходит для всех перечисленных выше флажков, и, когда я ищу хорошую систему сборки, я сравниваю ее с этим списком и Maven. Однако Maven не всегда очень гибок - он, однако, очень расширяем - если вы отклоняетесь от стандартизированного процесса. Это повышает вашу продуктивность в общем случае (когда-то впереди кривой обучения), а не если вы боретесь с этим.
источник
Вот мои главные 4 причины использовать инструменты сборки:
источник
В книге Pragmatic Programmer Эндрю Хант и Дэвид Томас говорят, что «checkout-build-test-deploy» должна быть единой командой (глава «Прагматические проекты»). Вы написали..
Тогда я уверен, что ваша команда будет расти. Еще более важно иметь возможность автоматического развертывания тестов.
Большой XML (скрипт), который вы видели, обычно является одноразовой работой. В большинстве случаев одни и те же сценарии могут использоваться во многих проектах.
Не ясно, насколько велик проект. Если ваши интегрированные тесты / приемочные тесты занимают большой процессор / память, вы можете рассмотреть возможность использования другой машины в качестве тестового сервера. Вы также можете использовать множество инструментов для анализа исходного кода / байтового кода .
источник
Я бы сказал, что для одинокого разработчика иметь хороший процесс и структуру, подобную сборке на основе сценариев, гораздо важнее, чем когда вы в команде. Причина в том, что у вас нет товарищей по команде, чтобы звать вас, когда вы срезаете углы. CI-сервер, на котором выполняется ваш скрипт сборки, делает вас отличным бескомпромиссным партнером по команде, чтобы вы были честны.
источник
По мере роста вашей кодовой базы вы захотите добавить набор тестов. По моему опыту, это должно быть сделано раньше, а не позже, и что ваша ночная (или любая другая) сборка должна запускать все тесты каждый раз. Начните с малого, автоматически сгенерированный XML, вероятно, в порядке. Когда вы боитесь что-то изменить из-за страха что-то сломать, это хороший стимул написать несколько тестовых случаев.
источник
Сборка без IDE позволяет легко перестраивать старые версии, не беспокоясь о перенастройке вашей IDE, как это было в то время, позволяет выполнять сборку не в интерактивном режиме, чтобы вы могли вести ночные сборки, чтобы люди могли их протестировать или быстро найти. если вы не справились с тестами, не запуская их, и дождитесь их завершения.
Он также позволяет выполнять сборки в средах без графического интерфейса, например, ssh'ing на сервере, и позволяет переключать IDE, не беспокоясь о потере возможности создавать свое программное обеспечение.
Некоторые инструменты сборки помогают автоматизировать тегирование и развертывание релизов, поставляются с приличными настройками по умолчанию для создания отчетов о покрытии кода и т. Д.
Когда вы добавляете больше людей, инструмент сборки гарантирует, что вы не уязвимы для чужой плохой конфигурации IDE. Я регулярно делаю скриншоты, чтобы исправить установки Eclipse коллег, потому что они не используют инструменты сборки (работая над этим).
Однако главная причина в том, что это не нужно делать вручную, поэтому не делайте этого вручную. Все остальное выпадает из этого.
источник