Як CI можна використовувати для інтерпретованих мов?

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

Я не бачу, як CI буде корисним для мене, якщо у мене немає кроку побудови. Я можу вважати CI як середовище тестування, яке б виконувало одиничні тести. Я щось пропускаю?

Постійна інтеграція як термін позначає дві чіткі ідеї.

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

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

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

Виявляється, такий сервер є цінним для більш ніж просто тестування. Насправді, більшість програмного забезпечення CI справді лайно під час виконання тестів у різних конфігураціях, але добре керувати різними робочими завданнями. Наприклад, на додаток до «безперервних» тестів на одиницю, може бути повний тест у вигляді нічного складання. Програмне забезпечення може бути протестовано з декількома версіями Python, різними версіями бібліотеки. Веб-сайт може бути перевірений на наявність мертвих посилань. Ми можемо проводити статичний аналіз, перевірку стилів, засоби перевірки тестування тощо над кодом. Документацію можна створити. Коли всі тестові набори пройдуть, процес упаковки може бути ініційований, щоб ви були готові випустити своє програмне забезпечення. Це корисно у спритних налаштуваннях, де ви хочете, щоб продукт, який можна розгортати, завжди можна було розгортати. З розвитком веб-додатків з’являється і ідея постійного розгортання: Якщо всі тести пройдуть, ми можемо автоматично підштовхнути зміни до виробництва. Звичайно, це вимагає, щоб ви були справді впевнені у своєму тестовому наборі (якщо ні, у вас є більші проблеми).

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

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

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

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

• Виконання автоматичних тестів. (У Python є безліч бібліотек автоматизованого тестування, а у PHP - принаймні деякі. Я не можу спілкуватися з MATLAB.)
• Комплектація програмного забезпечення для розповсюдження. Автоматизуючи цей процес, ви забезпечуєте його виконання точно, послідовно, повторюваним способом кожен раз. Жодні кроки не забудуться; генерація такого пакета розповсюдження займає щонайменше один клік. (З’єднання програми Python як колесо - це відмінна ідея!)
• Позначення віхи здійснює. Щоразу, коли ви будуєте пакет для виробництва, ви, ймовірно, хочете тегувати його.
• Автоматично збільшуються номери версій. Зазвичай це просто номер "збірки", а не більш значущі частини, але це може бути непогано однозначно визначити певну збірку, щоб ви знали, що де розміщено.

Пройшовши трохи далі до прикордонної лінії "безперервної інтеграції" в строгому сенсі, ви також можете зробити це:

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

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

• Послідовний процес (у вас не буде, щоб Стен і Саллі робили речі по-різному.)
• Знання процесів, записаних у коді (кожен, хто вміє читати сценарії, може вивчити кроки, пов'язані з розгортанням, замість того, щоб Салі була єдиною, хто це робить чи вміє.)
• Простіше дублювання процесів (просте розгортання декількох копій веб-сайту: ви просто надаєте нову конфігурацію!)
• Більш ретельне тестування (Боб лише протестував свою сторінку, але його зміни зламали сторінку Салі. Саллі забула створити файл. Стен додав нову залежність, яку потрібно встановити поряд з додатком, але не усвідомив її, оскільки вона встановлюється автоматично IDE Я все це бачив у тій чи іншій формі.)

І, певно, деякі інші переваги, які навіть не приходять у голову.

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

Скажімо, ви розгортаєте свій код Python на 5 різних QA-серверах і потребуєте його вказівки на різні бази даних QA, а потім після автоматичного тестового запуску (запускається CI), просуваючи збірку до виробництва та розгортаючи її там із відповідними змінами конфігурації для кожного виробничого сервера .