Які переваги сценаріїв побудови?

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

Я пам’ятаю, як писали кадри ще в школі, але я не бачив особливої ​​переваги тоді (ми використовували їх лише під час запису в терміналі Unix, де IDE із зручною кнопкою «build» не було). Крім цього, я бачив інші питання, які обговорюють, як побудувати сценарії можуть не просто створити вашу програму - вони можуть запускати одиничні тести , а також захищати ресурси незалежно від хост-машини .

Я не можу похитнутись від того, що сценарії побудови важливі для розуміння як розробника, але я хотів би змістовного пояснення; чому я повинен використовувати / писати сценарії побудови?

Обов'язки Build Script і Build Server обговорюють роль, яку він відіграє в більш широкому обсязі. Я шукаю конкретні переваги, запропоновані сценарієм збірки, порівняно з командою ID (ID / команда "build / run") або подібними простими методами.

Автоматизація.

Коли ви розробляєте, лише в найбільш простих проектах кнопка "build" за замовчуванням зробить все, що вам потрібно для цього; Вам може знадобитися створювати WS з API, генерувати документи, зв’язуватися із зовнішніми ресурсами, розгортати зміни на сервері тощо. Деякі IDE дозволяють налаштувати процес збирання шляхом додавання додаткових кроків або будівельників, але це означає лише, що ви генерування сценарію складання за допомогою товарів IDE.

Але розробка системи - це не тільки написання коду. Існує кілька кроків. Незалежний сценарій IDE може бути виконаний автоматично, тобто:

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

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

• Зараз у решти організації (QA, sysadmins) є вбудований продукт, який

  а) чудово відтворюється лише з контрольної версії.

  б) є ​​загальним для всіх них.

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

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

На противагу цьому, м'ясосумки, наповнені водою, просто відверті, коли йдеться про наступні кроки. Цей примхливий аналітичний мозок має тенденцію ставити під сумнів усе, що йому трапляється. "О ... мені це не потрібно", або "Чи я справді користуюся цим прапором? Е ... я просто проігнорую його". Крім того, ми маємо тенденцію до самовдоволення. Після того, як ми щось зробили кілька разів, ми починаємо вірити, що ми знаємо інструкції, і не потрібно дивитися на інструкцію.

З "Прагматичного програміста":

Крім того, ми хочемо забезпечити послідовність та повторюваність проекту. Ручні процедури залишають консистенцію до зміни; повторюваність не гарантована, особливо якщо аспекти процедури відкриті для тлумачення різними людьми.

Крім того, ми РОЗПОВІДНО мляві у виконанні інструкцій (порівняно з комп'ютером). У великому проекті з сотнями файлів і конфігурацій знадобиться років, щоб вручну виконати всі етапи процесу збирання.

Я наведу вам приклад із реального світу. Я працював над деяким вбудованим програмним забезпеченням, де більшість коду ділилось на декількох апаратних платформах. Кожна платформа мала інше обладнання, але більшість програмного забезпечення було однаковим. Але було мало деталей, які були специфічними для кожного обладнання. В ідеалі, загальні фрагменти розміщуватимуться в бібліотеці та пов’язуватимуться з кожною версією. Однак загальні фрагменти не вдалося зібрати в спільну бібліотеку. Це потрібно було складати з кожною різною конфігурацією.

Спочатку я склав кожну конфігурацію вручну. Щоб переключитися між конфігураціями, знадобилося лише кілька секунд, і це не біль. Під кінець проекту було виявлено критичний дефект у спільній частині коду, де пристрій по суті взяв би на себе шину зв'язку. Це був БАД! Справді погано. Я знайшов помилку в коді, виправив його та перекомпілював кожну версію. Крім одного. Під час збирання я відволікся і забув його. Бінарні файли були звільнені, машина була побудована, і через день я отримую телефонний дзвінок, в якому говорилося, що машина перестала відповідати. Я перевірив це, і виявив, що пристрій заблокував шину. "Але я виправив цю помилку!".

Я, можливо, це виправив, але він так і не знайшов дорогу на одну дошку. Чому? Тому що у мене не було автоматизованого процесу збирання, який би будував кожну версію за один клік.

Якщо все, що ви коли-небудь хочете зробити, це <compiler> **/*.<extension>створення сценаріїв не мало мети (хоча можна стверджувати, що якщо ви бачите a Makefileв проекті, який ви знаєте, ви можете його створити make). Вся справа в тому, що нетривіальні проекти зазвичай вимагають більше цього - як мінімум, вам зазвичай потрібно буде додати бібліотеки та (по мірі дозрівання проекту) налаштувати параметри збирання.

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

Вам також потрібно розібратися, як зробити цю зміну в кожному з IDE, використовуваних командою, і якщо одна з них не підтримує конкретний параметр ...

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

Навіть якщо ви змусите всіх розробників використовувати один і той же IDE - удача переконати сервер збірки використовувати його ...

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

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

Багато IDE просто пакують команди, які використовуються для створення щось, а потім генерують сценарій і викликають його!

Наприклад, у Visual Studio ви можете побачити параметри командного рядка для компіляції C ++ у вікні "командного рядка". Якщо ви уважно придивитеся до виводу збірки, ви побачите тимчасовий файл, який містить сценарій збірки, який використовувався для запуску компіляції.

Сьогодні це все MSBuild , але це все ще безпосередньо керується IDE.

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

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

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

make

набагато простіше запам’ятати та набрати

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

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

make clean

простіше і надійніше одного разу правильно налаштувати, ніж намагатися запам'ятати кожне місце, можливо, був створений проміжний файл.

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

Як ще ти би це зробив? Єдиний інший спосіб - вказати одну довгу команду командного рядка.

Ще одна причина полягає в тому, що makefiles дозволяють наростити компіляцію, що значно прискорює час компіляції.

Makefiles також може зробити процес складання крос-платформи. CMake генерує різні сценарії побудови на основі платформи.

Редагувати:

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

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

Самі IDE часто також створюють сценарії внутрішньо; кнопка запуску - це ще один спосіб виконання команди make.

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

Я професійний розробник Android / IOS / Windows Phone, і я використовую API - інтерфейси сервісів Google ( в основному Google Maps) на багато .

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

Замість того, щоб додавати до консолі розробника і керувати десятками магазинів ключів, лише один з яких насправді можна використати для оновлення програми, я включаю цю сховище ключів у нашу безпечну репо-версію і використовую Gradle, щоб точно розповісти Android Studio, який клавіатурний склад використовувати при будівництві "налагодження" або "звільнення". Тепер мені залишається лише додати два магазини брелоків до консолі розробника Google, один для «налагодження» та один для «випуску», і всі члени моєї команди можуть клонувати репо і отримати право на розвиток, не входячи в розробник консоль і додати SHA хеш-код їх конкретного сховища, або ще гірше, що змушує мене керувати ними. Це має додаткову перевагу в тому, щоб дати кожному члену команди копію магазину підписань, тобто, якщо я не в офісі, і оновлення заплановане, члену команди потрібно лише дотримуватися дуже короткого списку інструкцій, щоб перенести оновлення.

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

Переваги сценарію побудови:

• зміни виглядають як код (наприклад, у команді git diff), а не як різні перевірені параметри в діалоговому вікні

• створюючи більше результатів, ніж проста збірка

У деяких своїх попередніх проектах я використовував сценарії збірки для:

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

Часто ви можете викликати кнопку «побудувати» автоматизованим способом (наприклад, Visual Studio приймає аргументи командного рядка). Люди пишуть сценарії побудови, як тільки їм потрібно щось, що не може надати кнопка збірки.

Наприклад, більшість IDE дозволять вам створювати одну платформу за один раз. Або лише одна мова за раз. Тоді є те, що ви робите зі вбудованими виходами: чи може ваш IDE згорнути їх у пакет для встановлення?