Я как-то писала про Claude Code. По ощущениям, многие вайбкодеры сейчас выбирают его как основную CLI-среду для агентского кодинга. Между Codex, Gemini и Claude Code часто выбирают последний- за быстрые итерации и удобство. Собрала в одном месте полезные ресурсы про Claude Code.
Всем привет!
В первой части мы в общих чертах посмотрели на различия GitHub Actions и GitLab, а также начали разбирать структуру файла .gitlab-ci.yml.
В этой части продолжим разбираться с параметрами и особенностями конфигурации: триггеры, job’ы, артефакты и многое другое.
Не понимаете, «что тут происходит»? Рекомендую начать с первой части:: по ссылке.
Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.
Я Олег Одинцов, платформенный инженер 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, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.
Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».
Привет, Хабр!
Представим, что вы отвечаете за десятки конфигурационных файлов 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. Идея проста: вы ставите цели, а агенты пишут и проверяют код, тестируют и готовят диффы, а разработчик смещается к роли менеджера ИИ-процесса. В статье разбираемся, что именно появилось, на чем это работает и какие ограничения важно учесть.
Обнаружение бэкдора в 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, чтобы гарантировать его защиту, потому что таких руководств и так уже много.
Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.
Представьте, что вы 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.
Есть такой род статей на Хабре — читаешь ее и думаешь — вот как она была написана? Материал большой, длинный, много кода, и он в процессе повествования эволюционирует, улучшается. Автор показывает результаты выполнения, прогоны, бенчмарки. У статьи есть сюжет, драматургия, насколько это возможно для технической статьи — баги, тупики, отчаяние, метания и неожиданные озарения.
Я не раз вопрошал в восхищении: "вот как?..". Ведь если задуматься — чтобы автору выплеснуть на вас все палеонтологические слои своего кода, все версии от самых ранних и неуклюжих шагов к цели до матерого кода, обросшего абстракциями — как автор должен выстроить свою работу, чтобы в результате статья случилась такой, какой она есть?
Привет! Меня зовут Дима Иванов, я руковожу SourceCraft — это платформа для разработки, которая поддерживает полный цикл работы с кодом.
За последние два года ИИ‑революция изменила инструменты разработки и сделала кодогенерацию массовой и доступной, меняя наши представления об эффективности. В 2021 году появился GitHub Copilot — первый массовый помощник для написания кода, а сегодня нейросети и специализированные опенсорс‑решения помогают разработчикам на многих этапах создания ПО.
Совместно с коллегами из Университета ИТМО мы захотели больше узнать, как такая ситуация влияет на работу российских специалистов. Мы провели исследование рынка разработки, чтобы понять, что нейросети меняют в его отечественном сегменте. Выяснили, как ИИ‑инструменты для разработки изменили ежедневную рутину IT‑специалистов, какие кодовые ассистенты приживаются в командах и каким видят будущее профессии программисты и выпускники профильных специальностей.
