Англійська для розробників GitLab CI

Модель конвеєра GitLab CI — етапи, завдання, виконавці, артефакти — має достатньо власного словника, що обговорення можуть швидко стати неясними, якщо терміни використовуються вільно. Цей посібник містить інформацію англійською мовою, яку використовують під час обговорення конвеєрів CI/CD GitLab з командою.

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

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

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

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

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

** Artefact ** — файли, створені одним завданням і передані до наступних завдань або етапів, механізм спільного використання виводу збирання без його перезбирання. “Не перезбирайте програму у завдання з розгортання — завдання збирання вже створило її як артефакт; просто звантажте і використовуйте її.”

** needs ключове слово (конвейєр DAG) ** — директива, яка дозволяє запуск завдання, як тільки буде завершено виконання певних залежностей, замість очікування завершення всіх попередніх етапів.

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

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

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

• «Яка стадія насправді провалюється, і чи підтверджені попередні стадії зеленими?»
• Чи це завдання очікує через невідповідність тегу runner, або це справжнє затримання черги?
• «Чи ми відновлюємо щось тут, що попередня робота вже виробила як артефакт?»
• Чи дозволив би needs розпочати цю роботу раніше, замість того, щоб чекати на всій сцені?»
• Чи буде ця залежність встановлюватися кешуванням, або кожен запуск платить цю вартість з нуля?»

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

Перегляд запиту на звантаження: “Це нове завдання не декларує needs, тому воно чекає на весь тестовий етап, хоча насправді залежить тільки від завдання lint — це додає непотрібний час конвеєра.”

Пояснення рішення про проектування:

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

Опис події:

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

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

• Використовуйте « стадія » і « завдання » точно — стадія є фазовим воротом, завдання є одиницею роботи у ньому; змішування їх призводить до справжньої плутанини під час зневадження порядку конвеєра.
• Визначте назву **« runner tags » **, якщо завдання застрягло у черзі — це одне з перших речей, які слід перевірити, і часто є джерелом плутанини для новачків.
• Розрізняти “artefact” від “cache” чітко — артефакти є вихідними даними конвеєра; кеш є крос- запусковим прискоренням, і їх об’ єднання призводить до помилок застарілих збірок.
• Запропонувати ** needs ** за назвою, коли конвеєр відчувається повільнішим, ніж він повинен бути — це конкретний механізм для перетворення лінійного конвеєра в швидший DAG.

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

1. Поясніть у двох реченнях, чому needs може зробити конвеєр швидшим, ніж покладатися тільки на порядок етапів.
2. Написати коментар перегляду коду у одному реченні, у якому буде позначено завдання, яке перебудовує щось, що вже є доступним як артефакт.
3. Опишемо вашими словами відмінність між артефактом і кешом конвеєра.

Національний гідрографічний інститут: Відповідь і відповіді

Для людей, для яких англійська не є рідною мовою, які вчаться ефективно спілкуватися в професійному середовищі розробки, особливо в контексті GitLab CI/CD, мова йде не тільки про те, щоб знати що сказати, але і як сказати це. Часто нерозуміння виникають не з технічної складності, а з тонких відмінностей у фразуваннях і очікуваннях навколо зворотного зв’язку. Розглянемо типовий сценарій: розробник надсилає запит на звантаження зі складним налаштуванням конвеєра. Під час перегляду коду старший інженер залишає коментар на зразок: « Цей етап здається надто багатослівним; чи не могли б ми спростити залежності тут? » Хоча це граматично коректно, але може здатися трохи тупим для когось, хто не знайомий з нюансами конструктивної критики у команді розробників. Ключовим є позитивне оформлення зворотнього зв’ язку і зосередження уваги на тому, * чому * пропонується зміна. Замість того, щоб просто вказувати на проблему («надто розгорнуто»), пояснюючи логіку — «Спрямування цього етапу може поліпшити час збирання і зменшити потенційні помилки під час розгортання» — демонструє розуміння і сприяє співпраці. Аналогічно, в розмовах Slack, де обговорюються проблеми з трубопроводом, такі фрази, як «це не вдається», можуть бути неоднозначними. Краще сказати: « Завдання постійно повертає код виходу non-zero; давайте розглянемо основну причину ». Включення « ненульового » додає певні технічні деталі, які негайно прояснюють проблему.

Іншим частим викликом є чітке описування змін у самих описах запитів на витяг. Розробники часто за замовчуванням роблять короткі резюме, які можуть залишити рецензентів невпевненими щодо мети і обсягу модифікацій. Більш надійний опис включав би такі деталі, як: «Впроваджено новий runner для збільшення одночасності під час пікових часів розгортання. Ця зміна скорочує час виконання збирання приблизно на 15% на основі початкового тестування з імітованим навантаженням. ” Використання « підвищеної одночасності » є звичайним технічним терміном, але явне твердження * чому * це було реалізовано — щоб скоротити час збирання — пов’ язує технічні деталі з реальними перевагами. Крім того, використання точного словника, наприклад, «розгортання» (що стосується процесу випуску) проти просто «запуску» допомагає підтримувати послідовність і уникнути неоднозначності в контексті CI / CD. Пам’ятайте, чітке спілкування не про надмірну розмовність; це про передачу інформації точно і ефективно - будівництво спільного розуміння між членами команди. Також важливо визнати, що різні команди можуть мати трохи відмінні конвенції для документації, тому проактивне пояснення очікувань завжди вигідно.

І, нарешті, не бійтеся просити про пояснення, якщо щось не відразу зрозуміло. Питання «Чи можете ви розібратися в очікуваній поведінці цієї стадії у відношенні до загального конвеєра?» демонструє бажання навчатися і запобігає потенційним неправильним тлумаченням. Більшість досвідчених розробників цінують цей активний підхід і з радістю надають додаткові пояснення. Сфокусування на активному слуханні і підтвердженні розуміння - “Тоді, просто для підтвердження, ви пропонуєте зменшити кількість паралельних завдань, що виконуються на цьому етапі?” - зміцнює розмову і забезпечує, що всі знаходяться на одній сторінці.

# Example: Checking GitLab CI job status using the GitLab API (Illustrative)
curl --header "PRIVATE-TOKEN: <your_private_token>" \
     "https://gitlab.com/api/v4/projects/<project_id>/jobs/123"