Везде наступает новый год, а в Слёрме — новый формат курса GitLab CI/CD. Многим студентам часто не хватало обратной связи от спикеров при самостоятельном прохождении курса. Мы решили исправить эту несправедливость и добавили к видеокурсу AMA-сессии.

5 декабря в 16:00 спикеры Слёрма встретятся с вами в прямом эфире, чтобы провести бесплатный вебинар по GitLab.

О чем будем говорить?

? концепция непрерывной интеграции и развертывания программного обеспечения;
? основные этапы работы с GitLab-CI – от простого рабочего процесса до более сложных сценариев;
? навыки, необходимые для эффективного использования GitLab-CI в своих проектах;
? способы улучшения процесса разработки и сокращения времени выкладки новых изменений в продуктивную среду.

А для тех, кто хочет глубже погрузиться в тему, мы подготовили Навыкум CI/CD. На нем вы сможете окунуться в мир практических задач, пополнить портфолио реальными кейсами и вырасти до нового уровня в своей профессии. Стартуем в декабре?

Регистрируйтесь на вебинар, чтобы ничего не пропустить?

В конце марта Мстислав Казаков, руководитель практики Python ГК Юзтех, провёл внешний Usetech Meetup на тему «Как писать Gitlab CI файлы которые легко понимать, расширять и поддерживать».  

С ростом проекта и увеличением количества автоматизированных операций содержимое Gitlab CI файла превращается в спагетти-код. 

На примере демо проекта Мстислав поделился подходами, которые помогли ему решить эти проблемы. Спойлер: проблема решалась при помощи include, reference, rules и манипуляций с Docker.

Демо проект (или эталонный проект) – это монорепозиторий (представлен на изображении ниже). Он содержит 10 сервисов, монолит с беком и фронтом и несколько внутренних библиотек. Если говорить о тестовых средах, обновлениях, релизных циклах, и т. д., то их 3. В первой среде находится актуальная develop версия проекта, во второй среде тестируется release candidate, а третья среда предназначена для end-to-end тестов.

1,5 месяца назад мы запустили первый поток по обновленному курсу CI/CD на примере Gitlab CI. Следующий поток стартанет в октябре, но зачем ждать, если видеокурс всегда доступен к изучению. В нем вам доступны 12 тем, в каждой из которых есть практические задания с автопроверкой на наших готовых стендах.

20 июня в Слёрм стартует усовершенствованный курс «CI/CD на примере Gitlab CI». Пройдём путь от создания самого простого пайплайна до настройки сложных вариантов CI/CD с возможностью отката на предыдущую версию.

Breaking news: мы не только доработали программу, но и добавили новый формат обучения! Помимо классического видеокурса вам доступно обучение в потоке, которое поможет усилить мотивацию и не сбавлять темп.  

13 октября у нас стартует новый практический курс по DevOps Tools. На нём пройдёмся по основным эксплуатационным инструментам — расскажем, как они связаны архитектурно и как выглядит инфраструктура в целом.  

Приходите к нам на открытый вебинар «CI/CD: как, зачем, для чего» от Lead DevOps в Naviteq (ex. Onesoil and EPAM) Александра Довнара 5 октября в 19:00 (мск).

На вебинаре расскажем, что это за зверь такой, кому и когда нужен CI/CD и зачем применять его в команде, а также обсудим текущие проблемы индустрии вокруг этой практики.

6 сентября стартует курс по Jenkins от Кирилла Борисова, Infrastructure Engineer технологического центра Deutsche Bank. В курсе будет много кейсов и примеров из практики спикера. 

Вы научитесь автоматизировать процесс интеграции и поставки, ускорять цикл разработки и внедрять полезные инструменты, настраивать плагины и создавать пайплайны Jenkins as a code, работать с Jenkins Shared Library и многое другое.

В этой статье мы рассмотрим, как развернуть собственный GitLab сервер и GitLab Runners с использованием Docker Compose. Это руководство поможет вам создать локальную среду для изучения и практики GitLab CI/CD. Мы пройдем через все этапы: от настройки контейнеров до регистрации раннеров и создания примера CI/CD пайплайна. Независимо от того, новичок вы в CI/CD или опытный разработчик, этот гайд предоставит вам ценные знания для улучшения вашего процесса разработки.

CI/CD помогает разработчикам сократить затраты на развертывание и настройку проектов, позволяя им сконцентрироваться на решении бизнес-задач. Gitlab — чрезвычайно мощная платформа, и мы рекомендуем присмотреться к использованию средств CI/CD, которые она представляет.

В этой статье мы рассмотрели один из самых простых сценариев использования Gitlab CI.

Подход к ведению тестовой документации и выбранные для этого инструменты — важная часть процесса разработки, которая напрямую влияет на качество продукта. Особенно важно поддерживать тестовую документацию в актуальном виде. Qase может быть одним из подходящих для этого инструментов. Кроме того, он помогает объединить мир ручного тестирования с автоматизированным, а описанные тест-кейсы — с их исполнением.

В статье мы рассмотрим реализацию связки Qase с Playwright и GitLab CI, которую мы используем в SmartHead: от создания проекта до получения отчетов об автоматизированном тестировании.

Привет, я Саша Снытко, и я руковожу командой BI в Data Office Tele2. Мы уже рассказывали здесь о миграции на Fine BI, если быть точнее, о нашем опыте мониторинга пользователей. Сегодня речь пойдет о кардинально другой теме – разработке Telegram-бота для корпоративных каналов и чатов. Задача, которая родилась из потребности следить за составом подписчиков чата Data Office и выросла в полноценный корпоративный инструмент.

В статье мы с главным разработчиком нашего бота (спойлер: стажером команды, которая проявила инициативу и вызвалась заняться этой нетривиальной задачкой) рассказываем о своем опыте разработки в Telegram API на основе библиотек Telebot и Telethon. Еще объясним, как смогли обойти ограничение Telegram по выгрузке в 200 пользователей и настроили интеграцию с корпоративным LDAP-каталогом. Ну и куда без дашборда статистики активности Tg-каналов в Fine BI. В свое время нам не хватило прикладного DIY-материала, и мы проходили весь путь с граблями и шишками самостоятельно. Надеемся, что эта статья поможет кому-то из вас. А те, кто уже прошел этот путь, подскажут нам новые пути решения и возможности апгрейднуть наш сервис.

Как-то очень давно наш отдел автоматизации внутренних процессов посетил админ (ops) с идеей помочь нашим тестировщикам. Основная идея был упростить деплой т.к. было очень неудобно писать ручные curl запросы к gitlab'у с кучей меняющихся параметров. Так заставили нас наша команда решила помочь дружественному отделу и сделать их работу более приятной.

В статье я постараюсь поделиться тем, как мы разрабатывали GUI для curl'a, а сделали очень крутой сервис автоматизации. А также с какими проблемами столкнулись и как их решили (или нет).

За последние несколько лет я очень полюбил GitLab CI. В основном за его простоту и функциональность. Достаточно просто создать в корне репозитория файл .gitlab-ci.yml , добавить туда несколько строчек кода и при следующем коммите запустится пайплайн с набором джобов, которые будут выполнять указанные команды.

А если добавить к этому возможности include и extends, можно делать достаточно интересные вещи: создавать шаблонные джобы и пайплайны, выносить их в отдельные репозитории и повторно использовать в разных проектах без копирования кода.

Но к сожалению, не всё так радужно, как хотелось бы. Инструкция script в GitLab CI очень низкоуровневая. Она просто выполняет те команды, которые ей переданы в виде строк. Писать большие скрипты внутри YAML не очень удобно. По мере усложнения логики количество скриптов увеличивается, они перемешиваются с YAML делая конфиги нечитаемыми и усложняя их поддержку.

Мне очень не хватало какого-то механизма, который бы упростил разработку больших скриптов. В результате у меня родился микрофреймворк для разработки GitLab CI, про который я и хочу рассказать в этой статье (на примере простого пайплайна для сборки docker-образов).

Многие компании используют сертификаты, подписанные внутренними удостоверяющими центрами (Certificate Authority) для ресурсов в приватных сетях. Поскольку такие сертификаты по умолчанию не могут быть доверенными, почти на каждом этапе вокруг пайплайна могут возникать ошибки такого рода: x509 certificate signed by unknown authority. Из-за этого до каждого компонента необходимо доставлять корневые сертификаты, используемые в компании. В статье расскажу, как это можно сделать.

Статья подготовлена на основе моего материала в курсе «CI/CD на примере Gitlab CI», первые его темы доступны в бесплатном мини-курсе.

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

Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:

• Собирает исходный код и установщик приложения
  
  • проставляет номер сборки, каждый раз увеличивая последнюю цифру. Например, текущая версия нашего ПО 3.3.0.202 – часть 3.3.0 когда-то ввёл разработчик (привет, SemVer), а «202» проставляется в процессе сборки.
  • В процессе анализирует качество кода (с использованием SonarQube) – и отправляет отчёт во внутренний SonarQube,
• Сразу после сборки запускает автотесты (xUnit) и анализирует покрытие тестами (OpenCover),

Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:

• отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
• публикация файлов в систему автообновления ПО.

Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.

Цель статьи - показать один из возможных подходов для организации гибкого развёртывания dev/test стендов. Показать какие преимущества предоставляет нам IaC подход в сочетании с современными инструментами.

Всем привет. Меня зовут Сергей, я работаю в digital-агентстве Convergent лидером команды бэкэнд разработки. Одно из основных направлений работы агентства ⸺ это разработка под заказ веб-приложений. Такая деятельность подразумевает, что зачастую создается достаточно много однотипных проектов. Они могут отличаться механиками, но основные юзкейсы повторяются: регистрация, авторизация, личный кабинет, админка и т. д. В данной статье я хочу рассказать о том, как мы оптимизировали процессы переиспользования кода и пришли в итоге к модульному подходу, ну и затрону еще немного технической стороны вопроса. Основной язык программирования в компании — PHP, так что дальше я расскажу о работе с этим языком. В нашем случае он отлично подходит для создания сайтов различного уровня сложности, различных активаций и промо-кампаний.

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

В скриптах деплоймента (или в моем случае еще и в настройках GitLab репозитория), нужно сформировать токены/ключи доступов к докер реджистри, кубернетесу, разным кластерам и т.д. И если у вас пару сервисов, то это не проблема, но если сервисов 15-20, то это весьма болезненный процесс. Особенно, когда настройки кластера меняются и нужно эти изменения вносить во все репозитории.

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

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

И вот мы решили использовать монорепозиторий, но с чего начать и как все организовать?

Расширяем знания и переходим на следующий уровень