⚡️Через 5 минут начинаем наш эфир!⚡️

Ссылка для подключения здесь

Почему студенты выбирают курс "Профессия DevOps-инженер"?

Анализируя обратную связь студентов прошлых потоков, мы с коллегами из Слёрма выделили ключевые причины выбора этого курса:
1️⃣Прикладная ценность: упор на практику и инструменты (Ansible, Docker, Kubernetes, CI/CD), которые нужны в работе.
2️⃣Актуальность: подходит и новичкам, и опытным специалистам, так как закрывает реальные профессиональные задачи.
3️⃣Фундаментальность: продуманная программа дает не только поверхностные знания, а качественную базу.
4️⃣Карьерный рост: главное — возможность освоить востребованную профессию и выйти на новый уровень дохода.

Итог: курс помогает систематизировать знания, прокачать практические навыки и уверенно войти в разработку и эксплуатацию (DevOps).

⚡️Поток с обновленной программой стартовал.
⏩Присоединиться к группе вы можете на странице курса.

Коллеги, привет! 👋

26 февраля мы провели вебинар, посвящённый первому собеседованию в разработке и эксплуатации (DevOps).

Если вы мечтаете о первой работе в DevOps, но пока не знаете, с какой стороны подойти, — этот эфир для вас.

⏩Смотрите полный разбор по ссылке

Будет полезно и тем, кто только присматривается к направлению, и тем, кто уже начал рассылать резюме.

⚡️Сохраняйте и делитесь с теми, кто тоже ищет свой путь в DevOps!

Коллеги, привет! 👋🏻
Сегодня поговорим про Gitlab и посмотрим простой прием с переменными (variables) и вводом (input).
Они начали использоваться начиная с 17.0 версии, уже 10 версий прошло, кажется можно и обсудить. Не забудьте, что на более старых версиях может вообще не работать. в т.ч проверяйте версию раннера.

Как работать с переменными должно быть всем понятно, но у них есть несколько проблем и сложностей. Сегодня рассмотрим как просто поменять Variable на Inputs и как можно расширить возможности вашего пайплайна:

📌Простой пример как использовать переменные в job в Вашем gitlab-ci:

variables:
  versions:
    value: "1.0"
    options: 
      - "0.1"
      - "1.0"
      - "2.1"
    description: "tag name"

Удобная схема, которая позволит иметь дефолтное значение, и при ручном запуске можно переопределить значение из выпадающего списка.

📌Так как это действительно удобно, сделаем тоже самое с inputs

spec:
  inputs:
    versions:
      options: ['0.1', '1.0', '2.1']
      default: '1.0'
      description: 'tag name'

Работает точно также. Только для использования нужно использовать $[[ inputs.versions ]] вместо $versions

Возможно, выглядит может чуть сложнее, но с большей сложностью приходят новые возможности.

⏩Одну из них сегодня разберем.
С помощью переменных, я могу сделать огромный список разных вариантов переменных, сочетание которых, будет делать то, что нужно. Но мне хочется больше.
С помощью inputs можно создавать условие отображения возможных вариантов переменных. То есть, выбрав одну переменную, сделать возможным отображение вариантов или условий соответствующих только для нее.

Попробуем это сделать:

spec:
  inputs:
    run_playbook:   # Например я хочу выбирать значение для опредленного плейбука
      options: ['', 'nginx', 'k8s', 'postgres']
      default: ''
      description: 'Playbook to run'

environment:   # Возможно значение будет зависеть от окружения
      options: ['development', 'staging', 'production']
      default: 'development'
      description: 'Your environment'

playbook:     # Вот и основное значение, допустим это имя плейбука или нужная ему переменная
      description: 'Install'
      rules:    #  Пишем привычные правила, указывая условия. варианты будут доступны только при выполнении условий
        - if: $[[ inputs.run_playbook ]] == 'nginx' && $[[ inputs.environment ]] == 'development'
          options: ['my_lb', 'your_lb']
          default: 'my_lb'
        - if: $[[ inputs.run_playbook ]] == 'nginx' && $[[ inputs.environment ]] == 'production'
          options: ['prod01', 'prod02', 'prod03']
          default: 'prod01'
        - if: $[[ inputs.run_playbook ]] == 'k8s'
          options: ['common-test', 'common-dev', 'common-prod']
          default: 'common-test'
        - if: $[[ inputs.run_playbook ]] == 'postgres'
          options: ['base01', 'base02', 'base03']
          default: 'base01'
        - options: [''] 
          default: ''    # Пока не выбрано - будет пустое значение

Попробуйте использовать в ваших пайплайнах, а если вам будет полезно, разберем и другие варианты использования 🔥

Приветы! На связи Аниса 😎
И сегодня начистоту:

«Я не люблю работать — как быть?»

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

Отсюда вопрос:

А кто сказал, что любить работать — это обязательно?

Сейчас раскрою.

Такая мысль — это сигнал к тому, что нужно не «заставить себя полюбить работать», а сменить вектор отношения к этому делу.

В эпоху соцсетей, культа продуктивности и успешности кажется обязательным обожание работы, а вынужденный не по собственному желанию! трудоголизм поощряется обществом.

🗣 Big fact: сбегать от собственных мыслей в работу всегда почётнее и статуснее, нежели в компьютерные игры.

Однако работа ≠ единственный способ самореализации. Это классный способ заработка, удовлетворения потребностей.
Если работа позволяет чувствовать причастность к чему-то важному, самореализации — это супер!
Если нет (а такое тоже бывает) — это норм!

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

Работа — это часть жизни. А жизнь — это мы сами.

А у вас есть какие-нибудь заряжающие увлечения? Делитесь, будем вдохновляться

Коллеги, приветствую👋

17 марта мы собирались на неформальную встречу, где честно поговорили о карьере, учебе и страхах новичков. Вам было интересно, поэтому мы проводим еще один эфир, но теперь сфокусируемся на самом важном этапе обучения — финальном проекте. И обсудим мы его с выпускниками 11 потока курса «Профессия DevOps-инженер» .

На встрече:
1️⃣Расскажем как завершить финальный проект и вспомним самые любимые модули курса.
2️⃣Обсудим, что ждёт после диплома: обратная связь, первые рабочие дни и как не потерять себя в этом потоке.
3️⃣А ещё разберём, кому сейчас точно стоит идти на курс, а кому лучше повременить. И поделимся лайфхаками, как совмещать учёбу с работой и не выгореть.

‼️ Когда: 2 апреля, 19:00 мск

Будем рады видеть студентов, выпускников и всех, кто в поиске своего пути.

⏩ЗАНЯТЬ МЕСТО

А для тех, кто хочет системно изучить профессию и получить поддержку опытных инженеров, у нас есть курс

Коллеги, всем привет 📌

Разбавим контент развлекательным (но техническим) постом. На первый взгляд может показаться, что в нем нет смысла. На деле же, предлагаю разобрать подходы к решению проблем в своих разработках на примерах, не прикручивая дополнительные инструменты, а используя сам GitLab 🔥

⏩Итак, пример
Для начала создаем проект. Он пока пустой, поэтому сначала конечно же продумываем структуру:

Создаем (метки лейблы) для задач

Для t‑shirt‑оценки длительности:
    size::S — однодневка, без ночёвки
    size::M — классические выходные (2 дня, 1–2 ночёвки)
Качество дорог
    road::perfect — Что-то идеальное, платные дороги
    road::good — ожидаем нормальный асфальт
При желании можно добавить риски:
    risk::no-fuel — длинные участки без заправок.
    risk::no-mobile — возможное отсутствие связи.
Или просто фичи
    feature::tollroad — платная дорога

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

.gitlab/issue_templates/Route.md
и
.gitlab/issue_templates/Trip.md

В которых шаблон будет такого вида

# Маршрут: {{название}}

**Кратко**
- Регион: 
- Размер (S/M/L/XL): 
- Тип покрытия: 
- Ориентировочный километраж: 

**Что хочется**
- Основная идея маршрута:
  - 
- Что важно проехать:
  - 
- Что можно оставить на потом:
  - 

**Техданные**
- Примерные точки/города:
- Ссылки на карты (Яндекс/OSM/GPX черновой):

**Чек‑лист**
- [ ] Создана ветка `route/<slug>`
- [ ] Добавлен `route.yml`
- [ ] Добавлен `overview.md`
- [ ] Добавлены ссылки на карты/треки

Таким образом, мы создали основу для того, чтобы работать с проектом и создавать задачи, которые описаны и содержат нужную информацию. В типичном рабочем процессе здесь описывались бы критерии готовности (DoD)

После создания задачи, создается ветка этой задачи из основной. Далее ответственный за нее человек начинает выполнять задачу.

После того, как работа в ветке завершена, создается запрос на слияние (Merge Request) и чтобы там тоже был шаблон, создадим файл .gitlab/merge_request_templates/Request.md, в который добавим основные моменты, которые нужно отметить для готового слияния. Это все будет работать, когда будет залито уже в основную ветку.

Это конечно еще не все, но у нас уже есть проект, в котором мы выстраиваем работу используя рабочие элементы (Work items), и разработка идет с этим учетом, шаблоны создают порядок 🔥
Кто догадается что, можно сделать дальше, для настройки? Пишите в комментариях ⬇️

Коллеги, привет!👋

⏩Напоминаю, что сегодня, 2 апреля в 19:00 мск, мы снова встречаемся — и теперь в фокусе будет то, что волнует каждого, кто доходит до самого ответственного этапа обучения: финальный проект.

В прошлый раз мы честно говорили о карьере, учёбе и страхах новичков, и вы откликнулись. Поэтому решили продолжить, но ещё конкретнее. В этот раз к диалогу присоединятся выпускники 11-го потока курса «Профессия DevOps-инженер» — поделимся живым опытом и разберём самое важное.

⏩Ждём:
— студентов и выпускников,
— всех, кто сейчас присматривается к профессии и ищет свой путь в DevOps.

ЗАНЯТЬ МЕСТО

Идеальное резюме для ИИ-отбора⚡️

Сегодня резюме всё чаще сначала читает не нанимающий менеджер, а алгоритм.

Советы для прокачки резюме:
⚫️Задачи: Прописывайте их чётко, а не размыто.
⚫️Технологии: Указывайте всё, чем владеете.
⚫️Опыт: Показывайте не просто стаж, а ваши достижения.
⚫️Цифры: Любые результаты лучше превращать в метрики.

❗️Системы отбора (ATS) сверяют ваше резюме с вакансией автоматически. Нужны точные попадания в ключевые слова. И если в тексте нет нужных ключевых слов — ваше резюме могут даже не показать нанимающему менеджеру.

➡️Полная версия вебинара про первое собеседование в разработке и эксплуатации (DevOps) и профессиональные секреты ИТ-рекрутера — ТУТ

🚀 А если вы хотите составить идеальное резюме, которое понравится и ИИ, и рекрутеру, и техническому специалисту, тогда приходите на курс «Профессия Devops-инженер»

➡️ ЗАНЯТЬ МЕСТО НА КУРСЕ

⚡️Через 5 минут начинаем наш эфир!⚡️

Ссылка для подключения здесь

🔥Пока вы думаете, другие уже учатся

Коллеги, продажи на курс Профессия DevOps-инженер продолжаются, но осталось всего 3 дня.

⚡️В закрытом чате курса уже полным ходом идёт обсуждение. Участники знакомятся, делятся проблемами с CI/CD, кластерами и автоматизацией, задают вопросы.

Если вы тоже хотите прокачаться в DevOps, получить обратную связь от меня и зарядиться комьюнити — не откладывайте.

⏩ До конца продаж — 3 дня
⏩ ПРИСОЕДИНИТЬСЯ ПО ССЫЛКЕ

Коллеги, продажи на курс "Профессия DevOps-инженер" закрываются через 2 дня

⚡️Профессия DevOps-инженер — это интенсивное погружение, где вы не слушаете лекции, а строите работающую систему.

Мы не растягиваем теорию. Мы даем практику (83% времени), чтобы вы как можно быстрее начали претендовать на позиции уровня Middle.

⏩От ручного управления — к автоматизированной инфраструктуре.
⏩От поиска виноватых — к системе мониторинга.
⏩От «админа» — к инженеру.

За 9 месяцев можно выучить новый язык. А можно — новую профессию, которая перезапустит вашу карьеру.

➡️ ЗАБРАТЬ МЕСТО НА КУРСЕ

Доброе утро, с началом новой недели🔥

Увидел у коллеги @teamcity_fairy пост про TeamCity. Спасибо за честный разбор плюсов и минусов. Решил поделиться с вами.

Плюсы у TeamCity (далее ТС):

🐚 Удобный UI

🔗 Работа с цепочками сборок
Одна из наиболее используемых фич - удобный, гибкий и хорошо визуализированный механизм цепочек сборок.
⛓️ Сборки по цепочке можно запускать в обе стороны (механизмы dependency и build triggers).
⛓️ Пользовательские переменные тоже можно передавать в обе стороны (dep.*, reverse.dep.*).
⛓️Можно запустить только часть цепочки, если нужно.
⛓️ В случае изменений, ТС автоматически перезапустит только изменившуюся часть цепочки.
⛓️Гарантия, что все билды в цепочке запускаются на одних и тех же ревизиях репо.

Все это позволяет создавать сложные графы зависимостей и поддерживать огромные многокомпонентные проекты, что пригождается большим компаниям.

Еще есть прикольный механизм promotion - можно взять руками старый билд, и запустить с ним новую цепочку дальнейших сборок.
Так же есть опция помечать нужные билды тегами, помогает легко находить нужный артефакт в сотнях сборок.

👨‍💻 Kotlin DSL
Kotlin DSL - это ооп-язык, позволяющий динамически создавать сборки на ТС и управлять сложными системами сборок. Очень мощный инструмент в плане рефакторинга и управления большим количеством кода.
💡 Позволяет использовать всю силу IDE для работы с Kotlin DSL.
✍️ ТС умеет автоматически переводить простые джобы в Kotlin DSL.
📕 Инфраструктурный код на Kotlin DSL может храниться в отдельном в репо команды инфры и быть доступен только ей - лучше контролируются безопасность и порядок.

🕵️‍♀️ Гибкий выбор билд-агентов
В ТС удобный и гибкий механизм выбора билд-агентов под разные сборки и требования. Например, можно выбирать агент только с необходимым количеством места на диске под сборку.

🗒 Пулы агентов
Это группы билд-агентов, объединенные по какому-то признаку. Это очень когнитивно разгружает при работе с сотнями билд-агентов.
🔐 Модель доступа
Удобная модель управления доступами с гибко настраиваемыми правами и ролями, есть интеграция с LDAP/Active Directory.
📊 Сильная визуальная аналитика
Удобная и подробная аналитика динамики скорости билдов и флаки-тестов со всевозможными графиками и детализацией.

❌ Но есть и минусы тоже:

❗️ Самый существенный - вендор лок, необходимость лицензии, гео-ограничения (кто дочитал до этого пункта, для того и откроется ответ на вопрос заголовка: к сожалению, именно по этой причине проекты с него мигрируют на другие системы, хотя на нем по-прежнему работает очень много старых проектов).
🔐 В отличии от систем, где код проекта и описание пайплайна хранятся в одном месте (e.g. Gitlab CI), здесь придется потрудиться настроить все доступы отдельно (будь то доступы к UI TeamCity или к репо с Kotlin DSL). C другой стороны, это безопаснее - централизованный контроль доступов.
🚤 ТС сложнее завести в кубере, чем некоторые другие ci/cd-системы.
🐱 Для небольших проектов лучше взять систему с более простым развертыванием и сопровождением.