🧊 Интенсив по DevOps

От основ до production-ready проекта

Ты освоил основы CI/CD и хочешь большего? Если эта тема тебя захватила и ты хочешь прокачать свои навыки, тогда рекомендуем тебе пройти продвинутый курс по DevOps, который станет твоим следующим шагом к экспертизе.

Погрузись в мир DevOps и автоматизации с практическим подходом! В данном интенсиве ты пройдёшь путь от знакомства с DevOps-культурой до запуска полноценного production-ready проекта с автоматическим деплоем.

Что тебя ждёт:

1 — освоишь основы контейнеризации: установишь Docker, научишься работать с Docker Compose и поймёшь, как DevOps-подход ускоряет разработку.

2 — настроишь CI/CD-пайплайны с нуля: разберёшься в теории непрерывной интеграции и доставки, освоишь GitHub Actions с правильной работой с секретами, и запустишь свой первый автоматический деплой.

3 — соберёшь реальный проект: создашь монорепозиторий с Frontend (React) и Backend (Node.js), поднимешь и настроишь NGINX, и настроишь полностью автоматизированный деплой через Docker Compose и GitHub Actions.

Практика, реальные кейсы и навыки, которые можно сразу применить в работе! 🚀

🏗️ Основы DevOps, CI/CD для Front-end, GitHub Actions

Важное замечание от ментора⚠️

1. 🚀 Введение: От локальной разработки к глобальной доступности

Мы живём в мире localhost, но настоящая магия начинается, когда приложение уходит «в свет» и становится доступным пользователям по всему миру 🌍.

Понимание того, как ваш код попадает на сервер и превращается в работающий продукт — это то, что превращает разработчика в инженера.

Этот навык критически важен для:

• 💼 портфолио
• 🧪 тестовых заданий
• 🧱 уверенного понимания инфраструктуры

Сегодня мы настроим полноценный CI/CD-пайплайн через GitHub Actions и осмыслим весь процесс доставки.

2. 🏗️ Сборка приложения: Превращение исходников в продукт

Код, который мы пишем (TSX, CSS modules, TypeScript), — сырой материал. Он не может запускаться браузером напрямую.

Нам нужен этап сборки — превращение этого кода в оптимизированный, минифицированный, готовый к продакшену артефакт.

2.1. ⚙️ Команды npm run dev и npm run build

npm run dev

• режим разработки
• запускает локальный dev-сервер (Vite)
• hot reload 🔥 ( «горячая перезагрузка» )
• не создаёт файлов сборки

npm run build

• создаёт производственную версию приложения
• компиляция, транспиляцию, минификация, оптимизация
• кладёт результат в /dist 📦

2.2. 📁 Артефакт сборки: папка dist

После npm run build появляется папка dist — это и есть приложение.

Содержимое:

• index.html

• минифицированные .js файлы

• минифицированные .css файлы

  ❗

  Важно: dist и node_modules — производные директории → их нельзя хранить в Git. Добавьте их в .gitignore.

3. 🌐 Хостинг: Где живёт приложение

Чтобы приложение заработало в интернете, его файлы должны быть размещены на сервере.

3.1. 🗂️ Что такое хостинг статики?

Хосинг статики - простой сервер, основная задача которого — по запросу пользователя отдать ему статические файлы: HTML, CSS и JavaScript. Популярные серверы для этих целей:

• Nginx
• Caddy

3.2. 💸 GitHub Pages — бесплатное решение

GitHub Pages идеально подходит для:

• портфолио 💼
• документации 📚
• демо-проектов
• SPA 🚀

Он даёт бесплатный адрес вида:

 your-username.github.io/repository-name

4. ✋ Ручное развертывание на GitHub Pages

Прежде чем автоматизировать, нужно понять механику.

4.1. Процесс ручного деплоя 🚀

Процесс состоит из следующих шагов:

1. Создание отдельного репозитория. 🗂️ Для этого метода мы создаём новый, чистый репозиторий на GitHub. Он будет предназначен исключительно для хранения скомпилированных файлов из папки dist.

2. Сборка проекта. 🏗️ Локально в своём проекте выполняем команду:

npm run build

Эта команда генерирует папку dist с готовым приложением.

3. Копирование файлов 📁➡️📦

Копируем содержимое папки dist (а не саму папку!) в корень нашего нового репозитория, чтобы GitHub Pages было проще найти index.html.

4. Коммит и пуш 🔧📤

Фиксируем изменения и отправляем их в удалённый репозиторий:

git add .
git commit -m
git push

5. Активация GitHub Pages 🌐✨

В настройках репозитория на GitHub переходим во вкладку Pages. В разделе Source выбираем:

• Deploy from a branch
• Ветка: main

Сохраняем настройки.

После этих действий GitHub запустит процесс развертывания, и через несколько минут ваше приложение будет доступно по ссылке.

4.2. ❌ Ошибки путей — почему страница пустая?

Если появляется 404 — это нормально.

Проблема: Vite ожидает, что проект лежит в корне домена (/). GitHub Pages кладёт его в подпапку (/repo-name/).

Решение: В vite.config.js добавить:

export default defineConfig({
  base: "/имя-репозитория/",
})

4.3. 🔥 Самая важная часть: Утечка API-ключа

Если вы добавили ключ в код и закоммитили — всё, ключ скомпрометирован навсегда.

Даже если вы его удалите, он всё равно остаётся в истории Git.

🚀 5. Автоматизация с CI/CD: Концепция и компоненты

🔍 5.1. Расшифровка CI/CD

CI — Continuous Integration (Непрерывная интеграция)

Разработчики часто отправляют (пушат) код в общий репозиторий — и каждый пуш автоматически запускает проверки.

CD — Continuous Delivery / Deployment (Непрерывная доставка / развертывание)

Код проходит сборку, тестирование и автоматически доставляется на сервер после успешной интеграции.

🖥️ 5.2. Три ключевых сервера в CI/CD

Чтобы понять архитектуру, представим её как систему из трёх компонентов:

1. Git-сервер (GitHub) Хранилище кода: TSX, CSS-модули, конфиги и т.д.

2. CI/CD-сервер (GitHub Actions) Оркестратор, который реагирует на пуши, забирает код и выполняет пайплайн.

3. Хостинг-сервер (GitHub Pages) Конечная точка, на которую выкладывается папка dist.

Далее мы настроим главное звено — GitHub Actions.

⚙️ 6. GitHub Actions: автоматический пайплайн

GitHub Actions позволяет создавать CI/CD пайплайны с помощью workflow-файлов — сценариев, которые выполняются автоматически.

📂 6.1. Структура workflow-файла (.yml)

Файл deploy.yml лежит в папке: .github/workflows/

Основные элементы:

• name — название пайплайна
• on — триггер, который запускает процесс (например, push в main)
• jobs — список задач, которые необходимо выполнить.
• runs-on — виртуальная среда (ubuntu-latest), в которой будет выполняться задача.
• steps — последовательность команд
• permissions — права workflow для взаимодействия с репозиторием

🛠️ 6.2. Пошаговая настройка пайплайна

Стандартный пайплайн развёртывания:

1. actions/checkout@v4 — клонирует репозиторий
2. actions/setup-node@v4 — устанавливает Node.js
3. npm install — устанавливает зависимости
4. npm run build — создаёт папку dist
5. upload-pages-artifact@v3 — упаковывает артефакт
6. deploy-pages@v4 — загружает артефакт на GitHub Pages

Для корректной работы нужно выдать workflow необходимые права через permissions.

📝 Пример файла

name: MusicFun Deploy
 
on:
  push:
    branches: [main]
 
permissions:
  contents: read
  pages: write
  id-token: write
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm run build
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: "./dist"
      - uses: actions/deploy-pages@v4

🔐 6.3. Управление секретами: профессиональный подход

Автоматизация позволяет безопасно работать с API-ключами с помощью переменных окружения. Это исключает риск утечки секретов и делает проект профессионально оформленным.

🗂 1. Файл .env

В корне проекта создаётся файл:

VITE_API_KEY=ваш_секретный_ключ

Для Vite важно, чтобы ключ начинался с префикса VITE_, иначе он не попадёт в окружение фронтенда.

📄 2. Файл .gitignore

Необходимо добавить .env в .gitignore:

Это гарантирует, что ваши секреты никогда не попадут в репозиторий — ни случайно, ни по ошибке.

💻 3. Доступ к ключу в коде

Получение значения переменной:

import.meta.env.VITE_API_KEY

🛡️ 4. Безопасная реализация

Просто подставлять undefined в заголовок — плохая практика. Правильный подход — добавлять заголовок только если ключ действительно существует.

Поэтому создаём вспомогательную функцию, которая формирует заголовки безопасным образом:

const prepareHeaders = () => {
  const apiKey = import.meta.env.VITE_API_KEY
  if (!apiKey) return undefined
 
  return {
    "api-key": apiKey,
  }
}

🧼 5. Почему это важно: чистый и безопасный код

Такой подход делает код:

• чистым 🧹
• надёжным 🛡️
• предсказуемым в продакшене 🚀

Вы избегаете ситуации, когда в запросы улетают невалидные заголовки, а процесс развертывания становится не только автоматизированным, но и по-настоящему безопасным.

🧠 7. Заключение: Мышление инженера

Освоение DevOps-практик, таких как настройка CI/CD-пайплайна, — это не просто получение нового навыка. Это фундаментальный сдвиг в мышлении.

Вы переходите:

• от простого написания кода ✍️
• к пониманию всего жизненного цикла приложения 🔄

Этот путь делает вас уверенным и востребованным профессионалом. Вы перестаёте бояться «инженерной инженерии» и начинаете понимать, как устроены современные процессы разработки.

🏠 Домашнее задание

Цель задания: Научиться деплоить приложение на GitHub Pages двумя способами: вручную и автоматически с использованием CI/CD процессов. Освоить работу с GitHub Actions и настройку окружения для production-сборки.

Задание 1

Ручной деплой проекта Trelly на GitHub Pages

1. Создай папку с названием trelly-deploy
2. Сбилди проект, в котором ты проделываешь домашние задания для проекта trelly, чтобы создалась папка dist с минифицированным кодом
3. Перенеси полученные файлы из папки dist в trelly-deploy

trelly-deploy/
├── assets/
│   ├── index-DbZnEMmK.css
│   ├── index-dxKq1e5v.js
├── index.html
├── vite.svg

4. Проинициализируй проект при помощи команды git init.

• Добавь в папку файл .gitignore и добавь в исключения папку .idea.
• Закоммить файлы

5. На github.com создай новый репозиторий с таким же названием trelly-deploy
6. Свяжи локальный и удалённый репозитории. Запушь на удалённый репозиторий сбилдженный минифицированный код

git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:github-nickname/trelly-deploy.git
git push -u origin main

7. Зайди в настройки репозитория на вкладку Settings. В разделе pages выбери deploy from a branch. Затем выбери main ветку и сохрани изменения

8. После этих изменений во вкладке Actions автоматически запустится деплой приложения

9. Если ты всё сделал верно, то по итогу твоё приложение будет успешно задеплоено. Адрес можно увидеть в джобе deploy

10. Но когда ты перейдёшь на страницу приложения, то увидишь белый экран и ошибки в консоли. Самостоятельно устрани все ошибки по аналогии, как в видео

• ошибки, связанные с конфигурацией Vite
• ошибки, связанные с api-key (Do not provide the API key for this domain; keep it secret. (code=8))
• добавь адрес задеплоенного приложения в apihub

Если ты всё сделал верно, то по итогу ты сможешь увидеть своё задеплоенное приложение в сети 🚀

Задание 2

Автоматический деплой проекта Trelly на GitHub Pages

Деплой приложения, который ты проделал в первом задании, не самый удобный. Нужно в репозитории изменять и билдить, потом полученный минифицированный код переносить. Жутко неудобно, но иногда такой подход имеет место быть.

Поэтому в данном задании тебе нужно самостоятельно (по видео) настроить CI/CD процессы для автоматического деплоя приложения

1. В предыдущем домашнем задании (26 урок, задание 3, пункт 4) тебе нужно было создать репозиторий для работы с домашними заданиями и запушить его удалённо. Если ты этого не сделал, то сделай сейчас.

2. Добавь в репозиторий файл .env, в котором храни api-key.

3. Напиши инструкцию, каким образом нужно деплоить приложение в .github/workflows/deploy.yaml
4. В настройках репозитория в разделе pages/build and deployment выбери источник деплоя Github Action

Если ты всё сделал верно, то по итогу ты сможешь увидеть своё задеплоенное приложение в сети 🚀