Убедите одинокого разработчика использовать отдельный инструмент для сборки вместо сборки в один клик IDE

22

В мои годы программирования на Java и в последнее время на Scala я никогда не использовал Ant, Maven, Gradle или какие-либо из этих инструментов для сборки Java. Везде, где я работал, был менеджер сборки, который позаботился обо всем этом - я собирал локально с IDE для разработки и модульного тестирования, затем проверял исходный код и уведомлял менеджера сборки, который сделал то, что было необходимо для скомпилировать все файлы для общей среды.

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

Но все время я просто нажимаю кнопку сборки в IDE, и он создает файл Jar, и он работает просто отлично. Конечно, общепринятая мудрость предполагает, что я «должен» писать свои собственные сценарии Ant / Maven / Gradle и использовать их вместо IDE, но каковы конкретные преимущества этого в моей ситуации (работая в одиночку)?

Я немного прочел о том, как использовать эти инструменты сборки, и похоже, что я написал бы сотни строк XML (или Groovy или чего-то еще), чтобы сделать то, что IDE делает в один клик (сгенерированный IDE Ant XML для проекта составляет более 700 строк). Это просто выглядит подверженным ошибкам, трудоемким и ненужным для моей ситуации. Не говоря уже о кривой обучения, которая отнимает время у всей другой работы, которую я делаю, чтобы подготовить продукт, чтобы показать людям.

Gigatron
источник
3
Хотя вам, безусловно, следует подумать о возможности использования скриптов Ant / Maven / Gradle для управления процессом сборки. Это, безусловно, может подождать до более поздней фазы вашего цикла разработки. Не усложняй дела. Когда вы собираетесь выпустить что-то, что можно продать, и у вас есть инвестор, и когда это выходит за рамки просто вы, тогда подумайте об этом. Потому что это, конечно, не будет задачей «сделай это один раз и забудь». Вам нужно будет обновлять скрипт в соответствии с вашими процедурами сборки. Беспокойство по поводу сценариев, когда у вас есть помощь.
Ramhound
5
Инструменты сборки становятся полезными в тот момент, когда вам приходится иметь дело не только с «последней версией, содержащей весь последний код». Вы еще не там - в тот момент, когда вы делаете, приручите свою сборку.
8
Если то, что вы делаете сейчас, работает и не доставляет вам проблем - просто продолжайте. «Преждевременное исправление», вероятно, вызывает больше проблем, чем «Преждевременная оптимизация». Кроме того, ваша IDE, вероятно, использует Ant под одеялом.
Джеймс Андерсон
1
Весьма актуальный вопрос
Мадхур Ахуджа

Ответы:

11

Я бы посоветовал вам использовать 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 для создания развертываемой для меня версии. Это также делает возврат к последнему известному удачному развертыванию несложным, если когда-либо понадобится откат.

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

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

aroth
источник
1
Я продолжу сборку IDE в один клик, пока не выйдет первая бета-версия. Тогда я планирую использовать Maven. Кажется, что Ant создает больше работы, чем спасет для моей ситуации, но Maven кажется достаточно простым и достаточно мощным, чтобы того стоить. Для меня это не просто вопрос, есть ли польза от инструмента сборки; Я также взвешиваю затраты на его изучение, настройку и обслуживание.
Гигатрон
7

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

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

Nate
источник
7
Я не согласен 1000 раз. Если вы правильно структурируете свои сценарии сборки, то вам действительно придется заплатить только один раз за их написание, а затем использовать их почти дословно в любом количестве проектов. Там очень много можно сказать в пользу наличия команды сборки в одну строку , которая строит, конфигурирует, развертывает и запускает систему автоматически. И как только вы это сделаете, это сэкономит массу времени по сравнению с ручным развертыванием / управлением конфигурацией, которое затем можно будет потратить на те новые функции, которые вы упомянули.
aroth
Я бы согласился, что магазин с одним человеком должен быть сфокусирован. Я не согласен с вашим предположением, поскольку инструменты сборки позволят сэкономить время в долгосрочной перспективе, как для настройки новых проектов и поддержки существующих, так и даже для создания результатов по требованию клиентов.
Хайлем
Тонкое преимущество Maven заключается в том, что он лучше всего работает со стандартной компоновкой файлов, а не со специальным способом, часто встречающимся в проектах Ant. Когда люди видят преимущество использования настроек по умолчанию Maven, они используют их, и их проекты легче понять для будущих сопровождающих.
1
@aroth Но OP вообще не тратит время на «ручное развертывание / управление конфигурацией», он просто нажимает кнопку в своей IDE. Так что это не сэкономит время вообще.
Атсби
1
IDE - это система сборки. Иначе я бы не использовал его.
Арне Эвертссон
5

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

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

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

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

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

Kryptic
источник
Верно. Реальное, что должен учитывать этот разработчик, - это хорошее CI-решение, и скрипт сборки может помочь получить их там.
Билл Мичелл
4

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

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

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

  • организовывать и структурировать свои проекты последовательно и без усилий
  • повторно использовать передовой опыт в рамках проектов и легко и быстро начать его,
  • объединить несколько проектов в одной сборке,
  • автоматизировать вашу непрерывную интеграцию процесса,
  • поделитесь своим проектом с другими
    • без принуждения их использовать определенный инструментарий или 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 не всегда очень гибок - он, однако, очень расширяем - если вы отклоняетесь от стандартизированного процесса. Это повышает вашу продуктивность в общем случае (когда-то впереди кривой обучения), а не если вы боретесь с этим.

haylem
источник
3

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

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

источник
1
Особенно обработка зависимостей. Мне лень скачивать и добавлять внешние библиотеки. Гораздо проще просто добавить их в качестве зависимости. "Неправильная версия? Измените версию в конфигурации и перестройте!"
Да, но обработка зависимостей не является обязательным условием для всех инструментов сборки. Maven, Gradle, Ivy поддерживают это. Муравей, Делай, и т.д ... нет.
Хайлем
2

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

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

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

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

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

Джаян
источник
1

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

Уайетт Барнетт
источник
именно то, что я думал! В настоящее время я работаю в месте, где каждый разработчик работает в одиночку над своим собственным проектом. Я еще не смог продать им идею системы сборки, но сам использую ее, потому что думаю, что она действительно помогает.
Элиас
0

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

tripleee
источник
1
Я уже делаю модульные тесты без необходимости отдельного инструмента для сборки. В среде IDE можно запускать тесты или запускать их из командной строки.
0

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

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

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

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

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

Рики Кларксон
источник