Що таке інструмент збирання?

Протягом останніх 4 років я програмував за допомогою Eclipse (для Java) та Visual Studio Express (для C #). Згадані ІДЕ завжди, здавалося, забезпечують кожну програму, яку може запросити програміст (звичайно, пов'язаний з програмуванням).

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

Що таке інструменти побудови?

Інструменти збирання - це програми, що автоматизують створення виконуваних програм із вихідного коду (наприклад, .apk для програми Android). Будівництво включає складання, зв'язування та упаковку коду у зручну або виконувану форму.

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

1. Завантаження залежностей.
2. Складання вихідного коду у двійковий код.
3. Упаковка цього двійкового коду.
4. Запуск тестів.
5. Впровадження у виробничі системи.

Чому ми використовуємо інструменти побудови або будуємо автоматизацію?

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

Доступні різні інструменти побудови (називаючи лише декілька):

1. Для яви - мураха, Мейвен, Градле.
2. Для .NET Framework - NAnt
3. c # - MsBuild.

Для подальшого читання ви можете перейти за наступними посиланнями:

1. Автоматизація побудови

2. Список програмного забезпечення для автоматизації побудови

Дякую.

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

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

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

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

Ідея полягає в тому, щоб відокремити роботу над складанням та упаковкою коду від створення, налагодження тощо.

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

make був інструментом раннього командування, який використовувався в * nix середовищах для побудови C / C ++.

Як розробник Java, найпопулярнішими інструментами побудови є Ant та Maven. Обидва можуть бути запущені в IDE, таких як IntelliJ або Eclipse або NetBeans. Вони також можуть бути використані за допомогою інструментів безперервної інтеграції, таких як круїз-контроль або Хадсон.

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

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

Походження всіх систем побудови здається знаменитим "make".

Існують системи побудови для різних мов:

1. C ++: make, cmake, premake
2. Ява: мураха + плющ, мавен, градле
3. C #: msbuild

Зазвичай будують системи або за допомогою мови, визначеної для власності (make, cmake), або xml (ant, maven, msbuild) для визначення збірки. Сучасна тенденція полягає у використанні справжньої мови сценаріїв для написання сценарію складання, наприклад, lua for premake та groovy for gradle, перевага використання сценаріїв полягає в тому, що він набагато гнучкіший, а також дозволяє придумати набір стандартних API (як збірка DSL).

Процес збирання - це процес складання вихідного коду на наявність будь-яких помилок за допомогою деяких інструментів збирання та створення збірок (які є виконуваними версіями проекту). Ми (в основному розробники) робимо деякі зміни у вихідному коді та при реєстрації цього коду, щоб відбувся процес збирання. Після процесу збирання він дає два результати: 1. Будьте складені PASSES, і ви отримаєте виконану версію свого проекту (Build готовий). 2. Це не вдається, і ви отримуєте певні помилки, і збірка не створюється.

Існують різні типи процесів збирання, такі як: 1. Нічна збірка 2. Зведена конструкція 3. Постійна збірка інтеграції тощо

Інструменти побудови допомагають та автоматизують процес створення збірок.

* Отже, у Short Build - це версія програмного забезпечення у форматі до випуску, що використовується розробником або командою розробників для отримання впевненості у кінцевому результаті свого Продукту, постійно контролюючи їх Продукт та вирішуючи будь-які проблеми на початку процесу розробки. *

Це різні типи процесів, за допомогою яких ви можете виконати свої побудови.

1. Постійне нарощування інтеграції:В основному розробники зареєструють свій код і відразу після їх реєстрації збірка ініціює для побудови останніх змін, тому ми повинні знати, чи зміни, внесені розробником, спрацювали чи ні відразу після реєстрації. Це є кращим для менших проектів або компонентів проектів. У випадку, коли з проектом пов'язано декілька команд або їх немає. Для розробників, що працюють над тим самим проектом, цей сценарій стає важким для вирішення, як ніби немає «ні». реєстрації, і збірка не вдається в певні моменти, стає дуже важко відстежити, чи не відбулося все поломку через одну проблему чи з декількома проблемами, тому якщо старі проблеми не будуть вирішені належним чином, то дуже важко простежити пізніше дефекти, які виникли після цієї зміни.

2. Збудовані заїзди: - Цей тип перевірки в збірці починається одразу після того, як реєстрація виконана, зберігаючи зміни в наборах полиць. У цьому випадку, якщо збірка вдається, ніж реєстрація встановлена ​​на полиці, інакше вона не буде здійснена на сервер Team Foundation. Це дає дещо кращу картину з безперервної побудови інтеграції, оскільки лише успішним заїздом дозволено взяти участь.

3. Нічні побудови: Це також називається Заплановані побудови. У цьому випадку ми плануємо збірки, які слід виконати на певний час, щоб побудувати зміни. Усі попередні невідомі зміни від останньої збірки будуються під час цього процесу збирання. Це практикується тоді, коли ми хочемо перевірити кілька разів, але не хочемо збирати кожен раз, коли ми перевіряємо свій код, щоб у нас був визначений час або період, у який ми можемо ініціювати збірку для побудови зареєстрованого коду.

Більш детальну інформацію про ці збірки можна знайти в нижченаведеному місці.

Реєстрація в будівлях

Постійна інтеграція будує

Нічні будівлі

Ви їх використовували - IDE - це інструмент збирання. Для командного рядка ви можете використовувати такі речі make.

Люди користуються інструментами командного рядка для таких речей, як нічна збірка - тому вранці з похмілля програміст зрозумів, що код, з яким він співпадає з останніми збірками бібліотек, не працює!

"... дуже важко відстежувати, що потрібно будувати" - Інструменти побудови не допомагають у цьому всьому. Вам потрібно знати, що ви хочете побудувати. (Цитується з відповіді Ritesh Gun)

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

"Як же, я ніколи не потребував їх упродовж останніх чотирьох років". Можливо, тому, що ви досвідчений програміст.

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

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

Що робити, якщо в проект буде додано 4-5 компонентів. Ви додаєте 6-й компонент. Разом з першим доданим компонентом це може накрутити все. Жоден автоматик не допоможе виявити це.

Немає іншого ярлика, ніж думати, думати, думати.

Потім відбувається автоматичне завантаження із сховищ. Чому б вам хотілося це робити? Вам потрібно знати, що ви завантажуєте, що додаєте до проекту. Як ви виявляєте зміни у версіях сховищ? Вам потрібно знати. Ви нічого не можете "автоматизувати".

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

Вибачте, немає ярликів https://en.wikipedia.org/wiki/Scientist_method та https://en.wikipedia.org/wiki/Analysis