Git *

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

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

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

В этой статье мы рассмотрим проектирование импульсных источников питания: ключевые параметры и распространенные ошибки.

Импульсные источники питания (SMPS) стали стандартом в современной электронике благодаря высокому КПД, компактности и гибкости применения. Однако их проектирование связано с рядом сложностей: от правильного выбора топологии и компонентов до грамотной разводки печатной платы и обеспечения электромагнитной совместимости.

Привет! Меня зовут Дима Иванов, я руковожу 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 и протестировали разные атаки. В этой статье — разбор протокола и ключевых рисков безопасности.

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

А Claude Code, как передовой инструмент AI-программирования, не только полностью совместим с рабочими процессами Git, но и благодаря глубокой интеграции предоставляет разработчикам беспрецедентную автоматизацию и удобство.

Из этой статьи вы получите следующее:

Своевременное выявление уязвимостей в коде является одной из важнейших задач конвейера CI/CD, ведь чем раньше мы обнаружим ошибку в коде, тем дешевле нам обойдется ее исправление. Для решения этой задачи существует множество различных решений. Но если мы используем конвейер CI/CD то нам необходимо интегрировать наш анализатор в этот процесс. Однако, в GitLab имеется своя функциональность для анализа исходного кода. В этой статье мы настроим GitLab SAST для автоматического анализа исходного кода на наличие уязвимостей.

В современном ИТ ландшафте множество методологий имеют в своем названии упоминание Ops: DevOps, ChatOps, MLOps и другие. По сути, все они так или иначе являются порождением философии DevOps и сегодня мы поговорим о GitOps — подходе к управлению инфраструктурой и развёртыванием приложений, который использует репозиторий Git в качестве центрального механизма.

GitOps позволяет командам декларативно определять конфигурацию инфраструктуры и приложений, а затем автоматически развёртывать их. Основная идея GitOps заключается в использовании Git как единого источника данных для декларативной инфраструктуры и приложений.

В этой статье мы рассмотрим, те преимущества, которые дает использование GitOps, а также развеем некоторые мифы вокруг GitOps..

Статья для разработчиков, которые устали от сложностей Git и хотят навести порядок в своих проектах. Я расскажу про Jujutsu (jj) — современную альтернативу, которая меняет подход к контролю версий. Без веток, без stash, без мучительных rebase -i — только чистая история и удобный workflow, который позволит вам фокусироваться на написании кода, а не на борьбе с системой. Готовые примеры и наглядная демонстрация возможностей внутри.

Вышел релиз GitLab 18.2 с Duo Agent Platform в IDE (бета-версия) и настраиваемыми статусами рабочего процесса для тикетов и заданий

git commit -m "WIP" — три слова, после которых начинается настоящий ад.

Доброго времени суток. Такая технология как Git в представлении не нуждается. Все знают add, commit, push — это как азбука. Но что делать, когда что‑то пошло не так? Ошибочный коммит прокатился по ветке? Надо срочно переключиться, но незавершенные правки мешают? Нужно перенести только одно исправление из другой ветки?

Знакомая ситауция? Тогда давайте разберем 5 команд, которые выходят за рамки базового workflow и реально спасают репутацию (и ваши нервные клетки).

Изначально я занимался одним проектом со стороны тестирования в роли старшего тестировщика. У нас микросервисная архитектура — около 15 сервисов хранится в Git. Для тестирования на стенде нужно развернуть примерно 5–7 сервисов за один релиз. Всего стендов два, и после тестирования их же нужно деплоить в продакшн.

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

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

Поэтому мне приходилось делать так: заходить в каждый проект, открывать репозиторий сервиса, искать меню «Operate», затем «Environments» и там уже смотреть нужный стенд. И так — для каждого сервиса при деплое на тестовый стенд, при обновлении в продакшн или во время тестирования.

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

Экосистема продуктов 1С содержит много различных полезных инструментов разработки. Одним из них является 1C:EDT (1C:Enterprise Development Tools) — расширяемая среда разработки прикладных решений, созданная на основе свободной интегрированной среды разработки модульных кроссплатформенных приложений Eclipse.

1C:EDT поддерживает ключевые принципы создания прикладных решений на платформе «1С:Предприятие 8» и содержит большое количество инструментов автоматизации разработки, делающих работу программиста более быстрой и комфортной, а также позволяет расширять функциональность инструментов разработки с помощью технологии плагинов.

В этой статье мы поговорим о том, как интегрировать 1С:EDT с системой контроля версий Git для того, чтобы сделать разработку более эффективной.

Ходит легенда, что однажды разработчики GitLab закупились шапками, сделанными из переработанных крышечек от бутылок. И их настолько вдохновила идея повторного использования, что они решили добавить такую возможность и в свой продукт. Подкрепив это всё стандартизацией CI, они представили комьюнити новый механизм — GitLab CI/CD components.

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

Когда я был еще джуном, старшие разработчики настоятельно советовали мне перейти на zsh. Я помню, что я так и не получил никакой аргументации, чем zsh лучше привычного bash, и какую конкретно пользу я получу от перехода.
Что ж, в этой статье я хочу ответить на эти вопросы тем, кто еще только задается этим вопросом, с небольшим уклоном к PHP разработке

Zsh это командная оболочка, то есть программа, которая получает от пользователя команду в текстовом виде и выполняет соответствующие исполняемые файлы, найденные по путям, указанным в переменной окружения PATH.
Zsh является дефолтной оболочкой для macOS, на linux дефолт - bash. Zsh лучше, чем bash в основном благодаря своей очень обширной системе плагинов, модулей, различных тем и т. д.

Например, установив вот такой плагин.

Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.

По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.