GitHub Actions - кращі КІ на 2021 рік

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

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

Що таке CI (Continuous Integration)

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

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

Як саме працює КІ

Основою КІ є конфігураційний файл, де ми визначаємо його поведінку та реакцію на події. У випадку з GitHub достатньо створити допоміжний каталог .github/workflows і створити всередині нього будь-який файл з розширенням .yml. GitHub буде аналізувати його з кожним коммітом і виконувати за необхідності.

Уявімо, що ми хочемо визначити новий конфігураційний файл з певним завданням. Оскільки це завдання, яке буде виконуватися безпосередньо GitHub або іншим середовищем на віртуальній машині, нам потрібно визначити базові речі про середовище, в тому числі:

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

У випадку з робочими місцями, ми далі визначаємо:

• Назва роботи
• Виконавче середовище (як правило, назва операційної системи)
• Етапи будівництва контейнера

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

В рамках виконання конкретних кроків завдання нам необхідно запустити окремі команди, які побудують інсталяцію щойно встановленої нами операційної системи. Так у випадку з PHP важливо буде встановити лише мову PHP (і вказати версію), клонувати репозиторій проекту в runner, встановити залежності проекту (найчастіше Composer), і запустити сам тест.

Навіщо використовувати GitHub Actions (CI)?

В ІТ-спільноті існує поширений забобон, що Microsoft - це корпорація зла, яка робить неякісні речі. Однак у випадку з GitHub Actions це зовсім не так, адже вони мають, цілком об'єктивно, найкращу платформу для КІ у світі.

Фундаментальною перевагою GitHub CI є простота та елегантність нотації. За допомогою всього декількох рядків ви можете налаштувати власне тестове середовище і керувати ним автоматично, навіть без попередніх знань. При цьому величезною перевагою я вважаю швидкість опрацювання конкретних завдань. Наприклад, тест на codestyle (форматування коду) та PhpStan (перевірка типів даних, логіки та загальної коректності) може бути оцінений GitHub Actions на звичайному проекті менш ніж за 50 секунд, тоді як GitLab, наприклад, оцінює той самий тест майже за 8 хвилин! Інші рішення, такі як Travis, є відносно дорогими, і більшість розробників все одно не оцінюють переваги їхніх спеціальних функцій.

Підготовлені заходи

GitHub має велику базу готових дій та пакетів, які можна одразу використовувати. Це, як правило, операційні системи, мови програмування або бібліотеки спільноти.

Базу акцій можна знайти прямо в [Маркетплейсі] (https://github.com/marketplace?type=actions), наприклад, моя улюблена акція - [Відправка SMS у разі невдачі через Twillio] (https://github.com/marketplace/actions/twilio-sms).

Готові приклади

Дуже багато прикладів [я публікую у власних репозиторіях] (https://github.com/baraja-core), де можна прозоро побачити, яку конкретно конфігурацію я використовую.

Наприклад, у лютому 2021 року я використовував цю конфігурацію для перевірки стилю коду в проєкті:

name: Coding Style

on:
  push:
    branches:
      - master
  pull_request:
    types: [ assigned, opened, synchronize, reopened ]
  schedule:
    - cron: '1 * * * *'

jobs:
  nette_cc:
    name: Nette Code Checker
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: shivammathur/setup-php@v2
        with:
          php-version: 7.4
          coverage: none

      - run: composer create-project nette/code-checker temp/code-checker ^3 --no-progress
      - run: php temp/code-checker/code-checker --strict-types --no-progress

  nette_cs:
    name: Nette Coding Standard
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: shivammathur/setup-php@v2
        with:
          php-version: 8.0
          coverage: none

      - run: composer create-project nette/coding-standard temp/coding-standard ^3 --no-progress --ignore-platform-reqs
      - run: php temp/coding-standard/ecs check src

Цей конфігураційний файл встановлює останню версію Ubuntu (runs-on: ubuntu-latest), клонує репозиторій проекту (uses: actions/checkout@v2), встановлює PHP (uses: shivammathur/setup-php@v2) версії 7.4 (php-version: 7.4), встановлює пакет code-checker, а потім запускає завдання через PHP.

Ще кілька зауважень для користувачів, які не настільки досвідчені:

• При кожному запуску CI буде запускати віртуальну машину з повноцінною операційною системою, яку можна використовувати для виклику команд в Терміналі так само, як, наприклад, ваш сервер
• Для перевірки результатів тестування використовуються так звані коди повернення, визначені самою ОС Linux. Зокрема, коли програма повертає 0 (нуль), це означає успіх, а будь-яке інше число - невдачу. Наприклад, так само працюють shell-скрипти
• Коли ми хочемо написати власний тест або більш складну логіку, ми можемо використовувати PHP, наприклад, і запустити це як CLI-задачу (команда php file.php), яка запуститься і може робити все, на що вона має права (працювати з файлами, спілкуватися через Інтернет, виводити на екран, ...)
• Під час роботи КІ весь висновок фіксується на екрані і може бути переглянутий безпосередньо у веб-браузері
• КІ не є інтерактивним, хоча Термінал може виконувати інтерактивні операції з користувачем, КІ не підтримує цього і повинен бути розроблений як завдання, яке іноді запускається, а іноді завершується
• Для роботи контейнера КІ визначено таймаут в 1 годину, якщо за цей час все не буде оброблено (наприклад, програма зависне), то вся система буде примусово завершена і буде повідомлено про помилку
• GitHub може запускати завдання CI автоматично за допомогою cron, проте дуже часто він не запускає їх в потрібний час, а запускає із затримкою
• Ви також можете загорнути всю логіку CI в Docker контейнер і запускати її локально на всіх машинах або на сервері, наприклад
• Якщо вам потрібно отримати доступ до секретної інформації (наприклад, пароль до бази даних), є можливість визначити секретні змінні безпосередньо в GitHub, а в CI вони будуть доступні під час виконання.
• Розгортання на веб-сервер завжди краще проводити по SSH
• Загальний час виконання завдань КІ обмежений, як правило, до 2 тис. хвилин на місяць (дуже часто вам цього буде достатньо, я ніколи не використовував його, тому що одне завдання виконується максимум одну хвилину), або ви можете збільшити час за окрему плату
• Ви також можете розмістити CI бігуни на своєму сервері і обійти ліміт хвилин, але дуже ймовірно, що ваш сервер не буде набагато швидшим, оскільки Microsoft інвестувала значні кошти в свій Azure, де розміщений GitHub Actions, і він працює на дуже потужних серверах
• Дуже часто зручно встановлювати окремі пакети саме для CI (зазвичай це PhpStan і різні функції безпеки), тому помістіть їх в секцію composer.json файлу require-dev, щоб вони не встановлювалися в конкретному проекті як обов'язкова залежність

Додатки та боти GitHub

На відміну від інших репозиторіїв, GitHub підтримує так звані GitHub Apps та боти для автоматизації. Це велика база готових ботів, які можуть виконувати автоматизовані операції над вашими проектами (навіть без CI) і коли вони з чимось зіткнуться, то, наприклад, подадуть issue або відправлять pull request з виправленням.

Я особисто ним користуюся і вам рекомендую:

• Dependabot - автоматична перевірка залежностей в Composer, наприклад, коли виходить нова версія пакетів, які ви використовуєте, і є сумісною, він автоматично надсилає pull request
• Codecov - перевіряє покриття коду за допомогою автоматичних тестів і показує, які частини коду ще не покриті
• Snyk - автоматична перевірка на наявність вразливостей в системі безпеки
• Imgbot - автоматична оптимізація розміру зображень

Багато інших додатків можна знайти на [Marketplace] (https://github.com/marketplace?type=apps).

Більше корисних порад та підказок

Я дуже полюбив використовувати завдання автоматизації в GitHub.

У всіх моїх репозиторіях налаштовані автоматичні перевірки, тому, коли я відправляю будь-який комміт (або будь-хто інший в спільноті), я отримую зворотній зв'язок в реальному часі про те, чи були порушені якість коду (стиль коду і PhpStan), безпека і багато іншого.

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

З часом, протестувавши різні конфігурації, я прийшов до висновку, що ідеальним мінімальним налаштуванням вважаю наступні залежності до Composer:

• phpstan/phpstan - перевірка коду на коректність і логічність
• tracy/tracy - звітність про помилки високого рівня та ведення журналу помилок
• phpstan/phpstan-nette - Розширення Phpstan і спеціальності в Nette
• spaze/phpstan-disallowed-calls - блискуча бібліотека Міхала Спейсека, яка обробляє (не)використання небезпечних речей в коді (від забутих дампів змінних до можливості запуску користувацького рядка як команди оболонки)
• roave/security-advisories - перевірка на встановлення небезпечних версій пакетів (якщо в певному пакеті знайдено уразливість безпеки або випущено CVE, то цей пакет буде запобігати встановленню пошкодженої версії)

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

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

Тому що в профілактиці та автоматизації - величезний потенціал!

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Kontakt