Витрати на підтримку роботи безперервної інтеграції
Потенційна необхідність у виділеному сервері під потреби безперервної інтеграції
Негайний ефект від неповного або непрацюючого коду відучує розробників від виконання періодичних резервних включень коду в репозиторій
У разі використання системи управління версіями сирцевого коду з підтримкою розгалуження, ця проблема може вирішуватися створенням окремої "гілки" (англ. branch) проекту для внесення великих змін (код, розробка якого до працездатного варіанту займе кілька днів, але бажано частіше резервне копіювання в репозиторій). Після закінчення розробки та індивідуального тестування такої гілки, вона може бути об'єднана (англ. merge) з основним кодом або "стовбуром" (англ. trunk) проекту.
Найбільш популярні інструменти:
· CruiseControl15 - сервер інтеграції для Java (CruiseControl).
· ThoughtWorks Cruise6 - комерційний сервер інтеграції від компанії ThoughtWorks (є безкоштовна версія).
· CruiseControl.NET9 - сервер інтеграції для .NET (CruiseControl.NET)
· CruiseControl.rb3 - сервер інтеграції для Ruby.
· Hudson15 - open-source сервер інтеграції, створений як альтернатива CruiseControl. Функціональність розширюється плагінами.
· Bitten10 - open-source сервер інтеграції написаний на Python, інтегрується з Trac.
· TeamCity11 - комерційний сервер інтеграції від компаніїї JetBrains для java і .NET (є безкоштовна версія)
Для того щоб зробити потрібний вибір сервера безперервної інтеграції, можна за допомогою таблиці порівняння даних ( інтернет )
Налаштування Jenkins
Значний час в нашому проекті використовувалася самописна система інтеграційного тестування - чекаут коду по хуку в системі контролю версій, прогонка тестів з підтримкою звітів по покриттю коду, запис результатів в окремий html-файл, який був доступний розробникам через веб.
Природно, потім довелося робити підтримку локів, щоб водночас не запускалось відразу два тестування тощо.
Зрештою на її підтримку стала йти відчутна частина робочого часу, яка давно звела до нуля всі переваги простоти розробки такої системи, і було вирішено встановити нормальний сервер Continuous Integration.
В якості нової системи був вибраний Jenkins, про його встановлення та налаштування для django-проекту і піде мова в цій статті. Хто зацікавився, ласкаво просимо під кат.