DevOps и безопасность — одни из немногих профессий, устойчивых к кризису. Если изучаете DevOps или прокачиваетесь в безопасности — этот цикл статей для вас.
Часть 2 серии об осмысленном CI/CD: настраиваем self-hosted GitLab Runner. Пройдем от docker-compose.yml до работающего runner, попутно разбирая ошибки permissions, SELinux context и особенности rootless Podman. Все то же самое актуально и для Docker.
В этой статье мы рассмотрим процесс подключения GitLab к 1С Элементу и настройку групповой разработки в проекте.
Благодаря этому мы получим полный функционал: формирование задач, веток разработки и релиза, историю изменений.
Версия 1С Элемент: 8.0 и выше.
Тип установки 1С Элемент: Локальный
Версия Git: 2.45 и выше
Подключение GitLab
Так как мы используем локальную установку 1С Элемент на своем сервере, то первое, что требуется сделать - это на сервере с 1С Элементом установить и настроить Git (система контроля версий).
Как его устанавливать и настраивать - есть отдельная инструкция, которая доступна в справке 1С Элемента в разделе «Руководстве разработчика» → «Среда разработки» → «Git».
Ссылка на справку из 8.0 - https://1cmycloud.com/console/help/element/8.0/docs/topics/git-installation/
После установки Git, в панели управления 1С Элемента станет доступно Хранилище репозиториев.
Практический разбор того, как я вынес security-проверки Java-проектов из разрозненных CI/CD-скриптов в переиспользуемый Gradle plugin
Единый плагин для сканирования на безопасность Java проектов. Maven. Или как проверять кучу микросервисов на безопасность управляя этим в одном месте
29 апреля 2026 года Митчелл Хашимото объявил, что уводит свой Ghostty с GitHub. Цитата ушла на главную Hacker News через статью в The Register: «GitHub больше не место для серьёзной работы, если он каждый день блокирует тебя на часы».
Сам по себе уход одного человека, даже такого, как Хашимото, ещё не новость. Новость в другом: на главной HN на той же неделе оказалось ещё четыре истории про GitHub. Эссе Армина Ронахера про то, как мы жили до GitHub. Манифест команды Tangled про федеративные форджи. Тихий запуск голландской госплатформы для опенсорса на Forgejo. И жёсткий аудит безопасности того же Forgejo от Жюльена Вуазана. Если посмотреть на эти пять текстов вместе, складывается одна история.
Хашимото — не случайный пользователь GitHub. Сооснователь HashiCorp, после ухода оттуда автор Ghostty. И, по его собственным словам, «пользователь GitHub номер 1299, зарегистрирован в феврале 2008-го». Он же говорит про себя как про человека, который «листает задачи на GitHub с тех пор, когда у такого поведения ещё не было названия». Если GitHub для кого-то и был домом, то для него.
Необычным его пост делает разбор последнего месяца. Хашимото вёл журнал дат и ставил «X» против каждого дня, когда GitHub упал и помешал ему работать. «Почти каждый день стоит отметка X», пишет он. «В день, когда я пишу этот пост, я уже два часа не могу сделать ни одного ревью пулл-реквестов, потому что лежат GitHub Actions». The Register заметил, что пост вышел прямо перед инцидентом 28 апреля, когда пулл-реквесты перестали завершаться из-за падения Elasticsearch.
Все русскоязычные гайды по GitLab CI/CD — это «сделай вот так под Node.js/Java/.NET». А как оно вообще работает? Написал подробный туториал: термины, схемы, разбор .gitlab-ci.yml, логи runner’а построчно. Первая часть из трёх — от простейшего pipeline до понимания, что конкретно вам нужно в вашем случае.
При работе с Claude Code я столкнулся с проблемой: по мере роста числа агентов стало сложно синхронизировать их правила между машинами и окружениями. Параллельно возник риск — потерять все наработки (скилы, команды, конфигурации) при смене аккаунта или среды.
Я решил считать ~/.claude/ обычным кодом и хранить его в Git.
Так появился claude-config-template — репозиторий, из которого ~/.claude/ собирается через симлинки. В нём лежат скилы, агенты, команды, хуки и MCP-конфигурации.
Это даёт:
- переносимую конфигурацию между машинами
- единый источник правды для всех агентов
- версионирование и откат через Git
Как мы автоматизировали сборку Unity-проектов под несколько платформ: прошли через Jenkins, GitHub Actions с game-ci и сорокаминутные билды — и в итоге написали собственный инструмент.
В статье:
Почему Jenkins и GitHub Actions не подошли
Что такое Unity Builder и какую боль закрывает
Визуальный пайплайн, параллельные задачи, FTP-интеграция
Почему для некоторых GitHub перестал быть безопасным дефолтом, и что с этим делать - если вы, конечно, не хотите узнать об этом в день блокировки аккаунта или когда ваши закрытые репозитории могут общественным достоянием?
Думаю, для многих GitHub почти стал именем нарицательным. Помню, как я не знал, что такое git, но уже публиковал исходный код маленькой игры на GitHub через загрузку файлов. Многое было другим на тот момент: ИТ не был на пике мейнстрима, ИИ казался чем-то очень далеким и GitHub был де-факто стандартом.
Времена меняются и довольно быстро: теперь многие задаются вопросом так ли перспективен ИТ, появились LLM, которые используются ежедневно, GitHub уже не справляется с нагрузкой, а его приватные репозитории оказывается не такие уж и приватные.
28 апреля 2026 года стало по-настоящему плохим днём для GitHub. Утром CTO платформы опубликовал длинное извинение за кризис стабильности - 8 серьёзных сбоев за два месяца. Этим же днём Wiz Research опубликовал детали критической уязвимости CVE-2026-3854: один обычный git push мог выполнить произвольный код на серверах GitHub.
По порядку разберём и свежие, и давние события с точки зрения обычного разработчика, которые происходят с GitHub сейчас
Мы пытались отправлять уведомления о деплое из GitLab CI в MAX Messenger и долго шли по ложному следу, потому что проблема выглядела как сетевая. Но MAX API честно подсказывал обратное: proto.payload означал, что запрос доходит, а ломается именно body. В итоге решение оказалось не в DNS, а в минимальном JSON payload, очистке переменных окружения и отказе от хрупких shell-конструкций внутри CI job.
Все мы сталкивались с классическими алгоритмами на курсах, олимпиадах или собеседованиях и, куда более редко, на практике. Но даже в реальной разработке возникают ситуации, когда готового решения нет, а простое не подходит.
Расскажу как раз о такой задаче, над которой работала наша команда, — поиск по коду относительно произвольного коммита. Покажу, как много вариантов мы перебрали, что в итоге выбрали и почему.
В последнее время я часто работал с разными ML-проектами в GitLab. В каждом был свой .gitlab-ci.yml, своя обвязка вокруг MLFlow, своя регистрация и валидация модели. Со временем я понял, что MLOps-пайплайн во всех проектах очень похож, а при работе с новыми копипаста размножается быстрее кроликов. Ну и тут уже хочешь не хочешь, но идея сделать общий шаблон напрашивается. Однако будем честны, обычный template для CI — это круто, но хочется чего-то гибкого, декларативного и красивого. Для достижения этих целей GitLab уже давно предлагает переходить на CI/CD компоненты. В результате я хотел видеть 10 строк YAML, которые будут выдавать полноценный пайплайн с валидацией данных, обучением, quality gates и регистрацией модели.
И спустя месяц я добился желаемого. В этой статье покажу, как устроен компонент, на какие грабли наступал по пути, и как подключить всё это в ваш проект.
Когда проектов в GitLab становится много, довольно быстро появляется одна и та же задача: найти, где используется конкретный API, URL, env-переменная или конфигурационный параметр.
Пока репозиториев мало, всё просто: открыл поиск, ввел строку, получил результат. Но когда проектов уже больше сотни, а нужные вхождения лежат не только в коде, но и в YAML-конфигах, Helm-чартах, .env и JSON-файлах, жизнь становится менее романтичной.
Первый лобовой вариант — просто скачать все проекты локально и искать по ним через grep, ripgrep или IDE. Работает, но тащить 100+ репозиториев на локальную машину ради одной проверки — идея так себе. Ноутбук, скорее всего, энтузиазма не разделит.
Мне хотелось искать прямо поверх GitLab, без локального зеркала всей группы репозиториев. Я начал с просмотра готовых вариантов, а в итоге пришёл к своему гибридному краулеру: код ищется через GitLab API, а конфиги добираются отдельным глубоким обходом файлов. В результате поиск по 100+ проектам сократился с часов до нескольких минут.
Один клик — и ваша документация может исчезнуть. Именно так и произошло с нами. Поэтому мы нашли open-source альтернативу, где данными владеем только мы — и никакой регион это не изменит.
Несколько месяцев назад я делал плановую проверку кодовой базы на одном из проектов и нашёл обфусцированный код в файле vite.config.js. Он был на той же строке что и закрывающий };, но сдвинут вправо на несколько сотен пробелов — туда, куда ни один diff-вьюер не прокрутит и ни один редактор не покажет без горизонтального скролла.
Я пошёл смотреть через git log — какой коммит это принёс. Оказался merge-коммит. Не обычный коммит в ветке — именно merge. И вот тут началось интересное.
Время вялого вайбкодинга и медленных пайплайнов заканчивается.
И пока большинство CI/CD инструментов помогают вам деплоить. GitCrab заставляет вас бороться.
Статья о том, какие неочевидные вещи можно узнать о вас из логов гита. Методы ниже не бьют на 100%, но «щито поделать, десу».
Собрали гайд по работе с Git для новичков.
Разберём, как Git хранит изменения, какие команды нужны для базовой работы с репозиторием и ветками и какие ошибки чаще всего допускают новички. Все команды показываем на примерах в терминале, чтобы их можно было сразу попробовать.
Сохраняйте и пользуйтесь.
Собрала актуальный маршрут обучения Claude Code: с чего начать, какие доки и курсы пройти, и как перейти от просто попробовать к автоматизациям (skills/hooks/sub-agents/MCP).
Все ресурсы разложила в правильном порядке и коротко объяснила, как именно их проходить, чтобы не утонуть в ссылках и сразу получить результат.
Поиск по коду — одна из тех функций, ценность которых ощущается мгновенно. Она либо есть и экономит часы, либо её нет — и ты начинаешь открывать файлы вручную, клонировать репозиторий, запускать find или средства своей IDE и вспоминать «где же это было».
Мы добавили в GitVerse поиск по коду в репозиториях. и сделали это быстро. Не потому что «срезали углы», а потому что опирались на инструмент, который десятилетиями решает задачу поиска по коду внутри Git: git grep. Пока другие поднимают тяжёлые поисковые платформы, возводят кластеры, строят индексаторы, мы выбрали простое и проверенное решение, которое работает прямо сейчас.
