nmk

Лабораторна робота №9 (2 години)

Тема: Фінальна збірка та деплоймент. Оптимізація бандлу та розміщення проєкту в мережі Інтернет з налаштуванням CI/CD пайплайну.

Мета: Підготувати створений React-додаток до Production-середовища; навчитися аналізувати та оптимізувати розмір бандлу (Bundle Size); налаштувати процес Continuous Integration (CI) за допомогою GitHub Actions для автоматичного запуску тестів; розгорнути (Deploy) фінальний продукт на сучасній хмарній платформі (Vercel або Netlify).

Технологічний стек: React, Vite, Node.js, Vercel / Netlify / GitHub Pages, GitHub Actions (YAML).

Завдання

  1. Виконати статичну типізацію та виправити всі попередження лінтера (ESLint), підготувавши код до Production-збірки.
  2. Створити конвеєр (Workflow) у GitHub Actions для автоматичного запуску Unit-тестів (з Лаб №8) при кожному PUSH у гілку main.
  3. Виконати команду збірки (npm run build) та проаналізувати згенеровану папку /dist.
  4. Підключити GitHub-репозиторій до сервісу хмарного розгортання Vercel (або аналогу) та налаштувати автоматичний Continuous Deployment (CD).
  5. Налаштувати правила маршрутизації (Rewrites) на сторонньому сервері для коректної роботи React Router (запобігання помилці 404 при прямому переході за посиланнями).

Хід виконання роботи

Крок 1. Підготовка коду та лінтинг

Перед деплоєм професійний код не повинен містити попереджень.

  1. Запустіть лінтер:
npm run lint
  1. Запустіть перевірку типів TypeScript (з Лаб №7):
npx tsc --noEmit
  1. Виправте всі червоні помилки у консолі. Більшість із них можна автоматично виправити командою npm run lint -- --fix.

Крок 2. Налаштування CI у GitHub Actions

Ми створимо пайплайн, який буде автоматично тестувати наш код на серверах GitHub під час кожного коміту (Commit).

  1. У корені вашого проєкту створіть папку .github/workflows/.
  2. Всередині створіть файл main.yml:
name: CI Pipeline

# Спрацьовує при пуші в гілку main або створенні Pull Request
on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build-and-test:
    runs-on: ubuntu-latest # Запускаємо віртуальну Linux-машину

    steps:
      - name: Клонування репозиторію
        uses: actions/checkout@v3

      - name: Встановлення Node.js 18
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: "npm" # Кешуємо залежності для прискорення пайплайну

      - name: Встановлення пакетів
        run: npm ci # Чисте встановлення на CI замість npm install

      - name: Перевірка лінтером
        run: npm run lint

      - name: Перевірка типів TypeScript
        run: npx tsc --noEmit

      - name: Запуск тестів
        run: npm run test -- --run # Завершуємо процес після виконання тестів

Зробіть коміт і відправте (push) ці зміни до вашого GitHub репозиторію. Зайдіть у вкладку Actions вашого репозиторію на сайті GitHub, щоб побачити зелені галочки успішного виконання кроків.

Крок 3. Збірка (Build) додатку

Для підготовки до деплою Vite має згенерувати оптимізовані, мініфіковані статичні файли (HTML, CSS, JS).

  1. Запустіть:
npm run build
  1. Подивіться на вивід терміналу. Vite покаже список згенерованих файлів у папці dist (або build) і розмір бандлу (зазвичай index-xxxxx.js файл). Факт: Розмір index.js не повинен перевищувати 300-500 KB для якісного першого завантаження (First Contentful Paint).

Крок 4. Деплоймент на Vercel (Continuous Deployment)

Vercel — це ідеальна PaaS-платформа для хостингу Frontend-додатків, створена авторами Next.js та Vite.

  1. Зареєструйтесь на сайті Vercel.com (бажано через ваш GitHub акаунт).
  2. Натисніть “Add New” -> “Project”.
  3. Надайте Vercel дозвіл на читання вашого GitHub і оберіть репозиторій з вашими лабораторними роботами.
  4. На сторінці “Configure Project”:
    • Framework Preset: Має автоматично визначитися як Vite.
    • Build Command: Має бути npm run build.
    • Output Directory: Має бути dist.
  5. Натисніть кнопку “Deploy”.

Vercel самостійно скачає ваш код, збере його (Production Build) і видасть публічне посилання (URL) на ваш сайт. Щоразу, коли ви будете комітити в main, Vercel автоматично (у фоні) перезбиратиме ваш проєкт за лічені секунди (ЦЕ І Є CD!).

Крок 5. Вирішення проблеми SPA та React Router (Помилка 404)

Оскільки ви використовуєте react-router-dom (з Лаб №4), ви можете зіткнутися з класичною проблемою SPA: Якщо користувач перейде на ваш Vercel-сайт і натисне кнопку “Профіль”, URL зміниться на vash-site.vercel.app/profile (і все запрацює). АЛЕ, якщо користувач оновить сторінку (F5) прямо на vash-site.vercel.app/profile, сервер Vercel поверне помилку 404 (Not Found). Чому? Сервер намагатиметься знайти фізичний файл /profile/index.html у вашій папці dist, якого не існує (бо існує тільки один index.html від SPA).

Вирішення для Vercel: Створіть у корені вашого проєкту файл vercel.json:

{
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": "/index.html"
    }
  ]
}

Це правило інструктує сервер Vercel: “Всі невідомі запити перенаправляти напряму на index.html, а там вже React Router сам розбереться, який шлях (Route) відмалювати”.

_(Прим. Якщо ви деплоїте на Netlify, вам потрібно створити файл public/_redirects з вмістом /_ /index.html 200)*.

Контрольні запитання

  1. Поясніть принципову різницю (на архітектурному рівні) між файлами вихідного коду (в папці src з TypeScript та JSX) і файлами, що генеруються в папці dist командою npm run build. Який процес відбувається з кодом між цими кроками?
  2. В чому полягає філософія та основні технічні переваги патерну (підходу) Continuous Integration / Continuous Deployment (CI/CD) порівняно з ручним розгортанням коду розробником на сервер через FTP-клієнт?
  3. Яка ключова мета використання команди npm ci на відміну від npm install у файлі конфігурації пайплайну на CI-сервері (GitHub Actions)?
  4. Проаналізуйте з інженерної точки зору “Помилку 404”, яка виникає в архітектурі Single Page Application (SPA), якщо ми прямо запитуємо внутрішній роутерний шлях з сервера (наприклад, mysite.com/dashboard/users). Який механізм React Router (історія браузера) лежить в основі цього конфлікту і логіки створення файлу vercel.json?
  5. Чому конфігурація Github Actions (main.yml) має бути написана до того як ми віддамо платформі доступ на об’єднання гілок коду (Pull Requests) в main і які метрики якості повинні виконуватися як обов’язкова умова (напр., лінтинг, тести)?

Вимоги до звіту

  1. У Classroom необхідно надіслати:
    • Лише 1 посилання на GitHub-репозиторій (переконайтеся, що файл main.yml присутній у папці .github/workflows). На скріншоті репозиторію вкладка Actions повинна містити успішні (зелені) запуски пайплайну.
    • Лише 1 посилання на розгорнутий Vercel/Netlify фінальний проєкт (додаток має бути “клікабельним”, і навігація не повинна видавати помилку 404 при оновленні сторінки).
  2. У файлі lab_09.md дати вичерпні відповіді на 5 контрольних запитань.