Англійська для розробників трубопроводів Tekton

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

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

Task — the smallest reusable unit in Tekton, defining one or more steps that run in sequence inside a single pod, typically doing one job like building an image or running tests. “Keep the build and the push as separate steps within one task, but don’t fold the deploy step in too — deploy belongs in its own task so it can be reused independently.”

** Pipeline ** — визначена послідовність завдань, з явним порядком і залежностями, що Tekton виконує як поток роботи Kubernetes. “Ця конвеєрна програма виконує lint, test і build як три окремі завдання — якщо нам потрібен інший порядок для конвеєрної програми виправлень, ми можемо повторно використовувати ті ж завдання у новому порядку.”

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

** PipelineRun / TaskRun ** — фактичний екземпляр виконання конвеєра або визначення завдання, у якому зберігаються певні параметри, стан і журнали одного виконання, відмінні від самого визначення, яке можна використовувати знову.

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

** Тригер ** — Механізм Tekton для автоматичного запуску PipelineRun у відповідь на зовнішню подію, зазвичай, це webhook з системи керування кодом.

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

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

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

Приклади речення

Перегляд проекту конвеєра: *“Витягування кроку розгортання у власне завдання означає, що конвеєр виправлень може повторно використовувати збирання і тестування без змушування перевизначити розгортання з нуля.” *

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

Обговорення прогалин у автоматизації: “Ми все забуваємо запускати конвеєр перед злиття — додайте тригер на події запитів на завантаження, щоб він запускався автоматично, а не залежав від того, чи хтось пам’ ятає про це.”

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

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

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

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

Переклади: «Переклад з німецької» (нім

Як розробники, що працюють з такими інструментами, як Tekton, ефективне спілкування є найважливішим - не тільки про передачу технічних деталей, але і про те, щоб зробити це чітко англійською мовою. Часто, найбільш складним аспектом є не розуміння * механіки * конвеєра, а перекладання цих знань на точну і дієву мову для вашої команди. У цьому розділі описано тонкі нюанси професійної англійської мови у контексті розробки Tekton, зокрема, як вести обговорення щодо перегляду коду, розмов у Slack і описів запитів на витягування. Однією з поширених пасток є жорстке дотримання буквальних перекладів з вашої рідної мови — це може призвести до неоднозначності і нерозуміння. Розгляньте, що сам технічний жаргон швидко розвивається; чітке, коротке формулювання має більше значення, ніж ідеальне відображення конкретного походження терміну.

Наприклад, коли ви надсилаєте зворотній зв’ язок щодо коментаря перегляду коду, наприклад, « Ця задача потребує кращого оброблення помилок », прямий переклад може бути не настільки ефективним, як пропозиція « Давайте покращимо стійкість цього кроку додаванням всеосяжного журналу помилок і механізмів повторних спроб ». Зауважте, що останній фокусується на * реальних * поліпшення, а не просто на описі проблеми. Аналогічно, в обговореннях Slack щодо налаштування конвеєра, уникайте надто технічних описів, таких як «Ми повинні налаштувати параметр parallel». Замість цього, оформіть його як «Давайте дослідимо збільшення одночасності, щоб поліпшити швидкість збирання - можливо, паралельно з цим етапом». Цей підхід приоритизує розуміння * чому * за зміною, що є ключовим для співпраці. Під час написання описів PR, будьте конкретними щодо * впливу * ваших змін, а не лише того, що ви зробили. Замість « Оновлено робочий простір », спробуйте « Оптимізовано налаштування робочого простору, щоб скоротити час збирання на 15% за допомогою кешування і налаштування розподілу ресурсів. »

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

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

# Example Tekton Task Definition (YAML) - demonstrating CLI usage
task:
  name: "My Awesome Build"
  steps:
    - name: "Build Image"
      image: "ubuntu:latest"
      script: ["echo 'Building...'"]