Що таке безперервна інтеграція (КІ) і чим вона корисна? [зачинено]

Чи може хтось пояснити мені концепцію неперервної інтеграції, як вона працює легко зрозумілим способом? І чому компанія повинна приймати ІС у процесі роботи з доставкою коду? Я розробник, і моя компанія (в основному команда побудови) використовує Team City. Як розробник, я завжди перевіряю, оновлюю і вводя код у SVN, але взагалі ніколи не мав турбуватися про TeamCity або CI. Тож я хотів би зрозуміти, у чому корисність ІП? Чи є ДІ частиною методів Agile?

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

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

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

КІ зазвичай асоціюється з методами Agile, однак я особисто не знаю точної історії ІС.

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

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

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

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

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

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

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

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

Існує два аспекти постійної інтеграції.

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

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

Точка 2 - це інструменти та рамки, необхідні для забезпечення безпечного виникнення пункту 1, швидко ідентифікуючи злиття, які вийшли з ладу, порушивши існуючий код.

Наскільки це корисно?

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

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

CI корисний, якщо у вас є:

• Складання коду
• Фактичний набір тестів
• Повідомляє, що на основі вашого вихідного коду (охоплення коду, насильство за кодовими стандартами тощо)
• Звичайний, який ви робите періодично, після успішного складання коду

Список можна продовжити ..