Як створити робочі цикли для CI за допомогою дій GitHub?

Завершено

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

Щоб реалізувати цей процес, ви дізнаєтеся, як це зробити:

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

Створення робочого циклу на основі шаблону

Щоб створити робочий цикл, часто можна почати з використання шаблону. Шаблон містить типові завдання та кроки, попередньо налаштовані для певного типу автоматизації, який ви впроваджуєте. Якщо ви не знайомі з робочими циклами, завданнями та кроками, перегляньте Автоматизувати завдання розробки за допомогою модуля Дій GitHub.

На головній сторінці сховища GitHub виберіть Елемент Дії, а потім – Новий робочий цикл.

На сторінці Вибір робочого циклу можна вибрати шаблони різних типів. Одним із прикладів є шаблон Node.js. Шаблон Node.js інсталює Node.js і всі залежності, створює вихідний код і запускає тести для різних версій Node.js. Інший приклад – шаблон пакета Python , який інсталює Python та його залежності, а потім виконує тести, зокрема lint, у кількох версіях Python.

Щоб почати з шаблону робочого циклу Node.js, у полі пошуку введіть Node.js.

У результатах пошуку в області Node.js натисніть кнопку Настроїти.

Файл node.js.yml для проекту створюється на основі шаблону:

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

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

У цьому робочому циклі виконується одне завдання, позначене атрибутом job .

Атрибут runs-on визначає, що робочий цикл для операційної системи запускається ubuntu-latest. Атрибут node-version указує, що існує три збірки, кожна з яких для Node.js версії 14.x, 16.x і 18.x. Цей matrix атрибут докладно описано в модулі.

У атрибуті jobs виконайте дії з GitHub Actions/checkout@v3 , щоб отримати код зі сховища на віртуальну машину (VM) і дії/setup-node@v3 , щоб налаштувати правильну версію Node.js. Укажіть, що потрібно перевірити три версії Node.js за допомогою атрибута ${{ matrix.node-version }} . Цей атрибут посилається на матрицю, визначену раніше. Атрибут cache визначає диспетчер пакетів для кешування в каталозі за промовчанням.

Остання частина цього кроку виконує команди, які Node.js проектів. Команда npm ci інсталює залежності package-lock.json від файлу. npm run build --if-present запускає сценарій збірки, якщо він існує. npm test запускає платформу тестування. Цей шаблон містить етапи створення та тестування в одному й тому самому робочому місці.

Щоб дізнатися більше про npm, перегляньте документацію npm:

• інсталяції npm
• npm виконати
• тестування npm

Команда розробників може скористатися робочими циклами для повторного використання, щоб оптимізувати та стандартизувати повторювані кроки автоматизації. Використовуючи робочі цикли для повторного використання, ви можете зменшити резервування, підвищити зручність підтримки та забезпечити узгодженість трубопроводів безперервної інтеграції або безперервного розгортання (CI/CD).

Уникнення дублювання за допомогою робочих циклів для повторного використання

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

Робочі цикли для повторного використання – це спеціальні робочі цикли Дій GitHub, які можуть викликати інші робочі цикли, як і функції програмування. Вони створюються для надання спільного доступу до повторюваної логіки, наприклад етапів побудови, тестування процедур або стратегій розгортання. Створивши робочий цикл для повторного використання, ви можете посилатися на нього з будь-якого іншого робочого циклу в тому самому сховищі або навіть у різних репозиторіях.

Навіщо використовувати робочі цикли для повторного використання?

Нижче наведено переваги використання робочих циклів для повторного використання.

• Послідовність. Teams може дотримуватися однакових стандартів автоматизації в усіх проектах.
• Ефективність. Замість копіювання та вставлення кроків просто наведіть вказівник миші на робочий цикл для повторного використання.
• Простіше оновлення. Коли процес змінюється, наприклад додаванням тестового кроку, ви оновлюєте його в одному розташуванні. Потім усі робочі цикли, які використовують перевагу робочого циклу автоматично.
• Масштабованість. Робочі цикли для повторного використання ідеально підходять для команд платформи або DevOps, які керують кількома службами.

Далі дізнайтеся, як використовувати робочі цикли для повторного використання для вдосконалення проектів.

Упровадження робочих циклів для повторного використання

Щоб використовувати робочі цикли для повторного використання:

1. У папці сховища створіть робочий цикл для повторного використання. Файл містить кроки автоматизації, до яких потрібно надати спільний доступ, наприклад типові кроки, пов'язані з тестуванням, створенням і розгортанням.
2. Явно активуйте повторне використання робочого циклу, налаштувавши його за допомогою workflow_call події.
3. У основних робочих циклах (робочі цикли абонента) посилайтеся на цей файл для повторного використання та надайте необхідні входи або секрети.

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

Приклад

Уявіть, що ваша організація має 10 мікросервісів. Усі 10 мікросервісів мають виконати такі самі кроки:

• Запуск тестів
• Кодворк
• Розгортання в певному середовищі

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

Якщо використовуються робочі цикли для повторного використання:

• Процес визначається один раз у центральному файлі (наприклад, у ci-standard.yml).
• Ви викликаєте цей файл із власного робочого циклу кожної мікросервіси, переходячи в такі змінні, як середовище або ім'я програми.

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

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

Практичні поради

• Централізуйте робочі цикли для повторного використання в одному сховищі, якщо плануєте надавати до них спільний доступ у командах.
• Використовуйте гілки або позначки для версії робочих циклів (наприклад, використовуйте @v1), щоб за потреби можна було легко відкотити зміни.
• Ввід документів і секрети чітко. Робочі цикли для повторного використання часто залежать від входів і секретів. Командам потрібно знати, яку інформацію слід використовувати.
• Якщо потрібно повторно використати лише кілька кроків, об'єднайте робочі цикли для повторного використання зі складеними діями, а не створюйте повний робочий цикл.

Робочі цикли для повторного використання – це потужний спосіб забезпечити узгодженість, зменшити дублювання та масштабувати практики DevOps у будь-якій команді розробників. Незалежно від того, чи ви керуєте одним сховищем, мікросервісами або бібліотеками з відкритим кодом, робочі цикли для повторного використання можуть спростити автоматизацію, тому ci/CD – це швидше, чистіше та простіше керувати.

Настроювання шаблонів робочих циклів

На початку цього модуля ви розглянули сценарій, у якому потрібно налаштувати CI для своєї команди розробників. Шаблон Node.js – це чудовий початок, але його потрібно налаштувати відповідно до вимог команди. Потрібно націлюватися на різні версії Node.js та різних операційних систем. Крім того, потрібно, щоб етапи створення та тестування були окремими завданнями.

Ось приклад настроюваного робочого циклу:

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

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

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

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true