Постійна інтеграція: яка частота?

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

Спочатку кілька деталей:

• Проект Objective-C (iOS 5)
• 10 розробників
• кожна збірка фактично займає ~ 1 хв.
• Сервер інтеграції - це Mac Mini, тому обчислювальна потужність насправді тут не є проблемою
  • ми використовуємо Дженкінс із плагіном XCode

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

Отже, яка ваша думка з цього приводу?

Невдалий збій - хороший принцип - чим раніше ви знаєте, що збірка зламана, тим швидше може бути виявлено правопорушник і виправлення збірки.

Побудувати на кожному здійсненні - це правильно.

Побудова кожні 15 хвилин може бути безглуздим, якщо проект має великий обсяг зобов’язань у такі строки - відстеження поганої фіксації займе більше часу і може бути важко визначити (може бути також ситуація, коли в декількох комісіях є різні речі, які розбити збірку). Є ймовірність того, що в тихий час (нічний час?) Ви закінчите перебудовуватися, хоча жодних змін не було.

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

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

Ми робимо це на кожному зобов'язанні. Однак ми проводимо опитування сховища кожні п’ятнадцять хвилин і перевіряємо зміни, можливо, саме так посилаються ваші колеги.

Ви очікуєте, що ваші 10 диска будуть чинити більше одного разу кожні п’ятнадцять хвилин? Це звучить як досить висока оцінка. 10 дев означає, що через кожні 150 хвилин одна і та сама людина чинить знову, так що 2,5 години. Тож у середній день кожен дев займається 3 рази. Особисто я роблю один вчинок ~ 2 дні ... іноді більше, іноді менше.

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

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

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

Але я згоден, що сенсу будувати не має сенсу, якщо нічого не змінилося.

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

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

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

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

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

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

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

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

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

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