У свої роки програмування Java та нещодавно Scala я ніколи не використовував Ant, Maven, Gradle чи будь-який із цих інструментів побудови Java. Скрізь, де я працював, був менеджер збірки, який подбав про все це - я збирав локально з IDE для розробки та тестування підрозділів, потім перевіряв вихідний код і повідомляв менеджеру збірки, який робив те, що потрібно компілювати всі файли для спільного середовища.

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

Але весь час я просто натискаю кнопку збірки на IDE, і він створює файл Jar, і він працює чудово. Звичайно, загальноприйнята мудрість говорить про те, що я "повинен" писати свої власні сценарії Ant / Maven / Gradle і використовувати це замість IDE, але які конкретні переваги цього в моїй ситуації (працюючи в самоті)?

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

Я б запропонував вам поглянути на використання Мейвена на відміну від Мурахи. Якщо ваш 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 (наприклад, Дженкінс).

Звичайно, над головою, чому це того варто?

• Відтворювана конструкція, не прив’язана до IDE (або до вашої машини, якщо ви запускаєте її зовні). Якщо сервер збирання працює ним, інші машини можуть запускати його.
• Забава починається після побудови та тестування одиниць (до речі: ви впевнені, що ви протестуєте перед кожним вчиненням? Я іноді забуваю). Створюйте документацію, створюйте інсталятори, запускайте улюблені інструменти аналізу коду.
• Ваш улюблений сервер CI дозволяє з часом бачити графіки покриття коду, відмови тестування блоку тощо. Чи робить це ваш IDE?

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

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

Переваги інструментів збирання

Це короткий підсумок, який показує лише верхівку айсберга, і ви не обов'язково помітите важливе значення всього цього, якщо вам не потрібно поєднувати безліч проектів, великих проектів і середньої та великої команди. Але якщо ви будете мати віру і постаратися, ви отримаєте користь .

Вони полегшують життєвий цикл вашого розвитку, а також дозволяють:

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

Якщо ми застосуємо це до Maven ...

Для тих із вас, хто в світі Java, і хто користується Maven , читаючи це, ви, природно, асоціювали кожну точку з:

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

І звичайно, Maven (але й інші інструменти також) дає вам управління залежністю , і це величезна економія часу та простору для вас (враховуючи кількість людей у ​​вашій команді) та ваш SCM.

Все відносно:

Я використовую Maven як приклад, тому що я вважаю, що це найповніша система побудови та "батареї включені", але це не означає, що це обов'язково "найкраще". Він відповідає всім переліченим вище пунктам, і, шукаючи гарної системи збірки, я порівнюю його з цим списком і Maven. Однак Maven не завжди є дуже гнучким - він, однак, дуже розширюється, - якщо ви відхиляєтесь від свого стандартизованого процесу. Це підвищує вашу продуктивність у загальному випадку (колись випереджаючи криву навчання), а не якщо боротися з цим.

Ось мої чотири основні причини використання інструментів збирання:

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

У книзі « Прагматичний програміст» Ендрю Хант та Девід Томас говорять, що «оформлення замовлення-тест-розгортання» має бути єдиною командою (Глава: Прагматичні проекти). Ви написали..

У мене навіть потенційний інвестор вишикувався і планую показати їм бета-версію в найближчі кілька тижнів

Тоді я впевнений, що ваша команда буде зростати. Ще важливіше зробити автоматичні можливості тестового розгортання.

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

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

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

У міру того, як база вашого коду зростає, вам потрібно буде додати тестовий набір. Мій досвід полягає в тому, що це потрібно зробити швидше, ніж пізніше, і щоб ваша нічна (або будь-яка інша) побудова повинна кожного разу проводити всі тести. Почніть з малого, автоматично створений XML, ймовірно, добре. Коли ти боїшся щось змінити, боїшся зламати щось інше, це хороший стимул написати кілька тестових випадків.

Збірка без IDE дозволяє легко переробляти старі версії, не турбуючись про перенастроювання IDE таким, яким він був у той час, і дозволяє виконувати збірку неінтерактивно, щоб ви могли підтримувати нічну збірку для тестування людей або швидко дізнатися якщо ви зламали тести, не пам'ятаючи про їх запуск і чекати їх завершення.

Він також дозволяє виконувати збірки в не-графічному середовищі, наприклад, ssh'ing на сервер, і дозволяє вам перемикати IDE, не переживаючи про втрату можливості побудови свого програмного забезпечення.

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

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

Кінцева причина, хоча це те, що це не потрібно робити вручну, тому не робіть цього вручну. Все інше випадає з цього.