Git *

Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.

Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.

В этой статье я делюсь реальным опытом:

- как мы ушли от ручных релизов к автоматическому деплою в прод;

- какие практики и инструменты позволили нам перестать бояться каждого коммита;

- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.

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

А как мы этого добились — читайте под катом!

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

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

Обнаружение бэкдора в XZ Utils весной 2024 года поразило опенсорс-сообщество и подняло серьёзные вопросы о безопасности цепочки поставок ПО. В этом посте мы изучим, могло ли улучшение практик работы с пакетами Debian помочь в выявлении этой угрозы, приведём руководство по аудиту пакетов и предложим улучшения на будущее.

Бэкдор XZ в версиях 5.6.0/5.6.1 быстро попал во многие крупные дистрибутивы Linux наподобие Debian и Fedora, но, к счастью, не добрался до многих реальных пользователей, потому что благодаря героическому усердию Андреса Фройнда релизы с бэкдором были быстро удалены. Нам крайне повезло, что мы выявили регрессию производительности SSH в полсекунды, уделили время её трассировке, обнаружили зловредный код в загружаемой SSH библиотеке XZ и быстро сообщили о нём различным командам безопасников для принятия быстрых координированных мер защиты.

Этот эпизод заставил разработчиков ПО задаться следующими вопросами:

• Почему ни один из упаковщиков дистрибутивов Linux не заметил ничего странного при импорте новой версии XZ 5.6.0/5.6.1 из апстрима?

• Легко ли проводить аудит современной цепочки поставок в самых популярных дистрибутивах Linux?

• Возможно ли наличие других подобных бэкдоров, которые мы пока не выявили?

Я разработчик Debian Developer, поэтому решил провести аудит пакета xz в Debian, поделиться в этом посте своей методологией и находками, а также предложить способы повышения безопасности цепочки поставок конкретно в Debian.

Стоит отметить, что мы ограничимся только изучением способа импорта ПО дистрибутивом Debian из его апстрима, а также его распространения среди пользователей Debian. При этом мы никак не затронем тему оценки соответствия проекта апстрима best practices по безопасности разработки ПО. В этом посте мы не будем и говорить о том, какие меры следует предпринять на компьютере с Debian, чтобы гарантировать его защиту, потому что таких руководств и так уже много.

Сегодня мы с вами на практике разберем что такое динамические матрицы в Github Actions и как с их помощью экономить время и ресурсы на практике.

Я подготовил монорепозиторий с несколькими микросервисами url-shortener-demo с очень коротким флоу: feature_branch(через PR) →  main. Как понятно из названия это проект позволяющий генерировать короткие ссылки.

Если тебе не нравится Jujutsu - ты не прав.

Как и многие разработчики, я пользуюсь git с начала времён - с тех пор, как его команды были непостижимым набором плохо сочетающихся заклинаний. И таким, по большей части, он остаётся по сей день. Не нужно и говорить, что я просто не понимаю git. Никогда не понимал, хотя прочитал кучу материалов о том, как он всё это внутри представляет. Годами я пользовался им, зная, что делают несколько команд, и каждый раз, когда git входил в какое-то странное состояние из-за того, что я промахнулся по клавише, у меня был мой надёжный алиас fuckgit, который удаляет директорию .git, клонирует репозиторий заново во временную папку, переносит оттуда .git в мою директорию - и так я как-то ухитрялся зарабатывать на жизнь и кормить семью.

За последние несколько лет я всё чаще видел, как люди восторгаются Jujutsu, и всегда хотел попробовать, но мне казалось, что возни слишком много - даже несмотря на то, что я ненавижу git. Я лениво почитал несколько туториалов, пытаясь понять, как это работает, но в итоге решил, что это не для меня.

Однажды я случайно решил попробовать снова, но на этот раз попросил Claude объяснить, как сделать в Jujutsu то, что я хотел сделать в git. И вот тогда в моей голове наконец сложилась ментальная модель jj - и я понял всё. Даже то, как работает git. Никогда бы не подумал, что система контроля версий может приносить радость, но вот я тут. И я решил, что, может быть, смогу написать что-то, что заставит jj «щёлкнуть» и у тебя.

В предыдущей статье рассмотрены основы сборки RPM пакета и автоматизации процесса.

Данная публикация завершает цикл. Продемонстрировав практическую реализацию готового решения, включая:

Разработку Web сервиса.

Регистрацию сервиса в качестве системной службы с автозагрузкой (systemd) при установке пакета.

Внедрение централизованного логирования через journald.

В результате создана полнофункциональная заготовка для быстрого развертывания сервисов с последующей публикацией их в RPM пакет.

runo — ассистент для репозиториев, который позволяет забыть о проблемах с настройкой локальной среды разработки и переключаться между репозиториями быстро и безболезненно. Больше не надо запоминать что, где и как можно/нужно запускать и что перед этим требуется сделать — обо всём позаботится ассистент.

При работе с поддержкой GitLab, будь то установка из Omnibus пакета или Docker-контейнер, иногда приходится запускать руки в консоль gitlab-rails. Причин тому может быть много в зависимости от версии GitLab и задач, стоящих перед вами, например, чистка артефактов, исправление ошибок блокирующих обновление, или массовые операции с проектами/пользователями/токенами и так далее.

Некоторые такие задачи может потребоваться запускать регулярно, и как раз на примере одной из них мы и попробуем написать Cron-задание для Sidekiq.

Вы много своих приложений упаковывали, как RPM пакет? Мне, до недавних пор, не доводилось. Тенденция импортозамещения и перехода на OC Linux потребовала освоить и это умение. Ничего сложного, но, как и везде, есть нюансы, детали и особенности.

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

Статья - достаточно подробная инструкция, как решить эту задачу и автоматизировать ее с помощью GitLab CI/CD.

Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.

Представь мир, где каждый сервер, приложение и сетевая конфигурация тщательно оркестрируются через Git, где обновления, аудиты и восстановления происходят с помощью одного коммита. Эти и другие возможности открывает GitOps. Особенно мощно он проявляет себя в сочетании с универсальностью Linux-систем. Как же преобразить управление инфраструктурой Linux? И каким образом с помощью Git добиться ясности, контроля и уверенности в каждом изменении?

Представьте, что вы DevOps-инженер и разработчик просит развернуть новое приложение в Kubernetes. В большинстве случаев в нем будут секреты: логин или пароль от базы данных, ключи для S3-бакета и так далее. Эти секреты желательно спрятать.

Есть несколько способов это сделать. Мы в команде используем HashiCorp Vault. Храним там секреты в формате key-value, откуда они попадают в приложения, развернутые в ArgoCD с помощью ArgoCD Vault Plugin или аналогичных решений. Звучит не очень сложно, но кое-что в такой схеме нам не нравилось: ручное добавление или изменение существующих секретов в Vault, а также необходимость периодически создавать руками новые key-value secrets engine. Еще стоит упомянуть, что Vault используется не только DevOps-инженерами, но и разработчиками, например в их Jenkins-джобах, а у разработчиков нет доступа на запись в Vault, поэтому любой запрос на добавление/изменение секретов с их стороны выполнялся в рамках заведенного на DevOps-инженера Jira-тикета. Тикеты не всегда вовремя замечались в бэклоге, поэтому такая простая задачка, как добавление секретов, могла растянуться на пару дней.

Поэтому процесс взаимодействия с Vault мы в YADRO решили автоматизировать. В статье я расскажу, как можно управлять Vault через подход IaC (Infrastructure as a Code) с использованием OpenTofu — open source-форка Terraform.

Есть такой род статей на Хабре — читаешь ее и думаешь — вот как она была написана? Материал большой, длинный, много кода, и он в процессе повествования эволюционирует, улучшается. Автор показывает результаты выполнения, прогоны, бенчмарки. У статьи есть сюжет, драматургия, насколько это возможно для технической статьи — баги, тупики, отчаяние, метания и неожиданные озарения.

Я не раз вопрошал в восхищении: "вот как?..". Ведь если задуматься — чтобы автору выплеснуть на вас все палеонтологические слои своего кода, все версии от самых ранних и неуклюжих шагов к цели до матерого кода, обросшего абстракциями — как автор должен выстроить свою работу, чтобы в результате статья случилась такой, какой она есть?

краткое описание пути С++ от прямого вызова компилятора в 90х до создания проекта по шаблону в одну команду сегодня

Привет! Меня зовут Дима Иванов, я руковожу SourceCraft — это платформа для разработки, которая поддерживает полный цикл работы с кодом.

За последние два года ИИ‑революция изменила инструменты разработки и сделала кодогенерацию массовой и доступной, меняя наши представления об эффективности. В 2021 году появился GitHub Copilot — первый массовый помощник для написания кода, а сегодня нейросети и специализированные опенсорс‑решения помогают разработчикам на многих этапах создания ПО.

Совместно с коллегами из Университета ИТМО мы захотели больше узнать, как такая ситуация влияет на работу российских специалистов. Мы провели исследование рынка разработки, чтобы понять, что нейросети меняют в его отечественном сегменте. Выяснили, как ИИ‑инструменты для разработки изменили ежедневную рутину IT‑специалистов, какие кодовые ассистенты приживаются в командах и каким видят будущее профессии программисты и выпускники профильных специальностей.

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

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

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в МТС Web Services. Последние несколько лет мне приходилось создавать и адаптировать конвейеры на базе GItLab-CI, изменяя процесс автоматизации под каждую новую команду, стек, продукт и окружения эксплуатации. Чтобы облегчить жизнь себе и коллегам, я сделал небольшой внутренний фреймворк — FundaPipe, значительно упрощающий создание, развитие, переиспользование и применение самих конвейеров разработчиками.

Flutter & GitLab CI/CD. Сборка и подписание мобильных приложений

Привет! Меня зовут Данил Абдрафиков, я мобильный разработчик в компании TAGES. Эта статья является продолжением первой части руководства по настройке GitLab CI/CD для Flutter приложений, в котором мы подробно разобрали настройку физической машины и подготовили GitLab Runner для работы. Теперь, когда инфраструктура готова, перейдем к самому интересному – автоматизации сборки и подписания мобильных приложений.

Готовы превратить сборку мобильных приложений из рутинной задачи в полностью автоматизированный процесс? Тогда начинаем!

Привет, Хабр!

Монорепозитории удобны, пока CI не начинает пробегаться по всему дереву. Сегодня рассмотрим, как на GitLab собрать внятный pipeline для монорепы так, чтобы на каждое изменение реагировали только нужные куски. Базовых кирпичиков тут три: rules:changes, условные include и тонкое клонирование репозитория.

Если вы используете код десктопа, курсор или другие инструменты, то знаете: ИИ уже не просто генерирует код — он читает файлы, делает коммиты, отправляет письма. Эта интеграция работает через протокол MCP, который позволяет подключать серверы буквально в пару кликов. Увидели интересный GitHub-сервер, установили — и готово.

Но у MCP есть обратная сторона: каждый сервер требует широкие права. Gmail-сервер просит полный доступ к почте, GitHub-сервер — ко всем репозиториям, файловый сервер — к домашней папке. Microsoft уже фиксирует рост «теневых MCP-серверов», которые сотрудники ставят без ведома IT-отдела. Palo Alto предупреждает: злоумышленники маскируют вредоносные серверы под полезные.

Мы провели собственное исследование MCP, изучили отчёты Microsoft, Invariant Labs, Trail of Bits и протестировали разные атаки. В этой статье — разбор протокола и ключевых рисков безопасности.