Стаття також доступна російською (перейти до перегляду).

Зміст:

• Вихідні положення
• Компоненти GitHub Actions та їх взаємодія
  • Робочі процеси
  • Події
  • Завдання
  • Дії
  • Засоби виконання
  • Взаємодія компонентів
• Створення та розгортання PHP-проекту у Службі додатків Azure в режимі CD безперервного розгортання
  • Виконання підготовчих операцій та налаштувань
  • Створення workflow-процесу

Одним із шляхів вдосконалення та оптимізації напрямку DevOps є застосування технології безперервної інтеграції та постачання коду (CI/CD) у процесах підготовки та впровадження програмного забезпечення (ПЗ). Однією з реалізацій вказаної технології є механізм GitHub Actions, котрий забезпечує необхідні робочі умови для CI/CD та, навіть, виходить за її межі, надаючи розширені можливості по управлінню проектами. Розглянемо більш детально характеристики та особливості застосування GitHub Actions на практиці.

Вихідні положення

«Звичайний» процес розгалуженої розробки ПЗ полягає в одночасному та / або послідовному внесенню змін у тіло програми з боку розробників на перших стадіях підготовки ПЗ. Збірка вихідного коду, тестування та виправлення помилок зазвичай переходять на останній етап цього процесу. Саме в цьому і полягає головний недолік «звичайної» методології – накопичення значної кількості помилок на останній стадії розробки. Разом з тим, добре відомо, що вартість запізнілого виправлення помилки у коді буде значно вищою, порівняно із її виправленням на початкових етапах. В результаті збільшується загальна вартість проекту та час його розробки.

Виходом із ситуації може стати рівномірний розподіл та автоматизація робіт по тестуванню та виправленню помилок у коді упродовж усього циклу розробки. Переваги підходу очевидні:    

• Здешевлення процесу виявлення та усунення помилок;

• Застосування стандартних модулів тестування одразу після внесення змін;

• Можливість завжди мати Stable-версію програми, зокрема, для проведення додаткових тестів;

• Робота з кодом у ітеративному режимі зі скороченим часовим циклом.

Вказані переваги є настільки суттєвими, що не викликають сумнівів у необхідності переходу на нову методологію розробки ПЗ, котра отримала назву безперервної інтеграції CI (Continuous Integration). Затримка її масового впровадження була пов’язана зі складністю забезпечення умов для її функціонування та збільшенням витрат на відповідні машинні ресурси.

Вкажемо основні умови для можливості застосування CI на практиці:

Забезпечення зберігання вихідного коду проекту, засобів його збирання та тестування у репозиторії однієї з систем керування версіями;

• Автоматизація циклічних операцій по обслуговуванню проекту;

• Спрощений виклик сценаріїв операцій із зовнішніх програм;

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

Механізм GitHub Actions цілком забезпечує виконання вказаних умов, що дозволяє виконувати всі роботи по проекту, розміщеному у GitHub репозиторії у режимі CI. Нижче буде розглянуто його будову та принципи використання.

Компоненти GitHub Actions та їх взаємодія

Виділимо основні сутності, котрі забезпечують існування середовища CI:

• Робочі процеси (workflows);

• Події (events);

• Завдання (jobs);

• Дії (actions);

• Засоби виконання (runners).

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

Робочі процеси

Робочі процеси визначають тип та послідовність виконання завдань, котрі фіксуються у файлі формату YAML. Файли зберігаються у директорії .github/workflows репозиторію GitHub. Файл будь-якого робочого процесу повинен містити в собі одну або декілька подій та завдання.  

Прикладом робочого процесу може бути створення запиту на витяг результатів проміжного тестування коду або розгортання проекту після кожного випуску релізу.

З метою полегшити роботу із системою девелоперам, GitHub надає безліч варіантів шаблонів за кількома основними напрямками:

Безперервна інтеграція (CI);

• Розгортання (Dev);

• Автоматизація робочих процесів (Automationworkflows);

• Сканування коду (scan code);

• Робочі процеси сторінок (workflows pages).

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

Повну базу шаблонів можна продивитися насайті репозиторію у розділі actions/starter-workflows.

Події

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

Події, котрі відбуваються у репозиторії процесу;

• Події, котрі відбуваються за межами репозиторію та активують подію repository_dispatch;

• Події, що відбуваються у запланований час, тобто, за розкладом.

Завдання

Компонент реалізується за допомогою оператора job та слугує для визначення етапів виконання робочого процесу у межах одного й того ж засобу виконання, наприклад, у віртуальній машині сервера Ubuntu. Кожний етап прив’язується до сценарію або дії, котрі будуть почергово виконуватися. У межах завдання йде його додаткова деталізація за допомогою оператору Steps, котрий буде розглянутий нами пізніше.

Дії

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

Код зберігається у файлі action.yml. У файлі робочого процесу він під’єднується за допомогою оператору actions.

Компонент може бути попередньо створений користувачем, налаштовуватися у процесі роботи або отриманий із GitHub Marketplace.

Засоби виконання

Це середовище, у котрому відбувається виконання всіх робочих процесів після їх активації. На кожний процес виділяється одна віртуальна машина. Реалізується за допомогою оператору run.GitHub надає наступні види серверів для утворення віртуальних середовищ: Microsoft Windows, macOS та Linux Ubuntu.

Окрім вказаних «стандартних» серверів система дозволяє під’єднати та використовувати будь-які власні сервери зі своїм середовищем виконання.

Взаємодія компонентів

 Принцип взаємодії компонентів GitHub Actionsнаведений на Малюнку 1. У випадку виникнення події Event на вході робочого процесу, активуються процеси виконання завдань, визначених компонентами Jobs1 та Jobs2. Завдання у свою чергу розбиті на кроки: Step1-Step4 та Step1-Step3 відповідно. Кожне з завдань виконується лише у своєму середовищі виконання – Runner1 та Runner2 відповідно. 

Малюнок 1. Взаємодія компонентів GitHub Actions.

Розглянемо взаємодію компонентів на практичному прикладі. Наприклад, файл робочого процесу docker-image.yml із бази GitHub репозиторію реалізує розгортання системи Docker наVPS-серверіUbuntu. У якості події тут вказано значення push (відправка коду у гілку розробки), а завдання jobs визначає послідовність кроків для виконання операцій розгортання системи Docker на сервері. (див. скрин).

name: Docker Image CI
 
on:
push:
  branches: [ $default-branch ]
    pull_request:
  branches: [ $default-branch ]
jobs:
build:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v4
  - name: Build the Docker image
    run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)

Створення та розгортання PHP-проекту у Службі додатків Azure в режимі CD безперервного розгортання   

Розіб’ємо процес вирішення задачі на два етапи:

• Виконання підготовчих операцій та налаштувань;

• Створення workflow-процесу.

Виконання підготовчих операцій та налаштувань

Перед формуванням файлу робочого процесу GitHub Actions необхідно виконати підготовчі дії у наступному порядку:

Створити план вказаної Служби додатків;

• Створити додаток;

• Створити секрет та налаштувати профіль публікації в Azure;

• Налаштувати середовище розгортання.

Створення плану. Для цього можна скористатися сервісом Azure CLI:

Bash
 
az appservice plan create \
   --resource-group NEW_GROUP \
   --name NEW_NAME_PLAN \
   --is-linux

Замість NEW_GROUPнеобхідно вказати ідентифікатор існуючої групи ресурсів. Замість NEW_NAME_PLAN – нове ім’я плану. Деталі можна знайти у відповідному  розділі документації по Azure CLI.

Створення додатку. Тут також можна використати можливості Azure CLI та середовище PHP:

Bash
az webapp create \
--name NEW_NAME_WEB_APP \
--plan NEW_NAME_PLAN \
--resource-group NEW_GROUP 
--runtime "php|8.3"

Тут NEW_NAME_WEB_APP – нове ім’я для веб-додатку. Значення усіх інших параметрів повинні відповідати своїм налаштуванням.

Створення секрету та налаштування профілю публікації. Налаштування профілю публікації описано у цьому розділі документації по Azure. Після цього у GitHub-репозиторії необхідно створити секрет AZURE_WEBAPP_PUBLISH_PROFILE із даними налаштованого профілю публікації.

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

Створення workflow-процесу

Нижче представлений вміст сформованого файлу робочого процесу по створенню та розгортанню PHP-проекту в службі додатків Azure. 

YAML

name: Build and deploy of the project PHP in service Azure
 
env:
  AZURE_WEBAPP_NAME: NEW_NAME_WEB_APP # Задається ім'я нашого веб-додатку
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # Задається шлях до веб-додатку
  PHP_VERSION: '8.x'                  # Встановлюється версія PHP
 
on:
  push:                           # Процес активується одразу після відправлення змін у головну гілку тіла програми
 
branches:
  - main
 
jobs:
  build:
runs-on: ubuntu-latest # Визначається засіб виконання
 
steps:
  - uses: actions/checkout@v4 # Перевіряється користувацький репозиторій в середовищі виконання. Застосовується кожного разу, коли робочий процес використовує код з репозиторію.
 
  - name: Setup PHP
    uses: shivammathur/setup-php@1f2e3d4c5b6a7f8e9d0c1b2a3e4f5d6c7b8a9e0f
    with:
      php-version: ${{ env.PHP_VERSION }}
 
  - name: Check if composer.json exists
    id: check_files
    uses: andstor/file-existence-action@2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b
    with:
      files: 'composer.json'
 
  - name: Get Composer Cache Directory
    id: composer-cache
    if: steps.check_files.outputs.files_exists == 'true'
    run: |
      echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT
 
  - name: Dependency caching
    uses: actions/cache@v3  # Запускається дія по кешуванню залежностей
    if: steps.check_files.outputs.files_exists == 'true'
    with:
      path: ${{ steps.composer-cache.outputs.dir }}
      key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
      restore-keys: |
        ${{ runner.os }}-composer-
 
  - name: Install composer if composer.json exists
    if: steps.check_files.outputs.files_exists == 'true'
    run: composer validate --no-check-publish && composer install --prefer-dist --no-progress
 
  - name: Setting up artifacts
    uses: actions/upload-artifact@v4 # Активується дія по завантаженню артифактів
    with:        
      name: php-app
      path: .
 
  deploy:              # Конфігурується процес розгортання у визначеному засобі виконання 
runs-on: ubuntu-latest
needs: build
environment:       # Налаштовування середовища розгортання веб-додатку   
  name: 'production'
  url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
 
steps:
  - name: Loading an artifact based on the build results
        uses: actions/download-artifact@v4 # Завантаження артефактів за результатами збірки
    with:
      name: php-app
 
  - name: 'Deploy in service Azure'
    id: deploy-to-webapp
    uses: azure/webapps-deploy@85270a1854658d167ab239bce43949edb336fa7c
    with:        
      app-name: ${{ env.AZURE_WEBAPP_NAME }}
      publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
      package: .

Підписуйтесь на наш телеграм-канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів.

Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

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

Дата: 20.11.2024 Автор: Олександр Ровник #automation#devops#github#php

Голосування 1 2 3 4 5