Як пояснити Flaky CI Pipeline англійською мовою

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

Ключовий словник

** Неоднорідний тест / неоднорідний конвеєр ** — тест або конвеєр, який дає неоднозначні результати (пройшов або не пройшов) у різних запусках без будь- яких змін у коді, зазвичай, це пов’ язано з проблемами з часом, середовищем або порядком. “Цей конвеєр є нестабільним, особливо на стадії тестування інтеграції — він зазнає невдачі приблизно один раз з десяти, без відповідної зміни коду.”

** Відтворення з перервами ** — описує помилку, яку неможливо надійним чином викликати на запит, що змінює підхід до зневадження порівняно з послідовно відтворюваною помилкою.

• “Це відтворюється лише з перервами, тому я додаю додаткове журналювання навколо підозрілого стану гонки, а не намагаюся вловити його за допомогою зневаджувача.” *

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

• “Ми перезапускали цю роботу тижнями замість того, щоб вирішити причину — я хочу дізнатися, чому вона не спрацьовує, перш ніж ми нормалізуємо ігнорування червоних збірок.” *

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

Звичайні фрази

• «Цей тест провалюється періодично, приблизно [X] з [Y] запусків, без відповідної зміни коду»
• «Я підозрюю, що це скоріше проблема часу, ніж справжня регресія — невдача не корелює з будь-яким конкретним затвердженням»
• «Замість того, щоб перезапускати це знову, давайте додамо журналювання / відстеження, щоб спіймати його в дії наступного разу, коли він зазнає невдачі»
• «Я карантиную цей тест, щоб він не блокував злиття, поки ми розслідуємо, але зберігаючи його видимим на нашому флейк тестовому трекері»
• «Ця тріщина почалася близько [date/commit range] — що сужає місце, де шукати кореневу причину»

Приклади висловлювань

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

Відкидання звичайних повторень: “Я помітив, що ми повторили одну і ту ж роботу одинадцять разів цього місяця замість того, щоб розслідувати її — чи можемо ми використати південь, щоб дійсно визначити причину, перш ніж це ще більше погіршить довіру до всього набору?”

Пояснення команді щодо рішення про карантин:

• “Я переношу цей тест на карантин, а не мовчки пропускаю його — він все ще працює і все ще видимий на панелі тестів, просто не блокуючи злиття, поки ми не знайдемо справжню причину.” *

Пояснення кореневої причини після її виявлення: “Вийшло, що цей тест передбачав, що початок бази даних закінчиться протягом 200 мс, що тривало локально, але ненадійно під навантаженням CI — ми виправили це, чекаючи на явний сигнал готовності замість фіксованої затримки.”

Професійні поради

• Завжди чітко розрізняйте ** тріщини у результатах ** від ** справжньої регресії **, оскільки їх об’ єднання або призведе до того, що справжні вади буде відкинуто як « просто тріщини », або буде марно витрачати час на переслідування фантомної помилки.
• Зазначте ** рівень невдач конкретно ** (“4 з останніх 20 запусків”), а не “це трапляється іноді”, що дає команді реальний сигнал про тяжкість.
• Повільно, але чітко відкидайте звичайні повторні запуски без кореневої причини, оскільки це єдина найбільша причина, чому несправні тести тривають місяцями, замість того, щоб їх виправити.
• Використовувати карантину як навмисну, видиму, тимчасову заходу — а не евфемізм для тихого вилучення або постійного ігнорування тесту.
• Після того, як ви знайдете причину, вкажіть ** назву конкретного механізму ** (виправлення затримки замість готового сигналу, спільне тестове пристрій, незавершене з’ єднання), щоб виправлення і його обґрунтування було зрозумілим для майбутніх читачів.

Практичні вправи

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

Поняття «філософія» вживається для позначення окремих напрямків філософії

Флаки CI конвеєри - ті періодичні збої, які здаються з’являються з нізвідки - є поширеною головною болем в розробці програмного забезпечення. Але ефективне їх пояснення не просто про те, щоб сформулювати проблему; це про те, щоб передати як ви сприймаєте проблему, і робити це таким чином, щоб це звучало з колегами з різних сфер. Часто прямі переклади технічних термінів можуть призвести до непорозумінь. Наприклад, просто сказати «збірка зазнала невдачі» може не повністю передати розчарування члена команди, який провів години очікування на розгортання, тільки щоб побачити його аварію через кілька секунд.

Ключовим є використання точного словника і продемонструвати розуміння потенційних причин. Хороший підхід починається з визнання * спостереження * - що щось несподіване сталося - перед тим, як перейти до деталей. Замість того, щоб стверджувати « CI зазнав невдачі », спробуйте такі фрази, як « Я помітив помилку збирання під час автоматизованого тестування » або « Було повідомлено про помилку з перервами у конвеєрі ». Це негайно зробить це фактичним спостереженням, а не судженням. Важливо, щоб ви пояснили, чому ви вважаєте це проблематичним. Фрази на кшталт «Це свідчить про потенційну нестабільність в [конкретному компоненті]» або «Це може вказувати на проблему з конфігурацією нашого середовища» є набагато більш конструктивними, ніж просто сказати «це пошкоджено»

Розглянемо повідомлення Slack для вашої команди: «Збірка #123 з часом зазнавала невдач під час нічних тестових запусків. Журнали показують перехідні помилки мережі, але це відбувається приблизно кожні 30 хвилин. Я підозрюю, що це впливає на наш розклад випуску і потребує дослідження. ” Зауважте, як це використовує конкретні деталі — номер збірки, час, інформацію журналу — у поєднанні з обґрунтованою гіпотезою (« Я підозрюю… »). Іншим корисним способом описати проблему комусь, хто переглядає ваш запит на завантаження, є: « Конвейєр CI постійно зазнає невдачі під час об’ єднання запитів, які вносять зміни до модуля автентифікації. Це може бути через умови раси або конфлікти, введені новим кодексом. ”

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