Git *

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

Мне приходилось внедрять ИИ в продакшн-среду в разных доменах — от классических моделей классификации до разворачивания собственных серверов под локальные LLM и интеграции генеративных моделей для усиления командной работы. В каждом случае вывод оказывался одинаковым.

Большинство инженерных проблем при работе с ИИ по-прежнему лежит в области дисциплины и мышления, а не в технологиях. Поэтому привычные инженерные практики требуют переосмысления.

Я как-то писала про Claude Code. По ощущениям, многие вайбкодеры сейчас выбирают его как основную CLI-среду для агентского кодинга. Между Codex, Gemini и Claude Code часто выбирают последний- за быстрые итерации и удобство. Собрала в одном месте полезные ресурсы про Claude Code. 

Всем привет!

В первой части мы в общих чертах посмотрели на различия GitHub Actions и GitLab, а также начали разбирать структуру файла .gitlab-ci.yml.

В этой части продолжим разбираться с параметрами и особенностями конфигурации: триггеры, job’ы, артефакты и многое другое.

Не понимаете, «что тут происходит»? Рекомендую начать с первой части:: по ссылке.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

В этой статье мы рассмотрим, как использовать нейросети для описания кода через VS Code и как вносить изменения в описание в репозитории с помощью MCP-сервера GitHub.

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

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

В экосистеме 1С исторически существовало собственное хранилище кода, и Git долгое время казался чужаком. Но прогресс не стоит на месте, сейчас 1C:Enterprise Development Tools умеет работать с Git по дефолту, поддерживает групповую разработку и Git‑хуки. Хуки — это скрипты, которые автоматом выполняются при наступлении определенных событий в репозитории: коммит, пуш, слияние и так далее.

Я Олег Одинцов, платформенный инженер App.Farm. App.Farm — собственная разработка Россельхозбанка, которая используется для стандартизации процессов разработки программного обеспечения и предоставления высокоуровневого интерфейса пользователям для автоматизации их задач. Можно сказать, что App.Farm — это автоматизация «под ключ». Пользователь получает полный цикл управления разработкой от размещения кода до деплоя приложений. Более «смузийное»  название — IDP платформа.

Всем привет!

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

Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.

У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

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

Привет, я Павел Таланов из команды Yandex Infrastructure. Вместе с командой мы создаём SourceCraft — платформу для полного цикла разработки IT‑продуктов. Хочу рассказать о прикольной задаче на стыке бэкенда и IDE, которую мы решали, чтобы сделать ещё более удобную навигацию по коду в SourceCraft — когда индексация кода проходит с нужной скоростью, а подсказки и другие фичи навигации всегда готовы к открытию пул‑реквеста.

Расскажу про требования, которые мы выявили для поиска по коду, чуть‑чуть про предметную область, а также о том, какая архитектура индексации у нас в итоге получилась — и почему.

Когда я закончил работать над проектом ecosyste-ms/package-manager-resolvers, мне стало интересно, какой алгоритм разрешения зависимостей использует сервис GitHub Actions. Когда вы записываете в файл рабочего потока uses: actions/checkout@v4, то объявляете зависимость. GitHub её разрешает, скачивает и исполняет. Так работает управление пакетами. Я же решил отправится в кодовую базу runner, чтобы увидеть весь этот процесс изнутри. И открытия, скажу я вам, оказались весьма тревожными.

Привет, на связи Ксюша, миддл-разработчик Surf. Миддлом я стала недавно. Когда я пришла в компанию, я, конечно, знала, что такое Git. Ну, по крайне мере, я так говорила. 

Как-то я, по чистейшей случайности, разумеется, перезаписала чужую ветку. А потом потратила часов 6, чтобы вернуть всё «как было». Благо, помог наш лид, который показал, что делать.

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

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

Не стесняйтесь, и присылайте свой проект на конструктивный разбор!

Привет, Хабр! Я Алексей Шаманов, старший системный архитекторов ГК «Цифра», занимаюсь проектированием решений на базе платформы ZIIoT. Сегодня предлагаю поговорить об использовании SSH для подписи коммитов в git.

Не понимаете, что такое SCA?

Устали триажить ложные срабатывания опенсорсных инструментов SCA?

Хотите повысить безопасность ПО и любите бесплатные сервисы?

Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.

Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».

Telegram-бот для администрирования VPS tgbotvpscp получил модульную архитектуру, полную поддержку английского языка, возможность установки в Docker и десятки улучшений. Рассказываю, что сделано и что будет дальше: WebUI, CLI и архитектура «агент-нода».

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

Представим, что вы отвечаете за десятки конфигурационных файлов Kubernetes (или Terraform, Ansible, не суть важно) в репозитории, и каждый pull request может потенциально привести к тому, что в кластер уйдёт что-то не то. Наш любимый коллега случайно поставил контейнер с privileged-правами, другой задеплоил образ из публичного репозитория Docker Hub, а третий вовсе забыл про лимиты памяти и CPU. Без автоматического контроля такие промахи легко попадут в продакшн. Ошибки в настройках сегодня одна из главных причин инцидентов безопасности в облачных средах.

Как же нам держать всё под контролем? Внедрить политики как код: формализованные правила, проверяемые автоматически на каждом шаге. В этой статье я расскажу, как применять Open Policy Agent и язык Rego, чтобы навести порядок в GitOps-пайплайне и не допускать лишнего в конфигурациях.

Claw Engine: как студенты из НИУ ВШЭ релизнули MVP игрового движка

Всем привет! На связи Bear Head Studio, команда Claw Engine. Мы рады сообщить об открытом релизе нашего игрового движка :)

В конце октября 2025 Anysphere представила Cursor 2.0 — крупное обновление AI-IDE с параллельными агентами и новой моделью Composer. Идея проста: вы ставите цели, а агенты пишут и проверяют код, тестируют и готовят диффы, а разработчик смещается к роли менеджера ИИ-процесса. В статье разбираемся, что именно появилось, на чем это работает и какие ограничения важно учесть.

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

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

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

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

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

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

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

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