👩‍💻 CI/CD для фронтендера часть 3

В прошлый раз мы остановились на моменте, когда Pull Request прошел ревью, получил аппрув и попал в ветку develop.

Теперь начинается самое интересное — что происходит после merge и как код оказывается в Kubernetes. Разберем путь от merge до деплоя.

Итак, разработчик сделал merge:

feature/YH-1422 → develop

С этого момента обычно запускается новый workflow.

Первый этап — сборка.

CI/CD система берет свежий код из ветки develop и выполняет примерно такие шаги:
— скачивает репозиторий;
— устанавливает зависимости;
— собирает приложение;
— запускает необходимые проверки;
— создает артефакты сборки.

Для фронтенда результатом обычно будет набор статических файлов:

dist/
 ├── index.html
 ├── assets/
 ├── javascript bundles
 └── styles

Но часто в современных проектах дальше появляется Docker. Вместо того чтобы просто отправлять файлы на сервер, приложение упаковывается в Docker image.

Например:

код приложения

↓

npm install

↓

npm run build

↓

Docker image

↓

Container Registry

Docker image — это готовая версия приложения вместе с необходимым окружением.

Например:

frontend-app:1.25.0

Эта версия уже сохранена в Registry, откуда ее сможет забрать Kubernetes.

Следующий этап — Kubernetes.

Kubernetes сам по себе не знает, какую версию приложения нужно запускать.

Ему нужно описать желаемое состояние:
— какой image использовать;
— сколько запустить копий приложения;
— какие ресурсы выделить;
— какие настройки применить.

Обычно это описывается через Kubernetes manifests или Helm charts.

Например:

frontend:
  image: frontend-app:1.25.0
  replicas: 3

То есть мы говорим Kubernetes: "Мне нужно 3 экземпляра фронтенда версии 1.25.0"

И Kubernetes делает все необходимое:
— скачивает Docker image;
— создает контейнеры;
— запускает приложение;
— проверяет, что оно работает;
— заменяет старую версию новой.

В GitOps подходе мы обычно не отправляем команды напрямую в Kubernetes. Вместо этого есть отдельный репозиторий с описанием состояния инфраструктуры.

Например:

application-config

frontend:
  image: frontend-app:1.25.0

Изменили версию в Git → система увидела изменение → обновила Kubernetes.

И здесь появляется ArgoCD. ArgoCD постоянно сравнивает: что написано в Git vs что реально запущено в Kubernetes. Если есть различия — он выполняет синхронизацию.

Например:

В Git: frontend-app:1.25.0
В Kubernetes: frontend-app:1.24.0

ArgoCD увидит расхождение и обновит приложение.

В итоге весь путь выглядит примерно так:

Merge в develop

↓

CI/CD workflow

↓

Build приложения

↓

Docker image

↓

Container Registry

↓

Обновление конфигурации в Git

↓

ArgoCD

↓

Kubernetes

↓

Новое приложение работает

И вот этот процесс обычно скрыт от фронтендера. Разработчик сделал merge — через несколько минут новая версия уже доступна на стенде.

Но за этим стоят несколько систем, которые работают вместе:
Git → CI/CD → Docker → Registry → GitOps → ArgoCD → Kubernetes

Первые 4 шага можно изучить в нашем репозитории: https://github.com/YeaHubTeam/yeahub-platform/blob/main/Dockerfile

В следующей части можно разобрать уже сам Kubernetes: что такое Pod, Deployment, Service, Ingress и как вообще фронтенд приложение живет внутри кластера 🙂

🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Как устроены ИИ-агенты, которые умеют программировать сами?

27 августа в 19:00 встречаемся в кампусе Центрального университета на митапе про кодинговых ИИ-агентов.

На митапе:
⚫️ узнаем, почему кодинговые агенты превращаются в отдельные сервисы и как устроены распределенные агентные системы;
⚫️ разберем протоколы ACP и A2A и посмотрим, как разные агенты и клиенты могут взаимодействовать между собой;
⚫️ на практическом мастер-классе создадим собственного автономного агента с помощью Deep Agents от LangChain — с планированием, управлением контекстом, файловой системой и параллельной работой сабагентов.

Мастер-класс — с ноутбуками, так что получится не только посмотреть, но и попробовать собрать агента своими руками.

Спикеры:
⚫️Денис Артюшин — технический владелец продукта агентской платформы в Т-Банке
⚫️Полина Реброва — ведущий инженер по разработке, Сбер
⚫️Александр Шахов — инженер-преподаватель и академический руководитель направления «Разработка» в Центральном университете

📍 27 августа, 19:00
📍 Кампус Центрального университета, Москва

Зарегистрироваться по ссылке