Що означає "автоматизована збірка"?

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

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

Конкретні моменти плутанини: що означає "автоматизована побудова" в контексті:

• проект, що використовує інтерпретовану мову, наприклад Python чи Perl?
• будівництво з джерела на машині кінцевого користувача?
• додаток, який має залежності, які неможливо просто заздалегідь скомпілювати та поширити, як-от база даних у локальній RDBMS для машини користувача?

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

• Процес перетворення артефактів джерела (код, схема бази даних, документація тощо), розгорнутий кінцевому користувачеві.
• Застосування заходів забезпечення якості під час зазначеної трансформації

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

Етапи трансформації:

• Компіляція
• Зв’язування
• Упаковка
• Розгортання
• Міграція даних
• Резервне копіювання
• Повідомлення

Етапи забезпечення якості:

• Попередження / помилки компілятора
• Одиничні тести
• Інтеграційні тести
• Системні тести
• Аутентифікація розгортання

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

Автоматизована збірка - це опис процесу, який повинен охоплювати наступні основи:

1. Отримайте останній код з Source Control
2. Складіть останній код у виконуваний файл
3. Запустіть тести (одиничні тести, системні тести, інтеграційні тести) проти складеного коду
4. Розгорнути завершений виконуваний файл у відомому місці для розгортання.
5. Опублікуйте результати збірки.
   5.1 Успішне складання, успішність тестування одиниці

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

На мій погляд, автоматизована збірка - це щось таке

• відбувається автоматично, або за графіком, або з кожним зобов’язанням контролю джерела
• створює набір артефактів, який можна просто розгорнути на будь-який сервер

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

Якщо у вас мова не складається, ви все одно можете створити сайт і зафіксувати його, щоб створити єдиний артефакт.

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

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

a project using an interpreted language, such as Python or Perl?

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

будівництво з джерела на машині кінцевого користувача?

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

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

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

Те, що ви обговорюєте у своєму запитанні, - це фактично 3 різні поняття:

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

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

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

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

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

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

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

Для простого проекту Python автоматизована збірка може складатися лише з двох етапів - перевірки джерел та копіювання відповідних файлів у правильні каталоги. Для більш складних проектів це може включати такі речі:

• складання, зв’язування
• запуск автоматизованих тестів
• створення пакетів для встановлення
• встановлення
• модифікація баз даних
• створення резервних копій (у випадку, якщо вам потрібно відкотити)