Должен ли фронтендер знать, как устроен CI/CD на его проекте? Сложный вопрос. Если говорить про уровни, то я бы разделил так.
Сеньор должен понимать систему целиком. Не обязательно знать каждую настройку инфраструктуры, но он должен понимать:
— где собирается приложение;
— какие проверки проходят перед merge;
— как код попадает в окружения;
— где происходит деплой;
— какие инструменты участвуют в процессе.
То есть понимать не только "я сделал push и оно само задеплоилось", а что именно произошло между этими событиями.
Мидл должен понимать общую картину проекта:
— какие проверки запускаются;
— как работают линтеры;
— где запускаются тесты;
— как происходит сборка приложения;
— какие процессы настроены в репозитории.
Например, какие workflow существуют, что проверяется на Pull Request, что происходит после merge.
А вот джун не обязан глубоко разбираться в инфраструктуре. Но базовое понимание жизненного цикла изменения сейчас становится важным навыком.
Особенно учитывая современные инструменты и нейросети: простые задачи разработки становятся доступнее, а понимание системы вокруг кода становится одним из факторов роста.
📕 Давайте немного разберем GitOps подход и основные понятия.
CI/CD — это набор практик автоматизации, который помогает проверять, собирать и доставлять код.
CI (Continuous Integration) — это процесс постоянной интеграции изменений:
— проверка кода;
— линтеры;
— форматирование;
— тесты;
— сборка приложения.
CD (Continuous Delivery / Deployment) — это доставка изменений в окружения:
— создание сборки;
— публикация артефактов;
— деплой приложения.
Workflow — это сценарий автоматических действий, который запускается при определенном событии.
push → запустить проверки
Pull Request → запустить тесты и сборку
merge в develop → задеплоить приложение
Pipeline — это последовательность шагов внутри workflow.
1. Скачать код из репозитория
2. Установить зависимости
3. Запустить линтер
4. Запустить тесты
5. Собрать приложение
6. Создать Docker image
Docker — это технология упаковки приложения вместе с необходимым окружением в контейнер.
Например, наше фронтенд приложение после сборки может превратиться в Docker image, который потом будет запущен на сервере.
Kubernetes — это система управления контейнерами. Она отвечает за то, чтобы приложение работало:
— нужное количество копий;
— автоматический перезапуск;
— распределение нагрузки;
— обновление версий.
GitOps — это подход, при котором Git становится источником правды для состояния системы.
То есть мы не идем вручную на сервер и не говорим "обнови приложение".
Мы описываем желаемое состояние в Git, а специальные инструменты сами приводят систему к этому состоянию.
В Git указано:
- версия приложения: 1.5.0
- Kubernetes сейчас работает на версии 1.4.0
- Инструмент GitOps увидит расхождение и обновит приложение.
ArgoCD — один из таких инструментов.
Он следит за Git-репозиторием и Kubernetes-кластером, сравнивает текущее состояние с описанным в Git и синхронизирует их.
В следующий раз разберем весь флоу — от момента написания кода до полноценного деплоя. Получилось слишком много информации, поэтому пришлось разделить тему на несколько частей 😁
🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube