В мои годы программирования на 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 для сборки и запуска сервера:

mvn clean install cargo:start -Dcargo.maven.wait=true

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

./startServer.sh #or startServer.bat for Windows

И для развертывания обновления в производственной среде процесс просто:

1. Остановите работающий экземпляр сервера, если есть.
2. Беги svn update -r<target_release_revision>.
3. Беги ./startServer.sh.

Это просто, легко запомнить и сделать это невозможно, если бы я полагался на использование среды IDE для создания развертываемой для меня версии. Это также делает возврат к последнему известному удачному развертыванию несложным, если когда-либо понадобится откат.

Я даже не могу сосчитать, сколько времени этот подход спас мне от попыток вручную управлять процессом развертывания и настройки.

И, конечно же, еще один ответ на ваш вопрос - автоматическое управление зависимостями, но я думаю, что это уже охватывалось другими ответами.

Пока ваш код находится в управлении исходным кодом, использование IDE для создания распространяемых файлов - это нормально.

Если вы работаете в одиночку, лучше ли вам тратить время на добавление новых функций в свой продукт или написание сценариев сборки? Что-то говорит мне, что он не пишет сценарии сборки.

Конечно, труднее увидеть преимущества, когда ты работаешь один. Лично я работал над множеством сольных проектов, и я не только написал сценарий сборки, но и столкнулся с проблемой настройки CI Server (например, Jenkins).

Конечно, есть накладные расходы, почему это того стоит?

• Воспроизводимая сборка, не привязанная к IDE (или вашей машине, если вы запускаете ее извне). Если сервер сборки запускает его, другие машины могут запустить его.
• Веселье начинается после сборки и модульного тестирования (кстати: вы уверены, что тестируете перед каждым коммитом? Иногда я забываю). Генерация документации, сборка инсталляторов, запуск любимых инструментов анализа кода.
• Ваш любимый CI-сервер позволяет вам видеть графики покрытия кода, сбоев модульных тестов и т. Д. Ваша IDE делает это?

Для моего текущего проекта скрипт собирает, запускает инструменты статического анализа, сжимает js / css, модульные тесты и пакеты в веб-архив. Jenkins запускает его после каждого коммита и развертывает проект на тестовом сервере.

Я потратил время на настройку ( кстати, сценарий сборки может быть 300 строк, не затрагивал его месяцами) и могу сказать, что это того стоит, даже для одного человека. Для более чем одного человека это необходимо. Мое участие в процессе сборки / развертывания состоит из команд "hg commit" и "hg push".

Преимущества инструментов сборки

Это краткое резюме, просто показывающее верхушку айсберга, и вы не обязательно заметите важность всего этого, если вам не нужно объединять множество проектов, крупные проекты и среднюю или большую команду. Но если у вас есть вера и попытка, вы будете пожинать плоды .

Они облегчают ваш жизненный цикл разработки и позволяют:

• организовывать и структурировать свои проекты последовательно и без усилий
• повторно использовать передовой опыт в рамках проектов и легко и быстро начать его,
• объединить несколько проектов в одной сборке,
• автоматизировать вашу непрерывную интеграцию процесса,
• поделитесь своим проектом с другими
  • без принуждения их использовать определенный инструментарий или IDE (кроме системы сборки),
  • и не удивляя их, так как они ожидают стандартную сборку
• автоматизировать и облегчить на обслуживание вашего продукта
• автоматизировать процесс выпуска вашего продукта

Если мы применим это к Maven ...

Для тех из вас, кто живет в мире Java и использует Maven , прочитав это, вы естественным образом связали каждую точку с:

• Соглашение структурированного проекта Maven
• Maven Архетипы
• Материализация проекта из СКМ и реакторных сборок
• Поддержка Jenkins / Hudson / Bamboo / Other + поддержка Maven для интеграционных тестов
• m2eclipse, встроенная поддержка IntelliJ или NetBeans - или mvnsh для командной строки
• версии-Maven-плагин
• плагин maven-release-plugin, плагин buildnumber-maven-plugin и плагин версии-maven-плагин

И, конечно же, Maven (но также и другие инструменты) обеспечивает управление зависимостями , и это экономит время и пространство для вас (с учетом количества людей в вашей команде) и вашего SCM.

Все относительно

Я использую Maven в качестве примера, потому что я думаю, что это самая полная и «встроенная система батарей», но это не значит, что она обязательно «лучшая». Он подходит для всех перечисленных выше флажков, и, когда я ищу хорошую систему сборки, я сравниваю ее с этим списком и Maven. Однако Maven не всегда очень гибок - он, однако, очень расширяем - если вы отклоняетесь от стандартизированного процесса. Это повышает вашу продуктивность в общем случае (когда-то впереди кривой обучения), а не если вы боретесь с этим.

Вот мои главные 4 причины использовать инструменты сборки:

• обработка зависимостей (избегайте ошибок)
• тестирование (ваши изменения не сломали другие модули - намного проще тестировать)
• безопасные коммиты
• проще развернуть локальный дистрибутив (никто не успевает в QA env ждать, пока сборщик соберет ваш проект и его зависимости)

В книге Pragmatic Programmer Эндрю Хант и Дэвид Томас говорят, что «checkout-build-test-deploy» должна быть единой командой (глава «Прагматические проекты»). Вы написали..

У меня даже есть потенциальный инвестор, и я планирую показать им бета-версию в ближайшие несколько недель.

Тогда я уверен, что ваша команда будет расти. Еще более важно иметь возможность автоматического развертывания тестов.

Большой XML (скрипт), который вы видели, обычно является одноразовой работой. В большинстве случаев одни и те же сценарии могут использоваться во многих проектах.

Не ясно, насколько велик проект. Если ваши интегрированные тесты / приемочные тесты занимают большой процессор / память, вы можете рассмотреть возможность использования другой машины в качестве тестового сервера. Вы также можете использовать множество инструментов для анализа исходного кода / байтового кода .

Я бы сказал, что для одинокого разработчика иметь хороший процесс и структуру, подобную сборке на основе сценариев, гораздо важнее, чем когда вы в команде. Причина в том, что у вас нет товарищей по команде, чтобы звать вас, когда вы срезаете углы. CI-сервер, на котором выполняется ваш скрипт сборки, делает вас отличным бескомпромиссным партнером по команде, чтобы вы были честны.

По мере роста вашей кодовой базы вы захотите добавить набор тестов. По моему опыту, это должно быть сделано раньше, а не позже, и что ваша ночная (или любая другая) сборка должна запускать все тесты каждый раз. Начните с малого, автоматически сгенерированный XML, вероятно, в порядке. Когда вы боитесь что-то изменить из-за страха что-то сломать, это хороший стимул написать несколько тестовых случаев.

Сборка без IDE позволяет легко перестраивать старые версии, не беспокоясь о перенастройке вашей IDE, как это было в то время, позволяет выполнять сборку не в интерактивном режиме, чтобы вы могли вести ночные сборки, чтобы люди могли их протестировать или быстро найти. если вы не справились с тестами, не запуская их, и дождитесь их завершения.

Он также позволяет выполнять сборки в средах без графического интерфейса, например, ssh'ing на сервере, и позволяет переключать IDE, не беспокоясь о потере возможности создавать свое программное обеспечение.

Некоторые инструменты сборки помогают автоматизировать тегирование и развертывание релизов, поставляются с приличными настройками по умолчанию для создания отчетов о покрытии кода и т. Д.

Когда вы добавляете больше людей, инструмент сборки гарантирует, что вы не уязвимы для чужой плохой конфигурации IDE. Я регулярно делаю скриншоты, чтобы исправить установки Eclipse коллег, потому что они не используют инструменты сборки (работая над этим).

Однако главная причина в том, что это не нужно делать вручную, поэтому не делайте этого вручную. Все остальное выпадает из этого.