Если хочешь развиваться в бэкенд-разработке — выстроить сильную базу, углубиться в архитектуру или перейти в роль тимлида — в Центральном университете есть магистратура под каждый сценарий. И на нее можно получить грант до 75%. Места ограничены, дедлайн подачи заявок — 20 августа.
«Бэкенд-разработка» — это офлайн-направление (пары по вечерам и в выходные в центре Москвы) с тремя треками на выбор:
⚫️ Технический — для студентов старших курсов и разработчиков в начале карьеры. Языки программирования, DevOps-инструменты, базы данных, архитектура ПО и распределенные системы. Программа ежегодно обновляется под реальные запросы компаний, а преподают разработчики, тимлиды и CTO из ведущих IT-компаний. К выпуску — сильное портфолио бэкенд-проектов
⚫️ Совместный с MAGNIT TECH — обучение на реальных кейсах и архитектуре распределенных систем федерального масштаба, буткемп с экспертами компании и возможность выйти на оплачиваемую стажировку в техническую команду в течение первого года
⚫️ Тимлидский — для опытных разработчиков, которые хотят перейти к роли руководителя команды: выстраивать процессы разработки, принимать архитектурные решения и развивать команду
Магистратура в ЦУ — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях.
Поступление проходит через грантовый конкурс — это одновременно способ попасть на программу и возможность выиграть финансовую поддержку на все время обучения: грант покрывает до 75% стоимости. В 2026 году доступно 550 грантов на все программы магистратуры.
Подробнее о программе и условиях участия в конкурсе — по ссылке
«Бэкенд-разработка» — это офлайн-направление (пары по вечерам и в выходные в центре Москвы) с тремя треками на выбор:
Магистратура в ЦУ — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях.
Поступление проходит через грантовый конкурс — это одновременно способ попасть на программу и возможность выиграть финансовую поддержку на все время обучения: грант покрывает до 75% стоимости. В 2026 году доступно 550 грантов на все программы магистратуры.
Подробнее о программе и условиях участия в конкурсе — по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6😢2❤1🔥1
Недавно мы разобрались с основными понятиями: что такое CI/CD, GitOps, Docker, Kubernetes и зачем вообще фронтендеру понимать эти вещи.
Теперь давайте посмотрим, как выглядит путь обычной задачи в реальном проекте.
Представим, что разработчик берет задачу YH-1422. Под нее создается отдельная ветка, например:
feature/YH-1422
В этой ветке пишется код, фиксируются изменения через commit, после чего они отправляются в удаленный репозиторий:
commit → push → Pull Request
Еще до отправки кода могут запускаться локальные проверки. Обычно это Husky, линтеры, форматирование или тесты. Их задача — поймать простые ошибки еще до того, как изменения попадут в репозиторий.
Это еще не CI, а скорее локальная автоматизация, которая помогает разработчику. После создания Pull Request уже подключается настоящий CI.
В зависимости от проекта автоматически могут запускаться:
— установка зависимостей;
— линтеры;
— тесты;
— сборка приложения;
— дополнительные проверки безопасности или качества кода.
Если хотя бы одна проверка не пройдет, замержить изменения, скорее всего, не получится.
Часто CI интегрирован с таск-трекером. Например, после создания Pull Request задача автоматически переходит в статус In Review, а после merge — в Done. Разработчику уже не нужно менять статусы вручную.
На некоторых проектах для каждого Pull Request автоматически создается отдельное тестовое окружение (Preview Environment).
То есть изменения из ветки feature/YH-1422 разворачиваются по отдельному адресу, и тестировщики или заказчик могут проверить новую функциональность, не затрагивая общий стенд разработки.
После того как код прошел ревью, получил аппрув и успешно протестирован, Pull Request мержится в ветку develop.
И вот здесь для большинства проектов заканчивается CI и начинается CD.
Дальше коду предстоит пройти еще несколько этапов:
— сборка приложения;
— создание Docker-образа;
— публикация образа в Registry;
— обновление приложения в Kubernetes;
— синхронизация через GitOps (например, с помощью ArgoCD).
Именно на этом этапе код превращается в работающее приложение, которое увидят пользователи.
Но это уже отдельная большая тема. В следующем посте разберем весь путь от merge до деплоя в Kubernetes и посмотрим, что происходит "под капотом". 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍7❤5
Про ИИ истерию. Полностью согласен. Наконец-то все собрали в одно видео 😁
https://youtu.be/t_Z-KkJamSg?si=bBuScU9n-NHN2fQr
https://youtu.be/t_Z-KkJamSg?si=bBuScU9n-NHN2fQr
YouTube
Как AI скамит весь мир / Топ манипуляций твоим страхом
▶▶ На IT-конференции Профсоюзная расскажем про новую должность AI инженер и применение нейронок в работе: https://unionconf.ru/
▶▶ Как стать незаменимым AI инженером: https://t.me/om_assistant_robot?start=YWkg0LfQsNC80LXQvdC40YI
Полный список источников…
▶▶ Как стать незаменимым AI инженером: https://t.me/om_assistant_robot?start=YWkg0LfQsNC80LXQvdC40YI
Полный список источников…
❤4👍2
https://youtu.be/a43a-SCCHLg
Когда мне предложили провести прожарку собеса, я сначала хотел взять какой-нибудь идеальный кейс.
Тот самый собес, где ученик приходит, отвечает на все вопросы, закрывает все этапы и забирает оффер. Казалось бы, для ментора это самый красивый пример.
Но когда я начал готовить сценарий, понял — разбирать там особо нечего. В YouTube и так много собесов, а сама идея прожарки как раз в другом: найти ошибки, разобрать их и понять, что можно было сделать лучше.
Поэтому решил взять первый серьезный собес ученика в Big Tech.
Ученик учился 8 месяцев: прошел весь стек, закрыл все основные темы и сдал 13 экзаменов. После этапа теории еще 2-3 месяца ушли на практику, стажировку, создание резюме, проработку опыта и подготовку самопрезентации.
И вот здесь есть важный момент. Когда ты проходишь большой объем теории, а потом несколько месяцев фокусируешься на практике и подготовке выхода на рынок, часть тем уже не ощущается так свежо, как сразу после изучения. Поэтому перед собесами всегда важно возвращаться к базе и держать знания в тонусе.
Сейчас рынок тяжелый, поэтому стратегия была не уходить в бесконечную подготовку, а быстрее выйти на рынок: начать откликаться, получать реальные собеседования и параллельно повторять уже изученный материал.
Плюс нужно учитывать временной лаг: часто после отклика проходит 2-4 недели, пока HR дойдет до резюме и начнется активная коммуникация с компаниями.
Но хорошее позиционирование сработало быстрее, чем ожидали. Уже в первые дни начали приходить сообщения от компаний, а технические этапы начали назначаться буквально через пару дней. Среди них были крупные компании: Альфа, Сбер, VK, Яндекс, X5 и другие.
Поэтому я и решил прожарить именно первый его собес в Big Tech: сделать работу над ошибками, вместе с Антоном разобрать моменты, дать советы и навалить базы.
📚 Материалы для подготовки к собеседованиям
Что важно понять из этой истории:
— Даже на сложном рынке правильная подготовка и позиционирование могут привести к большому количеству возможностей.
— Даже если ты прошел все темы и сдал десятки проверок, нельзя терять тонус. Базу нужно постоянно поддерживать.
— Любой собес — это не приговор, а обратная связь. Он показывает, что нужно докрутить перед следующими этапами.
— Не стоит быть вечным учеником. Конечно, если бы подготовка продолжилась еще 1-2 месяца, знаний было бы еще больше. Но было бы столько собесов? А кто его знает, рынок меняется быстро.
Спустя месяц после этого собеса ученик получил оффер в финтех-компанию с хорошей зарплатой — 260к.
Он не сдался, продолжил искать, сделал работу над ошибками и выбрал правильную стратегию выхода на рынок.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥9😢3👍2🤝2🤔1
🤬 Дилемма IT-рынка
Дилемма разработчика: быть хорошим инженером или хорошим кандидатом?
Под комментариями к видео-прожарке люди разделились на два лагеря.
https://youtu.be/a43a-SCCHLg
Одни говорят: «Как можно не знать такие вопросы? Это же база».
Вторые говорят: «А зачем вообще задавать такие вопросы? Они ничего не показывают».
При этом и среди первых, и среди вторых были люди как с опытом, так и без него.
И вот тут начинается интересная дилемма.
Когда еще не было всей этой рыночной истерии, к собеседованиям относились проще. Опытные ребята, работающие в топовых компаниях, на собесах могли просто поговорить за жизнь — и их брали в Альфу, ВК, Сбер, Ростелеком и другие компании.
Не было жесткой проверки знаний. Алгоритмы, задачки и вопросы с собеседований считались отдельным навыком, который хороший разработчик знать не обязан.
Время шло. Записей собеседований на YouTube стало в сотни раз больше. Списки вопросов, подборки задач, сервисы подготовки — все стало доступно. Подготовиться стало намного легче.
Но вместе с этим поменялись и правила игры.
Сейчас уже недостаточно просто хорошо работать. Если ты приходишь на собеседование неподготовленным, то можешь проиграть человеку с меньшим опытом, который просто хорошо натренировал формат собеседования.
Готовиться к собеседованиям нужно. Это буквально часть профессии и реалии текущего рынка.
Улучшать резюме, правильно себя презентовать, иногда чуть подкручивать формулировки — это тоже часть игры.
Потому что какой смысл быть добрым, честным и иметь реальные навыки, если ты просто не проходишь первый фильтр и месяцами сидишь без работы?
Особенно сейчас, когда самый жесткий рынок находится в диапазоне 1-3 лет опыта. Но даже если человек условно добавит себе год и попадет в фильтр 3-6 лет, он все равно будет внизу выдачи.
HH ранжирует кандидатов: сначала идут люди с опытом 5+ лет, потом уже 3-4 года. Когда я делал эксперимент с вакансией, в топ-50 выдачи было около 80% людей с опытом 5 лет и больше.
Хотя на саму вакансию откликались разные люди. Кандидатов с 3-4 годами было тоже много, просто они находились ниже.
Кстати, проводя собеседования опытным ребятам, которые приходят за помощью с поиском работы, я часто вижу пробелы в базе.
Многие опытные разработчики не знают нормально про классы и прототипы. Ошибаются в задачах на this и Event Loop. Не умеют решать алгоритмические задачи.
Кто-то не может нормально отрефакторить React-компонент — хотя это один из популярных типов лайвкодинга.
А иногда проблемы вообще с базой: человек не помнит, что делают логические операторы, какая разница между функциями, как работают фундаментальные вещи языка.
И вот тут возникает вопрос: а что тогда вообще считать опытом? Количество лет в компании? Количество написанных строк кода? Умение решать реальные бизнес-задачи? Или способность пройти проверку на рынке?
Правильно говорят, что собеседования — это отдельный навык.
Если опытный разработчик не готовится, его может обойти менее опытный специалист, который просто лучше подготовился и умеет играть по новым правилам.
Еще часто говорят: «Опытный разработчик не значит хороший разработчик». И я с этим согласен.
Я регулярно встречаю людей с большим опытом, которые пишут код, который сложно поддерживать, сложно читать и сложно масштабировать.
Мне кажется, что в ближайшие годы с развитием нейросетей разница между просто опытным разработчиком и специалистом, который умеет думать, писать хороший код и правильно использовать AI-инструменты, будет только расти.
Мой пик менторства и помощи с трудоустройством новичкам пришелся на 2025 год.
И честно, я иногда не понимаю, как некоторые ребята раньше без нейронок умудрялись накручивать опыт и работать в компаниях. Только если с помощью сильного наставника на испытательном сроке. Но как-то же люди справлялись. И за это им большое уважение.
Помню, в начале 2024 года я помогал человеку, который накрутил себе 3 года опыта и попал в Сбер. Он обратился за помесячной помощью на испытательном сроке.
Дилемма разработчика: быть хорошим инженером или хорошим кандидатом?
Под комментариями к видео-прожарке люди разделились на два лагеря.
https://youtu.be/a43a-SCCHLg
Одни говорят: «Как можно не знать такие вопросы? Это же база».
Вторые говорят: «А зачем вообще задавать такие вопросы? Они ничего не показывают».
При этом и среди первых, и среди вторых были люди как с опытом, так и без него.
И вот тут начинается интересная дилемма.
Когда еще не было всей этой рыночной истерии, к собеседованиям относились проще. Опытные ребята, работающие в топовых компаниях, на собесах могли просто поговорить за жизнь — и их брали в Альфу, ВК, Сбер, Ростелеком и другие компании.
Не было жесткой проверки знаний. Алгоритмы, задачки и вопросы с собеседований считались отдельным навыком, который хороший разработчик знать не обязан.
Время шло. Записей собеседований на YouTube стало в сотни раз больше. Списки вопросов, подборки задач, сервисы подготовки — все стало доступно. Подготовиться стало намного легче.
Но вместе с этим поменялись и правила игры.
Сейчас уже недостаточно просто хорошо работать. Если ты приходишь на собеседование неподготовленным, то можешь проиграть человеку с меньшим опытом, который просто хорошо натренировал формат собеседования.
Готовиться к собеседованиям нужно. Это буквально часть профессии и реалии текущего рынка.
Улучшать резюме, правильно себя презентовать, иногда чуть подкручивать формулировки — это тоже часть игры.
Потому что какой смысл быть добрым, честным и иметь реальные навыки, если ты просто не проходишь первый фильтр и месяцами сидишь без работы?
Особенно сейчас, когда самый жесткий рынок находится в диапазоне 1-3 лет опыта. Но даже если человек условно добавит себе год и попадет в фильтр 3-6 лет, он все равно будет внизу выдачи.
HH ранжирует кандидатов: сначала идут люди с опытом 5+ лет, потом уже 3-4 года. Когда я делал эксперимент с вакансией, в топ-50 выдачи было около 80% людей с опытом 5 лет и больше.
Хотя на саму вакансию откликались разные люди. Кандидатов с 3-4 годами было тоже много, просто они находились ниже.
Кстати, проводя собеседования опытным ребятам, которые приходят за помощью с поиском работы, я часто вижу пробелы в базе.
Многие опытные разработчики не знают нормально про классы и прототипы. Ошибаются в задачах на this и Event Loop. Не умеют решать алгоритмические задачи.
Кто-то не может нормально отрефакторить React-компонент — хотя это один из популярных типов лайвкодинга.
А иногда проблемы вообще с базой: человек не помнит, что делают логические операторы, какая разница между функциями, как работают фундаментальные вещи языка.
И вот тут возникает вопрос: а что тогда вообще считать опытом? Количество лет в компании? Количество написанных строк кода? Умение решать реальные бизнес-задачи? Или способность пройти проверку на рынке?
Правильно говорят, что собеседования — это отдельный навык.
Если опытный разработчик не готовится, его может обойти менее опытный специалист, который просто лучше подготовился и умеет играть по новым правилам.
Еще часто говорят: «Опытный разработчик не значит хороший разработчик». И я с этим согласен.
Я регулярно встречаю людей с большим опытом, которые пишут код, который сложно поддерживать, сложно читать и сложно масштабировать.
Мне кажется, что в ближайшие годы с развитием нейросетей разница между просто опытным разработчиком и специалистом, который умеет думать, писать хороший код и правильно использовать AI-инструменты, будет только расти.
Мой пик менторства и помощи с трудоустройством новичкам пришелся на 2025 год.
И честно, я иногда не понимаю, как некоторые ребята раньше без нейронок умудрялись накручивать опыт и работать в компаниях. Только если с помощью сильного наставника на испытательном сроке. Но как-то же люди справлялись. И за это им большое уважение.
Помню, в начале 2024 года я помогал человеку, который накрутил себе 3 года опыта и попал в Сбер. Он обратился за помесячной помощью на испытательном сроке.
🔥10❤4👍3
Для меня это был шок. Код был слабый, базовой логики и понимания разработки почти не было. Но человек получал 250 тысяч рублей в месяц. И знаете что? Он молодец.
Он смог попасть в систему, пройти фильтры и получить результат. Возможно, ему вообще не интересно, что кто-то считает его путь неправильным.
Типа: «Хэй, я получаю 250к, а вы тут сидите и год ищете работу, зато говорите про честность».
Это было бы не очень красиво с его стороны. Но доля правды в этом есть.
Потому что рынок в итоге вознаграждает не самых правильных. Он вознаграждает тех, кто смог адаптироваться под его правила.
И, наверное, главный вопрос не в том, правильно это или нет.
А в том: Нужно ли быть лучшим разработчиком или нужно уметь доказать рынку, что ты им являешься?
Он смог попасть в систему, пройти фильтры и получить результат. Возможно, ему вообще не интересно, что кто-то считает его путь неправильным.
Типа: «Хэй, я получаю 250к, а вы тут сидите и год ищете работу, зато говорите про честность».
Это было бы не очень красиво с его стороны. Но доля правды в этом есть.
Потому что рынок в итоге вознаграждает не самых правильных. Он вознаграждает тех, кто смог адаптироваться под его правила.
И, наверное, главный вопрос не в том, правильно это или нет.
А в том: Нужно ли быть лучшим разработчиком или нужно уметь доказать рынку, что ты им являешься?
❤17💯6🔥3
Forwarded from Менторство Reactify
💼 Персонализированная подготовка
Весь июль тестировали Календарь собеседований и внедряли новый подход к подготовке.
Раньше мы в основном готовили ученика до выхода на рынок, а дальше уже подключались точечно, если нужен был мок.
И этого подхода в целом хватало.
Каждый ученик до выхода на рынок проходил 5–13 экзаменов по всем темам (экзамен = мок с ментором), потом ещё 2+ дополнительных мока и прожарки. Плюс были рандомные моки с другими ребятами примерно 2 раза в неделю.
Этого было достаточно, чтобы получать офферы.
Но рынок стал тяжелее. Конкуренция выросла, компании стали сложнее отбирать кандидатов, и сейчас нужно выжимать максимум из каждого шанса.
Поэтому мы поменяли подход.
Есть собеседование в Т-Банк и там лайвкодинг? Сделаем мок лайвкодинга именно под формат Т-Банка.
Финальный этап в Сбере? Сделаем часовой мок по софтам и разбору опыта, чтобы максимально повысить шанс пройти.
То есть после выхода на рынок ученик теперь имеет возможность делать практически неограниченное количество моков с ментором по необходимости, пока ищет работу.
Это и есть персонализированная подготовка.
И всё это стало возможным благодаря трекингу собеседований через Календарь.
Но моки — это только часть. Календарь даёт ещё несколько сильных возможностей.
🚂 Паровозы собеседований
Например, Ваня прошёл собеседование в Авито. Через неделю Петя идёт туда же — Ваня может передать ему вопросы, рассказать про этапы и помочь подготовиться осмысленно.
Раньше такие связи часто терялись. Теперь мы специально их создаём.
📚 Материалы и реальные вопросы
Мы подключили помощника, у которого есть доступ к куче источникам с записями собеседований, слитыми вопросами, задачами и закрытыми базами.
Когда ученик добавляет собеседование в календарь — мы можем искать актуальные материалы именно под эту компанию и этот этап. Давать это ученику.
🤝 Рефералы
Ещё один важный эффект — растёт база контактов.
Например, ученик прошёл собеседование в Сбер, но понял, что ему не подходит офисный формат. Он с большей вероятностью сможет порекомендовать другого ученика, которому такой формат подходит.
Получается система, где ученики помогают друг другу получать больше возможностей.
За июль Календарь уже показал хороший результат:
— 8 рефералок ученик → ученик
— 11 паровозов по собеседованиям
— 20 собеседований, где удалось найти вопросы и записи, которые совпали с реальными этапами примерно на 90%
— дополнительные моки для подготовки к алгоритмам и финальным этапам
Это только первый месяц.
Чем больше данных собираем, тем точнее понимаем, где можно помочь, какие компании сейчас нанимают и как увеличить шанс получить оффер.
Мы не ждем хороший рынок🚀
Мы побеждаем на любом💪
Весь июль тестировали Календарь собеседований и внедряли новый подход к подготовке.
Раньше мы в основном готовили ученика до выхода на рынок, а дальше уже подключались точечно, если нужен был мок.
И этого подхода в целом хватало.
Каждый ученик до выхода на рынок проходил 5–13 экзаменов по всем темам (экзамен = мок с ментором), потом ещё 2+ дополнительных мока и прожарки. Плюс были рандомные моки с другими ребятами примерно 2 раза в неделю.
Этого было достаточно, чтобы получать офферы.
Но рынок стал тяжелее. Конкуренция выросла, компании стали сложнее отбирать кандидатов, и сейчас нужно выжимать максимум из каждого шанса.
Поэтому мы поменяли подход.
Есть собеседование в Т-Банк и там лайвкодинг? Сделаем мок лайвкодинга именно под формат Т-Банка.
Финальный этап в Сбере? Сделаем часовой мок по софтам и разбору опыта, чтобы максимально повысить шанс пройти.
То есть после выхода на рынок ученик теперь имеет возможность делать практически неограниченное количество моков с ментором по необходимости, пока ищет работу.
Это и есть персонализированная подготовка.
И всё это стало возможным благодаря трекингу собеседований через Календарь.
Но моки — это только часть. Календарь даёт ещё несколько сильных возможностей.
🚂 Паровозы собеседований
Например, Ваня прошёл собеседование в Авито. Через неделю Петя идёт туда же — Ваня может передать ему вопросы, рассказать про этапы и помочь подготовиться осмысленно.
Раньше такие связи часто терялись. Теперь мы специально их создаём.
📚 Материалы и реальные вопросы
Мы подключили помощника, у которого есть доступ к куче источникам с записями собеседований, слитыми вопросами, задачами и закрытыми базами.
Когда ученик добавляет собеседование в календарь — мы можем искать актуальные материалы именно под эту компанию и этот этап. Давать это ученику.
🤝 Рефералы
Ещё один важный эффект — растёт база контактов.
Например, ученик прошёл собеседование в Сбер, но понял, что ему не подходит офисный формат. Он с большей вероятностью сможет порекомендовать другого ученика, которому такой формат подходит.
Получается система, где ученики помогают друг другу получать больше возможностей.
За июль Календарь уже показал хороший результат:
— 8 рефералок ученик → ученик
— 11 паровозов по собеседованиям
— 20 собеседований, где удалось найти вопросы и записи, которые совпали с реальными этапами примерно на 90%
— дополнительные моки для подготовки к алгоритмам и финальным этапам
Это только первый месяц.
Чем больше данных собираем, тем точнее понимаем, где можно помочь, какие компании сейчас нанимают и как увеличить шанс получить оффер.
Мы не ждем хороший рынок
Мы побеждаем на любом
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥28❤10👍9
В прошлый раз мы остановились на моменте, когда 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 и как вообще фронтенд приложение живет внутри кластера 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥6❤4
Скоро возвращение на YouTube 💪🏼
1. Разбор самого душного собеса: V8, Hidden classes, JIT, TS, Garbage Collector и другие необычные темы на собесе 🤯
2. Архитектура Frontend: Monorepo, Multirepo, Microfrontends, Monoliths
Схема эволюция на примере больших компаний
Видео в монтаже💪
Так же много сценариев написал, буду контент машину запускать
🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube
1. Разбор самого душного собеса: V8, Hidden classes, JIT, TS, Garbage Collector и другие необычные темы на собесе 🤯
2. Архитектура Frontend: Monorepo, Multirepo, Microfrontends, Monoliths
Схема эволюция на примере больших компаний
Видео в монтаже
Так же много сценариев написал, буду контент машину запускать
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥28❤10👍5😢1
This media is not supported in your browser
VIEW IN TELEGRAM
🔥28👍8😁6❤1
В этом видео разберём эволюцию больших frontend-систем:
Monolith → Modular Monolith → Monorepo → Multirepo → Microfrontends.
На примере роста большой платформы посмотрим:
— почему один frontend начинает не справляться с ростом команды;
— зачем переходят от монолитного приложения к модульной архитектуре;
— чем отличаются Monorepo и Multirepo;
— когда появляются отдельные приложения и бизнес-контуры;
зачем нужны Microfrontends;
— как независимые команды получают свои релизы, CI/CD и жизненный цикл.
Разберём:
— Frontend Architecture
— Microfrontend Architecture
— Monorepo vs Multirepo
— Modular Monolith
— Frontend Scaling
— Large Scale Frontend Applications
Видео будет полезно frontend-разработчикам, архитекторам и техническим лидерам, которые строят масштабируемые веб-приложения.
Видео уже на канале Reactify!
Я не оставляю ссылку, так как видео лучше продвигается, если заходить на него напрямую с YouTube. Это помогает улучшить его рейтинг и увеличить шансы на органическое продвижение.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤3👍3🤝1
This media is not supported in your browser
VIEW IN TELEGRAM
🔥18❤7👍5🫡1
This media is not supported in your browser
VIEW IN TELEGRAM
❤15👍11🔥7😢1