Просте пояснення безперервної інтеграції

Як би ви визначили постійну інтеграцію та які конкретні компоненти містить сервер CI?

Я хочу пояснити комусь із відділу маркетингу, що таке неперервна інтеграція. Вони розуміють управління джерелами - тобто використовують Subversion. Але я хотів би правильно пояснити їм, що таке CI. Вікіпедія Стаття ніколи правильно визначає це, стаття Мартіна Фаулера дає лише наступне, яка в основному тавтологія з подальшою невиразним поясненням «інтеграції»:

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

Оновлення : Я надіслав їм це зображення, не знайшов більш простого.

Оновлення 2 : Зворотній зв'язок з маркетинговою ділянкою (на час, коли було 3 питання):

Мені справді подобаються всі 3 відповіді - з різних причин. Мені подобається ввійти, щоб подякувати їм усім!

Очевидно, він не може - тому дякую від його імені :)

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

1. Підтримуйте сховище коду
2. Автоматизуйте збірку
3. Зробіть самотестування збірки
4. Кожен день бере на себе базову лінію
5. Кожна комісія (до базової лінії) повинна бути побудована
6. Тримайте нарощування швидко
7. Випробування в клоні виробничого середовища
8. Полегшіть отримання останніх результатів
9. Кожен може побачити результати останньої збірки
10. Автоматизація розгортання

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

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

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

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

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

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

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

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

Давно це було б написано так:

1. Погодьтесь із схемою для бази даних та вимогами - на це знадобиться тижнів, оскільки вона мала бути ідеальною, оскільки незабаром ви зрозумієте, чому
2. Призначте 3 розробки, або 3 незалежні команди розробників, на 3 частини
3. Кожен розробник працював над своїм твором і тестував свою частину, використовуючи власну копію бази даних, протягом тижнів чи місяців.

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

Коли всі три частини були повністю закодовані та протестовані їх розробниками, а іноді навіть перевірені користувачами (показуючи їм звіт, екран або попередження по електронній пошті), то настане фаза "інтеграції". Цей бюджет часто формувався на кілька місяців, але все-таки продовжувався. Ця зміна довжини поля на dev 1 буде виявлена ​​тут, і знадобиться розробки 2 та 3, щоб внести величезні зміни коду і, можливо, зміни інтерфейсу. Цей додатковий індекс спричинив би свій власний хаос. І так далі. Якщо хтось із розробників сказав користувачеві додати поле, і це зробило б, зараз би настав час і двом іншим.

Ця фаза була жорстоко болісною і майже неможливо передбачити. Тож люди почали говорити: "ми повинні частіше інтегруватися". "Ми повинні працювати разом з самого початку". "Коли хтось із нас піднімає запит на зміну (саме так ми говорили тоді], інші повинні про це знати". Деякі команди почали робити інтеграційні тести раніше, продовжуючи працювати окремо. І деякі команди почали використовувати код один одного і виводити весь час, з самого початку. І це стало постійною інтеграцією.

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

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

Його думка вважала, що ви не ставите речі під контроль джерел, поки це не буде зроблено. Зазвичай він робив одну-дві перевірки РОКІВ. У нас було трохи різниці у філософії :-)

Крім того, якщо вам важко повірити, що команди будуть відключені навколо спільного ресурсу, як-от база даних, ви дійсно не повірите (але це правда), що той самий підхід був застосований до кодування. Ви збираєтесь написати функцію, яку я можу зателефонувати? Це чудово, продовжуй і роби це, я просто жорстко кодую те, що мені потрібно тим часом. Через кілька місяців я "інтегрую" свій код, щоб він закликав ваш API, і ми виявимо, що він підірветься, якщо я пропущу нуль, я підірву, якщо він поверне null (і це робиться дуже багато), він поверне занадто великі речі для мене він не справляється з високосними роками та тисячею інших речей. Працювати незалежно, а потім мати фазу інтеграції було нормально. Зараз це звучить як божевілля.