Представлен открытый проект Ghostprovider — терминальный инструмент для быстрого запуска GitHub‑проектов у себя на localhost.
Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.
Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.
для тех, кто пишет код в VS Code, не помнит наизусть флаги git filter-repo и считает, что IDE — нормально. Если ты из лагеря «настоящие программисты сидят в vim и пишут всё в Makefile» — просто пролистай
git-private2public как .gitignore, но чтобы сделать зеркало приватного репо одной git push.
Что это
CLI-тулза. Держит два репо в синхроне: приватный (ваш рабочий бардак) и публичный (чистая версия). При пуше автоматически вычищает секреты и обновляет публичный mirror.
Конфиг — папка .gitpublic/, как .gitignore. По одной маске на строку, без YAML.
.gitpublic/
config — source / target / push
ignore — что НЕ публиковать
replace — что заменить (==> без кавычек)
scan — что не должно попасть, иначе падаем
allow — но конкретно эти можно пропускать в пуш,
Файла нет → настройки нет. Просто.
Автопуш через git hook
pip install git-private2public
cd ~/my-private-repo
git-private2public init
init создаёт пять пустых файлов с закомментированными примерами. Дальше правите то, что нужно:
Авторизация без перехода на главную. На портале для чтения при переходе по ссылке на закрытую статью окно входа открывается прямо на месте — больше не нужно идти на главную. После входа пользователь сразу попадает на нужную статью.
Обновленный интерфейс настроек пространства. В окне настроек GES-пространства боковую панель теперь можно свернуть значком в верхней части — рабочей области отдается больше места.
Общие изменения:
Режим ревью комментариев. Просматривать и анализировать комментарии стало удобнее: в правой панели открывается список по текущей статье или всему каталогу. Можно быстро переходить между комментариями стрелками, искать по содержимому, фильтровать по дате и автору, а также сортировать и группировать.
История изменений каталога. Окно Сравнение ревизий выросло в полноценную историю изменений: теперь можно просматривать все изменения в каталоге, фильтровать их по автору и дате, открывать каталог в состоянии на любой момент и сравнивать любые две версии между собой.
Улучшения окна публикации. Кнопка Редактировать Markdown убрана из меню статьи — теперь переключиться в режим редактирования Markdown можно через кнопку Исходный текст в нижнем тулбаре.
Кнопка переключения Двухпанельный режим перенесена туда же и появляется при выборе статей в окне публикации. Теперь обе кнопки всегда под рукой при просмотре и сравнении изменений.
Изменение размера диаграмм. Для диаграмм Mermaid, Drawio и PlantUML добавлена возможность изменения размера с помощью ползунка — так же, как у изображений. При необходимости диаграмму можно растянуть за пределы ширины статьи.
Ссылка на представление каталога. При активном представлении ссылкой можно поделиться с читателями — они откроют каталог на портале с уже примененным представлением.
Поиск утверждающих в запросе на слияние. В окне создания запроса в поле Утверждающие появился поиск по имени — можно быстро выбрать нескольких пользователей из списка, не вводя почту вручную.
Выбор шаблона при экспорте в PDF. В окне экспорта появился флажок Кастомный шаблон — можно включить его и выбрать шаблон для оформления документа.
Обновили оформление заметок. Раньше типы заметок Информация и Совет оба были голубыми и плохо различались. Теперь Совет стал зеленым — тип заметки понятен с первого взгляда.
Навигация по статье с клавиатуры. Раньше после открытия статьи нужно было кликнуть по ней, чтобы прокрутка стрелками клавиатуры начала работать. Теперь она доступна сразу.
Обновили окна подтверждения. Улучшили интерфейс окна закрытия комментария и окна отката изменений при публикации.
API тесты не упали: они проверяли статус и структуру нового формата — всё корректно.
Я была уверена что если API возвращает 200 и схема верна — клиент получает данные.
Но в клиентском коде была строка:
cachedRows = Array.isArray(rows) ? rows : []
Для объекта Array.isArray возвращает false. Список записей стал пустым.
Формально всё работало корректно. Просто данных больше не было.Никаких ошибок в консоли. Никакого 500. Просто пустая страница.
CI остался зелёным — потому что API тесты проверяли API, а не то, как клиент использует ответ.
Дальше сработал каскад: fixture teardown тоже вызывал этот эндпоинт, получал объект вместо массива, не чистил данные — и следующие тесты падали с совершенно другой ошибкой, в совершенно другом файле.
Три теста упали из-за одного изменения shape ответа.
Ни один из них не указал на настоящую причину.
Почему CI это не ловит
CI отвечает на вопрос: «выполнились ли тесты без ошибок?»
Но не отвечает на: «имеют ли тесты смысл относительно текущей системы?»
CI реагирует только на падения. Он не знает про бизнес-инварианты, не отслеживает правильность выполнения и не видит contract drift.
Что с этим делают в зрелых системах
Начинают появляться дополнительные слои:
контрактные тесты (contract testing) — фиксируют ожидания потребителя API
явно наблюдаемость тестов — метрики не как %, а как сигналы поведения
контроль изменений API через diff-инструменты
Ни один из них не заменяет хорошие тесты. Но каждый закрывает слепое пятно, которое тесты не видят.
Финальный вывод
Тесты не доказывают, что система работает.
Они только доказывают, что система не сломалась определённым способом.
Признаки сбоя
CI зелёный
UI показывает пустой список
API возвращает 200
fixture teardown не чистил данные, занимал слот
Скрытое предположение
«Я решила что статус 200 означает, что потребитель по‑прежнему правильно читает ответ»
Как это выглядит в реальной системе
Contract drift — один из тех классов ошибок, которые можно воспроизвести намеренно. В проекте есть buggy branch именно с этим кейсом: API возвращает изменённый shape ответа, все API тесты зелёные, но клиентский код получает пустой список — без ошибок, без 500, просто тишина.
В self-hosted Git-сервисе Gogs обнаружили непропатченную уязвимость нулевого дня. Суть в argument injection: если включена опция Rebase before merging, атакующий может внедрить флаг --exec в команду git rebase через вредоносное имя ветки в пулл-реквесте.
Это даёт полный RCE. Злоумышленник получает доступ ко всем репозиториям, хешам паролей, API-токенам и SSH-ключам. Ситуация осложняется тем, что в Gogs по умолчанию открыта регистрация.
Под ударом версии 0.14.2 и 0.15.0+dev. Мейнтейнеры подтвердили баг ещё в марте, но патча до сих пор нет. Временные меры: закрыть публичную регистрацию, отключить rebase-merging или закрыть доступ к серверу "Из внешней сети".
Git reset: как управлять историей и не уничтожить свою работу
git reset — одна из тех команд, которые удобно держать под рукой, но страшно запускать без понимания последствий. Она помогает очистить локальную историю, убрать лишние коммиты, отменить git add или полностью откатиться к нужному состоянию. Но в режиме --hard может стереть незакоммиченные изменения так, будто ничего и не было.
В новой статье разобрали, что делает git reset, чем отличаются режимы --soft, --mixed и --hard, когда команду можно использовать безопасно, а когда лучше выбрать git revert или git restore. Отдельно показали типичные сценарии: объединение нескольких коммитов, вывод файлов из индекса, полный откат и восстановление после неудачного reset --hard через reflog.
GitOps без романтики: эксплуатация, советы, решения
Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.
В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.
Что на повестке
Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.
Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.
Почему зелёный CI не гарантирует, что система работает
Кейс из QA automation: как миграция на TypeScript привела к скрытому удвоению тестов без единого падения в CI
CI зелёный.
Тесты проходят.
Pull request’ы мерджатся.
Но система уже сломана.
И самое опасное — это не видно ни в логах, ни в отчётах CI.
В большинстве команд CI воспринимается как индикатор здоровья системы:
зелёный CI → всё работает
красный CI → есть проблема
Это удобная модель. Но она не всегда верна.
Контекст кейса
После миграции проекта с JavaScript на TypeScript мы заметили странное поведение:
CI стал выполняться почти в 2 раза дольше
тесты не падали
ошибок не было
метрики оставались “нормальными”
На первый взгляд — ничего критичного.
Что происходило на самом деле
Playwright начал подхватывать одновременно два набора тестов:
.spec.js
.spec.ts
В результате один и тот же тестовый набор запускался дважды.
Самое неприятное — CI не просто не показывал проблему. Он создавал иллюзию, что всё становится лучше: время выполнения росло постепенно, и это воспринималось как “нормальная деградация после миграции”.
Почему это было незаметно
Проблема усугублялась полным отсутствием сигналов:
CI оставался зелёным
тесты не фейлились
никаких warning’ов
никаких алертов
Единственный симптом — увеличение времени выполнения. Которое списали на “ну TypeScript, наверное тяжелее”.
Как проблема была обнаружена
Случайно. Ближе к завершению миграции, при удалении .js файлов, количество тестов внезапно сократилось примерно в два раза:
было ~240
стало ~120
До этого момента CI фактически выполнял двойную работу — без каких-либо признаков аномалии.
Root cause
Root cause оказался банальным — и именно поэтому его так долго не замечали.
В playwright.config.ts отсутствовал явный testMatch. Playwright по умолчанию подхватывает все файлы, соответствующие glob-паттерну — и .js, и .ts одновременно.
Фикс — одна строка:
testMatch: [‘**/*.spec.ts’]
Но чтобы до неё дойти, нужно было сначала понять, что вообще происходит.
Архитектурный вывод
Большинство проблем в тестовых системах не проявляются как падения.
Они проявляются как:
дублирование выполнения
скрытая деградация производительности
изменения в поведении runner’а без изменений в тестах
И у них нет алертов — потому что мы их не проектируем.
Например, в нашем случае проблему можно было бы поймать простым счётчиком discovered tests в CI.
Финальный вывод
CI — это не инструмент контроля качества системы. Это инструмент контроля того, что тесты не упали.
И если вы используете его как индикатор качества — вы просто получаете ложную уверенность быстрее.
CI отражает только одно: тесты выполнились без явных ошибок.
CI не отражает: тесты запустились правильно, в правильном количестве, с правильными предположениями об окружении.
Если система может быть “зелёной” и при этом работать некорректно — значит у вас есть статус выполнения, но нет наблюдаемости.
Как это выглядит в реальной системе
Именно этот кейс лёг в основу проекта, который я собирала как QA portfolio. В pipeline добавлен счётчик discovered tests: если количество отклоняется от ожидаемого, CI падает явно, а не молчит. Рядом — buggy branch с намеренно сломанной конфигурацией, чтобы можно было воспроизвести и починить самостоятельно.
Если собираешь QA портфолио или готовишься к техническому собеседованию — в Telegram-канале Тесты как система (https://t.me/qa_as_a_system) разбираю такие кейсы с кодом и объяснением: что показывать, как объяснять решения, какие находки работают на собеседовании.
РБПО по ГОСТ Р 56939—2024: вебинар №14 из 30 – Управление доступом и контроль целостности кода при разработке программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Примечание. Во время демонстрации работы GitFlic с PVS-Studio часть срабатываний не попала в SARIF-отчёт, потому что при запуске утилиты plog-converter не был указан флаг -a. Без него утилита включает в отчёт только срабатывания диагностических правил общего назначения уровней 1 и 2. Чтобы сохранить все срабатывания из исходного отчёта, нужно передать флагу -a значение ALL. Подробнее о флагах утилиты plog-converter можно прочитать в нашей документации.
Цели 14-го процесса по ГОСТ Р 56939—2024:
Обеспечение управления доступом к исходному коду и его целостности.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Я писал про кейс перевода всех сайтов на OpenClaw. Теперь переводим разработку больших продуктов.
Было так: Cursor пишет код как ассистент разработчика. Говоришь ему «построй план», корректируешь, и с нуля быстро можешь написать довольно масштабную систему.
После этого начинается просто корректировка, новые фичи и фиксы багов. И как правило, в большой системе, обросшей фичами, внедрение нового занимает время, особенно если команда не Full Stack (отдельно Front и отдельно Back разработка).
Но я попробовал и вынес дальнейшую разработку двух больших систем в OpenClaw.
По сути, на VPS с OpenClaw (полный sudo доступ) подтягиваем нужные репозитории. И в чате ему говорим: в репо A добавь X, почини Y, найди баги. Вроде все то же самое, как и в Cursor, но нет, все мгновенно оказывается в Prod, и в цикле там уже включено UI тестирование, потому что есть playwright + browser.
Dev Pipeline теперь это не 3 отдельные среды (prod + test + dev), а Front+Back Dev + QA + DevOps со средним time-2-market в 3 недели, а просто три ветки prod/test/dev, все три постоянно подняты, и time-2-market падает до часов.
Этап дизайна в Figma тоже уходит. Зачем просить дизайнера, который все время занят, сделать новый дизайн, если можно просто сказать боту: «Накидай три версии дизайна новой фичи сразу с самой фичей прямо в dev‑ветке», и уже через 5 минут смотреть, выбирать и корректировать.
Написание больших систем с нуля все еще удобнее в Cursor, но дальнейшее развитие работает на OpenClaw на 4+.
Установка Git на Ubuntu: три способа и базовая настройка
Git есть почти везде, но версия из стандартного репозитория Ubuntu может сильно отставать от актуальной — и это уже повод разобраться, какой способ установки выбрать. В блоге разобрали все три варианта: через APT, через PPA и сборку из исходников — плюс базовую настройку и первые команды для старта.
Недавно наткнулся на занятный опенсорс‑проект — GitHub Store (github.com/OpenHub-Store/GitHub-Store). Это такая «оболочка» поверх GitHub, которая делает с репозиториями то же самое, что App Store / Google Play делают с приложениями.
В чём суть
По факту GitHub Store пытается ответить на давно назревший вопрос:
«Почему, чтобы поставить простую утилиту с GitHub, мне нужно идти читать README, искать бинарники, разбираться с релизами, а потом ещё помнить, как это всё обновлять?»
Авторы решили: хватит так жить. Давайте сделаем нормальный стор поверх GitHub, но без своей отдельной экосистемы:
есть лента с трендами и популярными репозиториями — можно просто полистать и найти что‑нибудь полезное, как в обычном магазине приложений;
установка в один клик (ну, почти) — не надо руками лазить по релизам и думать, какой файл скачать;
автоматические обновления уже установленных программ — не нужно помнить, что там выходило, кто из них обновился, а кто нет;
работает на Android, Windows, macOS и Linux — то есть это не очередной «только под одну платформу, остальным держаться».
С точки зрения пользователя это выглядит как нормальный стор: плитки, поиск, категории, тренды. Но под капотом — обычные GitHub‑репозитории. Никакого своего «реестра пакетов», зависимостей и т.п. Всё, что уже лежит на GitHub, становится чуть более человечно упакованным.
Зачем это вообще нужно
Если вы давно сидите на GitHub, то знаете эту боль:
находишь классный проект на Hacker News / Хабре / Реддите;
переходишь в репу;
в README: «build it yourself», 15 шагов, три тулчейна и «tested only on Arch btw»;
если повезло — есть бинарник где‑то глубоко в релизах, но без автообновлений.
GitHub Store как раз пытается это сгладить: вместо «репозиторий с набором файлов» — понятное приложение, которое можно установить и потом обновлять как нормальный софт.
Причём это не замена package manager’ам (apt, brew, winget и прочие), а именно интерфейс к тем проектам, которые туда никогда не доедут: личные тулзы, мелкие утилиты, нишевые программы, эксперименты.
Автор проекта прямо пишет, что идея — собрать в одном месте тысячи программ, которых вы не увидите ни в одном официальном сторе, но которые живут на GitHub, звёзды собирают, а до пользователя так и не доезжают.
Чем это похоже на App Store, а чем — нет
Похоже:
есть витрина: тренды, популярное, поиск;
есть установка в одно действие;
есть обновления, о которых думать не нужно.
Не похоже:
нет централизованной модерации в духе Apple/Google — это всё равно GitHub, со всеми вытекающими;
нет единого UX по установке/запуску (проекты разные, и у каждого свои особенности);
безопасность пока, очевидно, на уровне «как в GitHub»: вы сами решаете, кому верить.
То есть это не «новый стор, который победит все остальные», а надстройка над тем, чем GitHub по факту давно является — огромным складом софта, где интерфейс для обычного пользователя исторически был «так себе».
Кому это вообще может зайти
Тем, кто любит ковыряться в GitHub и искать новые инструменты, но устал превращать каждый проект в квест.
Тем, кто живёт на Linux / Windows / macOS, использует кучу мелких утилит и хочет держать их в одном месте с автообновлениями.
Тем, кто сам пилит опенсорс: это ещё один канал донести свой проект до людей, которые не любят GitHub, но любят «поставить и пользоваться».
Что в итоге
Идея «сделать стор поверх GitHub» витала довольно давно, но тут её хоть кто‑то нормально попробовал свернуть в рабочий вид, да ещё и кроссплатформенно.
Пока это выглядит как удобная человеческая морда к GitHub, а не очередной велосипед ради велосипеда. Если у вас жизнь связана с опенсорсом (или вы просто любите новые игрушки), проект точно стоит хотя бы посмотреть.
Ну и по классике: это опенсорс, так что можете не только поставить, но и прийти с PR’ами, если чего‑то не хватает или кажется сделанным криво.
Корректные ссылки из приложения. Раньше ссылки на статью или каталог копировались как https://app.gram.ax/repo-name.... Теперь приложение подставляет домен вашей компании (где развернут веб-редактор), поэтому ссылки ведут в приложение в вашем контуре.
Фильтр по файламв поиске. Добавили режимы «Без вложений», «С вложениями» и «Только во вложениях», чтобы искать не только по тексту статей, но и по содержимому PDF и DOCX-файлов.
Другие улучшения:
Автоматическое решение конфликтов в комментариях. Если несколько пользователей одновременно отвечают или редактируют один и тот же комментарий, изменения корректно объединяются и не ломают комментарии. В связи с этим в «Проверить на ошибки» появился пункт «Комментарии» — он показывает статьи с комментариями, которые не привязаны ни к одному блоку.
Улучшения поиска:
Поиск стал быстрее. Ускорили примерно в 2 раза и оптимизировали индексацию.
Обязательные слова в запросе. Добавили оператор +: поставьте его перед словом или фразой, и они точно будут учитываться в результатах.
Окно поиска по статье сохраняет состояние. При переходе между статьями окно закрывается, но при повторном открытии сохраняется введенный текст (пока приложение открыто).
ИИ-поиск стал точнее. Мы улучшили RAG, поэтому ответы в поиске стали более релевантными и полезными. Подробнее — в статье на Хабре.
Инлайн-тулбар в комментариях, сниппетах и шаблонах. Теперь над полем ввода комментария доступно базовое форматирование: жирный, курсив, код и вставка ссылок. А в редакторе сниппетов и шаблонах появился полный набор инструментов, включая редактирование таблиц.
Превью Excel-файлов. Теперь Excel-файлы можно открыть в режиме предпросмотра: при клике отображается превью в модальном окне.
Быстрая публикация. Список изменений загружается в 3 раза быстрее.
Автоматическое обновление ссылок при редактировании. Если вы меняете текст ссылки и он совпадает с ее адресом, адрес тоже обновится. Если текст и адрес разные — ссылка не меняется.
Сохранение позиции прокрутки между статьями. Если вы перешли в другую статью и вернулись назад, статья откроется там, где вы остановились, а не в начале.
Версия приложения в деталях ошибки. Это помогает быстрее понять, на какой версии возникла проблема и быстрее ее воспроизвести.
Исправление уязвимостей. Теперь перед выпуском новых версий мы автоматически проверяем используемые библиотеки на известные уязвимости.
Продолжаю писать серию коротких постов про историю айти. В последнее время нам очень интересна тема нашего наследия и почитывая разные источники, я пишу об этом коротко и простым языком.
В 2013 году биткойн впервые пробивает тысячу долларов, а Сноуден сливает PRISM. У людей начинает появляться ощущение и понимание, что интернет-сервисы, которыми они пользуются каждый день, могут быть частью конвейера доступа к данным. На этом фоне у всего IT живёт боль в виде окружения. Чтобы запустить приложение в среде, нужно было вручную настраивать сотни зависимостей. Малейшее несовпадение версии и всё падает. Виртуальные машины помогали, но они были слишком тяжелыми.
В этом же году в компании dotCloud во главе с его основателем Соломоном Хайксом делали сервис, в котором ты загружаешь код и он запускается на сервере без ручной настройки. Для этого им нужен был внутренний инструмент, который упаковывает приложение вместе с окружением.В какой-то момент они поняли, что их облачный бизнес идет так себе, а вот штука для управления контейнерами получился бриллиант.
Так Хайкс впервые представил Docker на PyCon. В своем докладе он упоминал, что айти индустрия страдала от проблемы под названием “матрица ада”. То есть чтобы запустить каждое приложение в каждой среде, нужно было вручную настраивать сотни зависимостей. Малейшее несовпадение версии библиотеки и всё падает. Виртуальные машины помогали, но они были слишком тяжелыми. Это оказалось сильнее, чем первоначальная бизнес-идея dotCloud.
В Linux уже были на тот момент механизмы изоляции, но собрать это можно было, однако повторить - сложно. Первопроходцы Solaris Zones в 2004 году были не хуже. Но Docker единственный упаковал контейнеры так, что ими стало удобно пользоваться: рецепт сборки в Dockerfile, слои для переиспользования и публичный реестр по умолчанию. Он победил за счет удобного UX.
Докер так быстро стал стандартом, что другие игроки испугались монополии на формат. И чтобы не расколоть индустрию, закрепили нейтральный стандарт - OCI (Open Container Initiative).
Подписывайтесь на наш Telegram-канал. Там мы публикуем полезные подборки от инженеров и делимся инсайтами.
Где хранить код и как настроить CI/CD, если GitLab CE уже не хватает
Иногда возможностей бесплатного GitLab уже недостаточно, при этом платная версия по понятным причинам недоступна. Собственные форки требуют постоянной возни с обновлениями и закрытием CVE, а написание своей системы — больших затрат ресурсов.
У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:
Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.
Обсудим, как сократить нагрузку на команды за счёт managed-подхода.
Проведём живое демо от коммита в консоли до артефакта в registry.
Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.
OAuth на практике: что оказалось удобным, а что отпугнуло пользователей
Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).
Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.
С чего начали
Для обычных пользователей: • Email / пароль • Google • GitHub
Для разработчиков — жёстче: • Обязательная привязка Google • Обязательная привязка GitHub
Логика казалась разумной: «Разработчик = есть GitHub» «Двойная верификация = меньше спама»
На практике это не сработало.
Первые тревожные сигналы
Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.
Сначала списывали на: • новый продукт • низкое доверие • отсутствие аудитории
Но после общения с разработчиками (в том числе через Habr) картина прояснилась.
Что отпугивало разработчиков
Новый сервис → нежелание делиться данными
Даже если это «просто email», психологический барьер остаётся.
Когда с первого шага нужно: • линковать внешние аккаунты • проходить несколько этапов подтверждения • подключать сторонние сервисы
это воспринимается как лишний фрикцион.
Особенно для соло-разработчиков и небольших команд.
Git ≠ GitHub
Ключевой инсайт.
Мы обнаружили, что: • не все хотят логиниться через GitHub • часть использует GitLab или Bitbucket • некоторые принципиально не хотят связывать GitHub с новым сервисом
Обязательная привязка GitHub стала серьёзным барьером.
А мнение стандартных пользователей разделилось:
Часть говорила:
«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».
Логика простая: • если есть Google / Facebook / Discord — значит не ноунейм • интеграции с крупными сервисами повышают доверие
Это не про безопасность — это про ощущение легитимности.
Другие говорили ровно противоположное:
«Слишком много кнопок — ощущение перегруженности».
И это тоже справедливый аргумент.
Что мы изменили
Упростили форму для пользователей
Оставили: • Google • Facebook • Discord
Достаточно выбора для доверия, без визуального шума.
Git-провайдеры вынесли в отдельную группу
Под отдельной кнопкой: • GitHub • GitLab • Bitbucket
Для разработчиков это стало понятнее и логичнее.
Убрали обязательный GitHub
Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.
Без принудительного GitHub.
Первые цифры (осторожно)
Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.
Тем не менее: • Зарегистрированные пользователи: +13% (было 0–6% в неделю) • Зарегистрированные разработчики: +16% (было 0–3%)
Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.
Выводы (пока не финальные) • OAuth — это не только безопасность, но и психология доверия • Жёсткие требования на старте почти всегда бьют по росту • Git ≠ GitHub — и это важно • Много провайдеров могут как повышать доверие, так и перегружать UI
Для молодой платформы даже такие ранние сигналы уже показательны.
Интересно услышать опыт коллег: добавляли ли вы OAuth-провайдеров после запуска? были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?
Модуль метрик в Gramax Enterprise Server. Появились отчеты с метриками просмотров, визитов и посетителей на портале документации. А также статистика поисковых запросов. Отчеты можно фильтровать по дате и пользователям, выбирать период (день, неделя, месяц).
Поддержка Git LFS . Добавили возможность работать большими бинарными файлами (изображения, архивы, PDF и др.) через спецификацию Git LFS.
Превью файлов. На портале для читателей доступно превью файлов PDF и DOCX по клику. Читателю не обязательно скачивать файл на компьютер — он может просмотреть его прямо в браузере.
Свойства на портале. Раньше свойства отображались только в приложении, теперь можно настроить отображение и на портале для читателей. Читатель увидит их на статье, а также сможет отфильтровать результаты в поисковой строке.
Ссылки между каталогами. Добавили возможность добавлять относительные ссылки на статьи в других каталогах.
Удаление запроса на слияние. Теперь можно закрыть запрос на слияние в интерфейсе Gramax — он будет удален для всех пользователей после публикации изменений.
История комментариев. В просмотре изменений теперь проще отслеживать обновления комментариев: слева появляется иконка комментария, которая показывает, что в тексте изменились или появились комментарии. Там же можно кликнуть по комментарию, открыть его и отредактировать.
Несмотря на кажущуюся сложность, на повседневной основе для работы с Git не требуется большой набор знаний. Checkout, fetch, branch, commit, amend, rebase, revert, reset, pull и, наконец, log. Это — большинство нужных команд. Изредка пользуюсь еще config, бывает нужно.
В общем-то, Git достаточно прост с точки зрения пользователя. Проблема: понимание простоты Git приходит именно с опытом работы с тем самым Git. А по началу хочется иметь под рукой какую-нибудь книжку.
Скотт Чакон и Бен Страуб составили замечательное справочное пособие для тех, кто хочет окунуться с головой в детали работы с Git. Издание есть в виде сайта, PDF, EPUB и MOBI. Распространяется Pro Git бесплатно.
Книга рассчитана на начинающих пользователей или тех, кто имеет конкретные вопросы по механикам Git и им нужен подручный справочник. Что немаловажно, сайт и книга переведены на русский язык.
Pro Git не раз мне пригодился в прошлом, рекомендую.
Мы сделали быстрый офлайн-поиск по всей документации. Открывается через Cmd/Ctrl+/, навигация стрелками, Enter – переход с подсветкой найденного фрагмента. Подхватывает опечатки и кривую раскладку.
Помогает быстро переключаться между статьями и проектами. Работает одинаково в приложении и в докпортале.
--- Gramax – это база знаний с хранением контента в Git в Markdown-файлах и с визуальным редактором. Подробнее о проекте: https://gram.ax/ru
Запуск GitLab Runner в Yandex Cloud Serverless Containers
Я Павел Елисеев, старший разработчик в команде Serverless в Yandex Cloud. Мы реализовали сценарий использования сервиса — Serverless GitLab Runner. В посте покажу архитектуру и поделюсь кодом решения.
GitLab Runner — агент, выполняющий задачи (jobs) из CI/CD‑пайплайнов GitLab. Он получает инструкции от GitLab, запускает сборку, тесты или деплой в нужной среде и передаёт результат обратно.
Раннер работает в разных окружениях:
на общих серверах GitLab (shared runners);
на выделенных VM;
в K8s‑кластере.
В первом варианте репозитории должны размещаться на gitlab.com. В случае Managed GitLab или self‑hosted GitLab развёртывание выполняется самостоятельно.
Для shared‑раннеров free‑tier ограничен 400 мин./мес. Учёт идёт по формуле (duration × price-factor), так что число доступных минут зависит от используемого типа раннера. А за пределами лимита нужна привязка не российской банковской карты.
Serverless‑сценарии пытались реализовать на Cloud Functions, что требовало отдельной VM и сложной конфигурации. А мы хотели объединить плюсы serverless‑модели с CI‑задачами:
оплата за время
масштабирование за секунды
изоляция выполнения
отсутствие инфраструктурной рутины
Архитектура
GitLab Runner работает по модели pull: запускает процесс, устанавливающий long‑polling‑соединение с GitLab API, и ожидает появления задач.
Пришла задача — раннер выбирает executor:
shell — job выполняется в текущем окружении
docker — под job создаётся отдельный контейнер со всеми зависимостями
Эта модель плохо подходит для serverless‑окружения, где нельзя держать постоянно активный процесс.
Для перехода на push‑модель используем GitLab Webhooks — HTTP‑уведомления о событиях. С появлением задач GitLab отправляет вебхук в Serverless Container, который:
запускает раннер;
получает информацию о задаче;
выполняет её и возвращает результат в GitLab.
Так, выполнение задачи инициируется событием, а не постоянным опросом API.
Для упрощённого развёртывания есть лёгкий образ раннера с поддержкой docker-executor, размещённый в Container Registry. Раннер автоматически загружает и запускает контейнер, указанный в конфигурации job. Секреты для аутентификации в GitLab API хранятся в Lockbox.
GitLab требует от обработчика вебхуков быстрого ответа без ошибки. А выполнение задачи может занимать часы. Поэтому вебхуки обрабатываются асинхронно:
GitLab отправляет вебхук.
Платформа проверяет авторизацию и сразу отвечает 202 Accepted.
Обработка выполняется асинхронно в фоне.
Платформа решает, запускать ли новый экземпляр контейнера. Когда job завершается, контейнер остаётся активным какое‑то время, чтобы обработать вызовы без cold‑start.
GitLab не отправляет событие «создание job», поэтому раннер сперва проверяет, есть ли задачи со статусом pending.
Для docker‑executor требуется dockerd. Инициализация демона и подготовка окружения выполняются 1 раз при старте контейнера. Если job найдётся, запускается эфемерный раннер, исполняющий ровно 1 задачу.
Раннер загружает docker‑образ, выполняет команды, передаёт результат обратно через GitLab API.
Docker внутри Serverless Containers. Это не Docker‑in‑Docker: внутри serverless‑контейнера jobs исполняются без отдельного демона Docker, но с аналогичной логикой. Примеры есть в исходном коде.
Важные особенности serverless‑подхода
Эфемерность: кеш между вызовами отсутствует. Для хранения артефактов используйте Object Storage или свои базовые образы.
Загрузка образов: выполняется при каждом запуске. Рекомендуем использовать оптимизированные образы и близкий реестр (Cloud Registry), а при критичных требованиях к скорости старта — перейти на shell‑executor, собрав образ с установленным раннером и нужными зависимостями.
Ограничение времени: не более 1 часа. Для длинных задач разделите пайплайн на этапы с промежуточным сохранением результатов.
Ограничение по диску: до 10 ГБ.
Сценарий Serverless GitLab Runner позволяет выполнять CI/CD‑задачи GitLab, оплачивая лишь время выполнения job. Serverless Containers дают возможности для CI‑нагрузок: асинхронные вызовы, часовой таймаут, эфемерный диск и поддержку docker‑executor внутри контейнера.
Друзья, классная новость! Мы с коллегами из GitVerse закончили разработку интеграции!
Теперь в Gramax можно подключить GitVerse в качестве хранилища. Работает в лучшем виде: клонирование, синхронизация, коммит, пуш — все как и должно быть ✨
Это была масштабная и интересная работа: мы вместе анализировали API, чтобы получилось максимально удобно. Потому будем очень рады увидеть ваши плюсики!
Gramax — Open Source-платформа для работы с документацией в подходе Docs as Code. GitVerse — AI-first платформа для работы с кодом.
Всем привет! Меня зовут Катя, я развиваю Gramax, open source-платформу для управления технической документацией. За последние 3 месяца мы сделали много новых полезных функций, коротко расскажу о самых важных.
Интеграция с GitVerse. Теперь в качестве хранилища можно использовать GitVerse. Как подключить GitVerse к Gramax читайте в статье.
Поддержка Gitea. Также добавили поддержку Gitea: доступно подключение в качестве хранилища и использование всех возможностей Gramax.
Экспорт в PDF и DOCX в собственных стилях. Можно настроить вид документа: добавить титульную страницу, оглавление, номера заголовков, собственные шрифты и отступы и так далее. Для DOCX — с помощью стилей, для PDF — с помощью CSS. Применяется при экспорте из приложения, портала документации и в CI/CD.
Предпросмотр загруженных файлов. Теперь при клике на загруженный файл в статье открывается окно предпросмотра. Отображаются файлы форматов DOCX и PDF. Остальные форматы — скачиваются.
Улучшения поиска.
Новое ранжирование. Больший вес дается результатам, в которых искомое слово содержится в названии статьи или в одном из заголовков.
Переход к поисковой фразе. После клика на результат поиска статья откроется на том фрагменте, в котором есть поисковый запрос.
Настройка поисковой выдачи. Для статей можно указать поисковые запросы: если в поиске ввести один из них, статья отобразится выше остальных.
Поиск по свойствам в приложении. Если на статьях установлены свойства — в поисковой строке можно отфильтровать по ним.
Улучшение внешнего вида. Теперь в результатах есть указание на каталог, в котором содержится запрос. А также отображается иерархия заголовков в статье.
Улучшения Gramax Enterprise Server.
Разворачивание с помощью Helm. Добавили новый способ разворачивания Gramax Enterprise Server в Kubernetes.
Тестирование знаний. Реализовали модуль проверки знаний читателей: в статью можно добавить тест с разными типами вопросов. После прохождения статистика пользователей отобразится в панели администрирования.
Поиск по вложенным файлам. Теперь поиск учитывает не только контент статьи, но и контент из PDF и DOCX-файлов.
«СберТех», Cloud.ru и Хабр заколлабились и запустили грантовую программу «Код без границ». Это отличная мотивация для разработчиков и ресурсы для проектов. Можно доработать свой проект с поддержкой сообщества, найти единомышленников и показать свои возможности.
Участвовать просто:
разместить свой проект на GitVerse (СберТех) или импортировать его с другой площадки.
делится кодом и вдохновляться чужими разработками.
Номинации следующие: ИИ‑инновации, «Наука и образование», «Проекты для всех», «Разработка для разработчиков».
Заявки на грантовую программу «Код без границ» принимаются с 3 сентября по 31 октября. Отбор проведут в ноябре, а результаты огласят в декабре.
7 полезных плагинов для фронтенд-разработки в VS Code!
Сегодня хочу поделиться с вами списком полезных плагинов для Visual Studio Code, которые упростят вашу работу и повысят производительность.
ESLint — находит ошибки и баги в JS/TS коде. Незаменим для профессиональной разработки. 🛠
Prettier — автоматически форматирует код по стандартам. Никаких споров о стилях! 📊
Code Spell Checker — ищет опечатки в коде и комментариях. Больше никаких ошибок из-за опечаток! Для русского языка нужно установить дополнительный плагин Russian - Code Spell Checker 🔍
DotENV — подсветка синтаксиса для .env файлов. Переменные окружения больше не путаются! 📦
GitLens — показывает, кто и когда менял каждую строку кода. Незаменим для работы в команде.
NPM outdated — показывает устаревшие зависимости в проекте. Не пропустите важные обновления! ⏳
SonarQube — анализирует качество кода, ищет уязвимости. 🔐
Установите эти плагины и сделайте свою работу ещё эффективнее! 💻
Ранее в Amvera Cloud, были возможны откаты только путём новой сборки из нужного коммита в Git-репозитории. Помимо этого, использовалась медленная технология сборки.
Мы ускорили сборки до 10 раз и сделали возможность быстрого отката к предыдущим версиям!
Стало легче откатывать приложение, в случае ошибок.
Подключить быстрые сборки можно в разделе проекта «Контроль версий».
Интерфейс управления версиями сборок
Новые сборки
Быстрее старых до 10 раз.
Позволяют откатываться к предыдущим версиям одной кнопкой. Это полезно, если вы случайно накатили баг и надо вернуться к прошлой версии.
Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе), бесплатными https-доменами, мониторингом работы приложений, встроенным проксированием до ведущих LLM и собственным инференсом LLaMA.
Вам не нужно думать о настройке инфраструктуры. Git push amvera master и ваш проект запущен. Зарегистрируйтесь и получите 111 рублей на тест.
Убедитесь, что имя ключа соответствует указанному в параметре sshCommand внутри соответствующего .gitconfig-*
✅ Результат
Теперь можно: - Открыть в редакторе любой проект из этих папок. - Работать, делать коммиты и пушить - без ручного переключения пользователя или ключа. - Открыть сразу несколько проектов из разных папок - всё будет работать корректно.
Можно добавить и больше папок с пользователями - принцип остаётся тем же.
Привет, Хабр! 👋 Хочу поделиться небольшой, но полезной фичей, которая упростила мне жизнь при оформлении коммитов.
В своей работе я придерживаюсь структурированного подхода к именованию веток и сообщений коммитов. Подробнее об этом можно почитать здесь: 📎 https://habr.com/ru/articles/820547/
Я использую предложенные в статье правила, немного адаптировав их под себя. Например, добавляю номер задачи в текст коммита — это сильно упрощает анализ изменений при подготовке релиза.
Почему это удобно?
Указание номера задачи позволяет быстро понять, какие именно тикеты попадают в релиз. Особенно это помогает при ревью и при деплое.
Пример структуры ветки:
feat/dev-123_filter или fix/dev-432_filter
Сообщения коммитов я пишу в следующем формате:
dev-123 | настроил сортировку в фильтре
Чтобы не вставлять руками номер задачи каждый раз, я написал небольшой shell-скрипт, который делает это автоматически.
Скрипт prepare-commit-msg
#!/bin/sh
COMMIT_MSG_FILE=".git/COMMIT_EDITMSG"
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
if echo "$BRANCH_NAME" | grep -qE 'dev-[0-9]+'; then
TASK_ID=$(echo "$BRANCH_NAME" | grep -oE 'dev-[0-9]+')
if ! grep -q "$TASK_ID" "$COMMIT_MSG_FILE"; then
sed -i.bak "1s/^/$TASK_ID | /" "$COMMIT_MSG_FILE"
rm -f "$COMMIT_MSG_FILE.bak"
fi
fi
Скрипт нужно сохранить как .git/hooks/prepare-commit-msg и сделать исполняемым:
chmod +x .git/hooks/prepare-commit-msg
Как это работает?
COMMIT_MSG_FILE — путь до файла, в который Git записывает текст коммита.
BRANCH_NAME — название текущей ветки.
Сначала проверяется, есть ли в названии ветки номер задачи (dev-123).
Если он найден и ещё не указан в коммите — скрипт добавляет его в начало первой строки сообщения.
Таким образом, ваш коммит автоматически будет выглядеть так:
dev-123 | добавил пагинацию в список товаров
Вроде мелочь, а приятно — экономит время и упрощает навигацию по истории коммитов.
Если будет интересно — это и другие полезные скрипты, на моём GitHub
Обновляем платформу SourceCraft и открываем доступ к ней для всех разработчиков
Сегодня Yandex B2B Tech открыла публичный доступ к платформе для разработки SourceCraft и представила её новые возможности. В платформу интегрированы инструменты безопасности, которые обеспечат защищённую разработку программных продуктов. А в ИИ‑помощнике SourceCraft Code Assistant появился чат‑режим, что увеличит скорость и эффективность разработки.
Удобство командной работы повысится за счёт бранч‑ и ревью‑политик, встроенных в интерфейс, а также аутентификации через SSO. Также появляется возможность зеркалирования репозиториев с GitHub и публичный API.
Инструменты безопасности
На платформе стали доступны инструменты безопасной разработки: сканер секретов в коде и анализ зависимостей в кодовой базе.
По данным исследования аналитиков Forrester интеграция инструментов безопасности в разработку на 81% снижает трудозатраты на ИБ‑поддержку всего проекта.
Чат‑режим в SourceCraft Code Assistant
ИИ‑помощником SourceCraft Code Assistant пользуются десятки тысяч разработчиков. Теперь в нём доступен чат‑режим, интегрированный непосредственно в среду разработки. В диалоговом режиме на естественном языке можно задать вопрос ИИ‑ассистенту, сгенерировать код, юнит‑тесты, документацию. Это ускорит поиск необходимой информации и оценку предлагаемых решений. Функциональность доступна в плагинах для VSCode и IDE от JetBrains.
Зеркалирование и бесшовная миграция
Миграция проектов с GitHub становится бесшовной — кроме кода переносятся Issues, PRs, Labels, Milestones, Comments. Также можно выбрать ветки для зеркалирования — непрерывной синхронизации кода.
Также появился федеративный доступ к платформе для компаний — авторизация через SSO.
Публичный API
Благодаря появлению публичного API платформа становится расширяемой. Пользователь сможет взаимодействовать с SourceCraft и обеспечивать автоматизацию и интеграцию с другими приложениями. Первая версия публичного API доступна для управления задачами, список будет пополняться.
Правила работы с ИТ‑проектами
В интерфейсе платформы появились бранч‑ и ревью‑политики — правила работы с ветками и проверками кода, которые интегрируются в систему контроля версий и процессы CI/CD.
Опенсорс
Появился анонимный доступ к публичным репозиториям платформы.Пользователи SourceCraft смогут создавать независимые копии репозиториев (forks) опенсорс‑проектов. Это позволит вносить персональные изменения, не затрагивая напрямую исходную кодовую базу. При этом копия сохраняет связь с оригиналом для получения обновлений.
Удобство работы с кодом
Интерфейс платформы теперь позволяет просматривать структуру файлов для шести языков программирования: Python, C++, Java, Go, TypeScript и JavaScript. Функциональность навигации по коду стала умнее и аналогично теперь поддерживает 6 языков.
Автоматизация CI/CD‑процессов
Среди обновлений, связанных со сборкой и развертыванием кода, появились self‑hosted runners — теперь можно запускать задачи как на виртуальных машинах Yandex Cloud, так и в своём окружении. Также появились flavours — теги для пользовательских задач, за счёт которых можно выбирать, где запускать задачу. Помимо этого в интерфейсе платформы появилась возможность не только разрабатывать, но сразу публиковать мобильные приложения в App Store, Google Play, RuStore, Huawei AppGalery.
Packages
Появилась возможность создавать и использовать собственные программные пакеты популярных форматов: наборы кода, библиотек, модулей или компонентов. Разработчик сможет хранить их в персональном облаке, привязанном к организации SourceCraft, и использовать в своих проектах. Packages также интегрированы с CI/CD платформы.
Вход в SourceCraft реализован через Яндекс ID аккаунт. Зайти на обновлённую платформу можно на сайте SourceCraft.
В репозитории Tencent Cloud SDK for Go на GitHub содержится более 200 000 тегов Git. Это так много, что попытка взаимодействия с тегами в этом репозитории может фактически привести к сбоям в работе GitHub (504 Gateway Time-out. The server didn't respond in time).
Кардинальное упрощение привязки GitHub, GitLab, Bitbucket в Amvera Cloud
Привязка репозиториев GitHub, GitLab, BitBucketвызывала у наших пользователей затруднения, и мы обещали упростить процесс.
Теперь для привязки репозитория достаточно указать токен и выбрать ветку и репозиторий.
Способ позволяет организовать максимально простой деплой и обновление приложений через git push. Для обновления приложения достаточно сделать коммит в привязанный репозиторий, и оно соберется и бесшовно запустится автоматически.
Заполняем три поля и CI/CD готов
Подробная инструкция по подключению доступна по ссылке.
Amvera Cloud — это облако для простого деплоя приложений через git push (или интерфейс). Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS.
Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. Он позволяет автоматизировать создание виртуальных машин на основе текстовых файлов конфигурации. Схема его работы примерно такая:
В GitOps-репозитории находятся terraform-файлы с описанием параметров виртуальных машин и DNS.
На основе этих файлов формируются конфигурации для новых ВМ.
Все изменения вносятся через pull request, а их корректность проверяется автоматическими запусками тестов в CI.
После слияния изменений CI запускает процесс приведения нового желаемого состояния репозитория к действительному.
Этот подход отлично масштабируется, позволяет быстро создавать новые кластеры. Достаточно лишь скопировать все файлы в новые директории и поменять нужные переменные. В итоге с OpenTofu вы сможете описывать инфраструктуру в декларативном формате и автоматически применять изменения.
В своей статье Кирилл Яшин рассказывает, как с нуля реализовать такой подход к виртуальным машинам, используя провайдеры для работы с OpenStack и DNS.
Это задачка для DevOps-инженера: почему ArgoCD не расшифровывал секреты из Vault
Нашему DevOps-специалисту Антону нужно было развернуть helm-чарт для Airflow с использованием ArgoCD. Как известно, ArgoCD реализует концепцию GitOps и подразумевает хранение манифестов в репозитории. Но часть данных в values чувствительна, например пароль от базы данных PostgreSQL. Поэтому неплохо было бы вынести эти данные в хранилище секретов (в этом случае — HashiCorp Vault), чтобы скрыть информацию от лишних глаз.
Есть несколько способов подтянуть секреты из Vault в поды. Наиболее предпочтительный по ряду причин — vault-injector. В обычной ситуации Антон бы воспользовался им, но в случае с helm-чартом Airflow задача показалась непростой. Поэтому он решил воспользоваться менее предпочтительным, но точно рабочим (как думал Антон) вариантом с ArgoCD Vault Plugin.
Какая вылезла проблема
Когда секреты были добавлены в хранилище, а ArgoCD Application написан, Антон попытался развернуть его для теста. Вот примерный Application, с которым это делалось (весомая часть пропущена для компактности):
Ничего необычного, за исключением прокидывания values прямо из Application и того самого секрета. А еще — компонент webserver отказался запускаться, ссылаясь на невозможность подключиться к базе данных. Хотя данные были абсолютно точно правильными.
В чем итоге была проблем и как Антон с ней справился, читайте в статье →
Выстроенный code review позволяет: — найти баги и не пропустить их в прод. Конечно, в дополнение к статическому анализу с помощью настроенного pre-commit и тестам; — выявить проблемы в архитектуре; — сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных.
В долгосрочной перспективе постоянные code review: — налаживают обратную связь между участниками; — бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода; — помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде; — дают приток новых идей для улучшений в процессах, подходах и автоматизации; — увеличивают децентрализацию знаний и bus factor.
В статье даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.
Бывает, смотришь на код и сразу видно, что код плохой. Признаков может быть множество: — разные куски кода по-разному отформатированы; — импорты в файлах никак не структурированы; — используются вперемешку синтаксис старых и новых версий питона; — где-то видны зачатки использования типов, но не везде; — где-то docstring есть, где-то нет; Всё это характеризуется так: нет единого стиля в написании кода. Проблема становится особенно актуальной, когда над проектом трудится несколько разработчиков.
Частично эту проблему решает встроенный в среду разработки анализатор кода или запускаемые вручную анализаторы кода. Но анализатор в среде разработки может быть настроен по-разному у разных членов команды. Если в проекте принято использовать несколько анализаторов одновременно, то разработчик может забыть прогнать код через все анализаторы до коммита.
Для решения всех обозначенных проблем есть замечательная утилита — pre-commit. Один раз в конфиге прописываете, какие анализаторы кода нужно запускать, и далее при любом коммите они будут запускаться автоматически. С этого момента код будет опрятным и шелковистым. Вы просто не сможете сделать коммит, если у анализатора есть вопросики к коду.
Для тех, кто хочет распилить монорепу на подмодули или уже сделал это. Задача со звёздочкой.
Дано: в репозитории около 50 подмодулей, текущие ветки у них имеют разные названия. Джун Вася создал в каждом подмодуле новую ветку и внёс минорные правки. Чтобы провести ревью, миддл Серёжа получил Васины изменения, переключил ветки родительского репозитория и выполнил команду:
git submodule update --init --recursive
После ревью Вася пошёл исправлять замечания, а Серёжа вернулся к разработке своей фичи, вот только подмодули теперь в состоянии head detached.
Вопрос: как быстро подгорит у программистов из-за необходимости выставлять подмодули из состояния head detached в соответствующие feature-ветки, если процесс повторять?
По хешу команда найдёт указатель и на него переключится. Если есть несколько указателей для текущего коммита, будет выбрано имя ветки первое по алфавиту. Если на текущий коммит подмодуля никакая ветка не указывает, получим head detached. Рекурсивно (если у подмодулей есть подмодули) тоже работает.
