Няня на вашій системі постійної інтеграції

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

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

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

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

Яких корисних практик слід дотримуватися? Які особливості зрілої безперервної інтеграції ?

Оновлення

Замість відповіді на деякі коментарі я збираюся зробити оновлення замість цього. У нас є одна проста команда, яка робить саме те, що буде робити сервер збирання при створенні програми. Він буде компілювати, запускати весь блок / інтеграцію та деякі швидкі тести на основі інтерфейсу.

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

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

У моїй команді все складніше - це те, що у нас є велика команда (10+ розробників). І у нас є кілька членів команди, які беруть участь в офшорній зоні, коли ми навіть не працюємо. Оскільки команда чисельна, і ми встановили, що часті, невеликі події віддають перевагу, ми іноді дійсно маємо велику активність за день.

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

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

У вашій команді щось не так:

Відповідальність за сервер збірки - це не те саме, що відповідальність за збірку .

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

• Будівництво зламалось!
• Що пішло не так при будівництві!
• Що змінилося з моменту останньої збірки!

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

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

Отже, щоб відповісти на ваше запитання: Зріле середовище CI НЕ вимагає залучення двірника до його нормальної роботи.

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

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

Стратегія "золотої гілки" не працює, якщо немає воротаря для золотої гілки.

DVCS типу Git може допомогти; замість виконання зобов'язань розробник може просто подати набір змін для інтеграції на сервер CI, і сервер може спробувати інтегрувати набір змін. Якщо інтеграція проходить успішно, набір змін об'єднується, а якщо ні - відкидається.

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

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

Додаткові переваги цього підходу включають:

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

PS. вся концепція побудови няні є смішною, але інші охопили це.

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

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

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

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

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

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

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

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

Якщо у вас є члени команди, які мають більше шансів зламати збірку (і, виходячи з мого власного досвіду, я здебільшого думаю про членів в іншій країні), і якщо ви використовуєте якийсь приємний сучасний контроль джерел, наприклад Mercurial або Git, ви можете змусити їх зареєструватися в іншій гілці для іншої команди, запустити окремий процес CI щодо цього та автоматично об'єднати зміни від цієї гілки до магістралі після успішної збірки (зауважте, що вам доведеться запустіть другу збірку і протестуйте після злиття, перш ніж перевірити злиття!). Оскільки автоматичне злиття не завжди є успішним, це врешті-решт залишить гілку, яка потребує ручної уваги, що може бути справжнім болем. Хоча це може бути менш болісно, ​​ніж те, що зламаний код зареєстрований для решти команди.

Як сказав Джонатан Кхо, ви повинні нести відповідальність за сервер збирання та сценарій збірки. Є три причини:

1. На даний момент у вас є випадок "Шина 1", що означає, що якщо ви переїхали на автобусі, то втрачаються всі знання про сервер збірки та сценарії побудови.
2. Сценарії, написані вами (правильно чи неправильно), мали лише ваш внесок. Як і будь-який код, чим більше залучених людей, тим ширша база знань, яка може бути застосована до нього.
3. Нарешті, коли щось піде не так, ви тільки відчуваєте біль. Біль - це добре, але не тоді, коли вона ізольована. На даний момент ви маєте справу з болем, але якби всі інші відчували біль, то ви виявите, що вони зрештою будуть більш суворими в тестуванні коду до вчинення.

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

1. Сценарії побудови повинні працювати не тільки на серверах CI, а й на локальних машинах розвитку. Вони повинні давати однакові результати, проводити ті ж самі тести і виходити з ладу з тих же причин. Це дозволяє розробникам запускати скрипт перед введенням коду.
2. Якщо хтось зламає складання, оприлюднить його за допомогою використання спливаючих вікон у лотку завдань, електронних листів, миготливих вогнів, шумів тощо. Це не тільки бентежить членів команди, але й надає можливість усім іншим у команді стрибнути вгору та допомогти.
3. На деякий час уникайте виправлення збірки. Запропонуйте комусь іншому це зробити. Якщо ніхто більше не підскакує, чекайте, коли трапляться погані речі, і використовуйте це як точку навчання для всієї команди, щоб зрозуміти, чому сервер CI важливий.
4. Постарайтеся, щоб ваш сервер побудови та машини для розробки був максимально позбавленим встановлених сторонніх компонентів, особливо підтримуйте чистоту GAC. Покладайтеся на сторонні компоненти, що знаходяться в папці бібліотеки проектів. Це допомагає швидше визначити відсутні компоненти.

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

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

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

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

Інше - покращити рівень відповідальності людей. Наприклад, якщо ви використовуєте щось на кшталт Рітвельда, люди не можуть скористатися, не пройшовши експертної оцінки. (На практиці цей процес набагато легший, ніж ви думаєте, він є. Але він змушує людей "конвеєрувати" та працювати над кількома речами одночасно. Якщо хтось або регулярно ламає збірку, або схвалює речі, які порушують збірку, тоді не дозволяйте їм давати остаточне схвалення комітетів. Поєднайте з процесом, коли кожен може легко відмовити будь-які зміни, і збірка не буде ламатися так часто, і не залишиться порушеною, коли зміни будуть внесені.

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

Пари, про які слід пам’ятати:

1. Вашій команді потрібен набір стандартів, яких слід дотримуватися
2. Вам потрібно отримати управління на борту з ідеєю чистого коду та прагнути до вдосконаленої практики кодування.
3. Тестовий тест-тест! Завжди перевіряйте перед тим, як зареєструватися.
4. Хоча я згоден, що це нормально, щоб зламати збірку, це рідкісний, і я маю на увазі надзвичайно рідкісний випадок, який був би прийнятним. Якщо це щодня, я б шукав двері або говорив зі своїм начальником про стандарти.

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