Сегодня Yandex B2B Tech в режиме технического превью открывает пользователям доступ к SourceCraft — платформе для разработки полного цикла, которая помогает создавать исходный код, управлять версиями, заниматься тестированием, сборкой, деплоить и сопровождать программные продукты. Её история началась в Yandex Infrastructure — эта команда развивает инструменты для создания и развёртывания приложений и сервисов внутри Яндекса и поддерживает инфраструктуру, на которой работают большинство разработчиков компании. Во многом поэтому значительная часть идей для новой платформы возникла благодаря догфудингу — практике использования собственного продукта командой его создателей.
Вместе с разработчиками платформы Ольгой Лукьяновой @ollka_lukianova и Сергеем Захарченко @neofelis узнаем, каково это — делать платформу для разработки, одновременно используя эту же самую платформу для написания кода, тестирования, проверки пул‑реквестов, сборки и деплоя.
Немного о догфудинге в Яндексе
Догфудинг — широко распространённая практика во многих командах Яндекса. Например, все сотрудники внутри компании используют систему для управления задачами и процессами Yandex Tracker, который улучшается благодаря обратной связи и внешних, и внутренних пользователей.
В случае с dev‑платформами всем разработчикам Яндекса также хорошо знаком внутренний монорепозиторий, который создавался с целью дать удобные инструменты разработки сотрудникам. Как уже рассказывали коллеги, одной из причин его появления была необходимость переиспользовать код внутри Яндекса, а также большой объём данных. Так что, с одной стороны, у команды был пример внутренних инструментов разработки, которыми можно вдохновляться. С другой стороны, было важно учитывать, что у монорепозитория одни задачи, а у SorceCraft — немного другие.
В частности, для монорепозитория используется своя система контроля версий, которая существует только внутри Яндекса. Из‑за заточенности на большие данные в такой клиент‑серверной системе данные хранятся на сервере, там же работают тяжелые алгоритмы. Это хороший компромисс, когда надо работать с большими монорепозиториями. А «в обычном мире» всё проще и стандартом индустрии остаётся git. Она встроена во все IDE, есть множество клиентов к ней. Поэтому в платформе разработки, которая нацелена на самых разных разработчиков, система контроля версий должна быть совместима с git.
В любой момент команда проекта готовилась переехать на собственную систему и продолжить разработку SourceCraft на самой SourceCraft.
Забавное наблюдение, как по внутренним ощущениям определить, что уже можно переезжать на тот продукт, который сам и разрабатываешь. Первая фаза процесса разработки в новом проекте — ты удивляешься, что всё работает. Если делаешь что‑то с нуля, то первое время процесс рождения приложения может вызывать восхищение. Но потом происходит фазовый переход: ты оказываешься в той стадии, когда удивляешься уже тому, что что‑то не работает. И начинаешь активно оформлять баг‑репорты и фича‑реквесты. Вот на этой фазе — уже можно переезжать.
Сергей Захарченко
CTO платформы SourceCraft
Какие сложности у догфудинга в случае инструментов разработки
Разработка SourceCraft стартовала в январе 2024 года, а в сентябре команда переехала сама на свой продукт. Разумеется, платформа ещё не была написана до конца. В связи с этим возникла пара трудностей.
Как не утратить объективность при тестировании и проверке качества. Практика догфудинга часто напоминает ситуацию «сапожника в сапогах», который шьёт сам для себя по собственным меркам. С одной стороны, разработчики хорошо представляют процесс разработки изнутри, их гипотезы не теоретические, а практические. Команда сразу на собственном опыте ощущает, если что‑то устроено неудобно, и стремится это исправить, чтобы дальнейшая работа стала проще. С другой стороны, этот опыт всё равно ограничен определёнными сценариями, и тогда важно, чтобы в команде было как можно больше людей с разнообразным бэкграундом и они могли стать репрезентативным прототипом будущей аудитории.
Я остаюсь фанатом догфудинга ещё с момента работы в JetBrains, но всегда стараюсь помнить не только про его плюсы, но и ограничения. Догфудинг плохо работает в сценариях, которые твоя команда не использует. Так или иначе, у всех разработчиков выстроены определённые процессы, которые складываются в определённый воркфлоу. А для остальных сценариев необходим QA, или другие команды, которые будут эти сценарии покрывать.
Ольга Лукьянова
руководитель команды поиска и навигации по коду
По этой причине в команду догфудинга попали как разработчики, которые имеют большой опыт работы с внутренним монорепозиторием, так и активные пользователи BitBucket, GitHub, GitLab, которые могут обратить внимание на совсем другие особенности интерфейса или процессов.
Ещё одна частично связанная проблема — при переезде на платформу, которая находится в стадии разработки, есть риск просадки скорости работы, и полностью свести его к нулю нельзя. Для решения обеих трудностей было важно выстроить быстрый луп обратной связи:
На начальном этапе у нас не было никаких дополнительных тестировщиков, мы работали внутри нашей команды разработки, где между нами уже налажены связи. С одной стороны, так мы сразу отловили и стабилизировали огромное количество проблем, которые делали больно нам самим. С другой — это замедлило нашу разработку, так как потребовалось время, чтобы устранить возникшие препятствия. Но поскольку эти проблемы болели у всей команды, они лечились с наивысшим приоритетом.
Заодно такой процесс позволил найти зоны, которые на начальном этапе не были покрыты end‑to‑end‑тестами — в дальнейшем для этих областей тоже можно написать дополнительные тесты. В хорошо выстроенном догфудинге это превращается в постоянный процесс.
Как выстроить работу с обратной связью. На старте сразу планировалось несколько основных источников фидбэка по работе в SourceCraft: сами разработчики платформы, некоторые сотрудники Яндекса из других команд, получившие ранний доступ, и первые пользователи технического превью. Поэтому для сбора обратной связи было важно собирать её через одно окно, а для себя разделить на два канала: баги и фича‑реквесты.
На первый взгляд, работа с багами выглядит прозрачнее. В Яндексе есть Zero bug policy — буквально «политика нулевой терпимости», где у каждой ошибки есть свой SLA и бюджет. Соответственно, для всех найденных ошибок важно сразу принять решение, не впадая в крайности наподобие тех, где нужно сразу править всё подряд или, наоборот, тикеты не заводятся вовремя. Чтобы этого избежать, команда проводит триаж: разбирает поступающие баги и расставляет приоритеты согласно критериям.
Блокеры — это самые серьёзные баги, которые не дают пользоваться основной функциональностью и при этом затрагивают частотные сценарии. Как правило, ситуация усугубляется тем, что при таких ошибках нет никакого обходного пути для реализации сценариев использования. Эти баги «стоят» разработчикам 1000 единиц. Нужно чинить как можно быстрее, привлекая все свободные руки.
Крит — баги поменьше, которые не блокируют работу, но доставляют неудобства и замедляют функционирование. Они тоже затрагивают частотные сценарии, но для их выполнения уже можно найти обходной путь. Если сопоставить их по «стоимости» с блокерами, то это уже 100 единиц. Важно взять в работу быстро, но не с такими жёсткими сроками, можно пофиксить в ближайшее разумное время (три дня на разбор и три дня на исправление).
Все остальные баги со средним и низким приоритетом отправляются в бэклог. Это уже нечастотные сценарии, где есть обходные пути. Такие ошибки «стоят» 1 единицу. Баги со средним приоритетом можно исправить в течение месяца.
Так ресурсы команды чётко распределяются между багами, продуктовой разработкой, техническими задачами и поддержанием техдолга. И одновременно возникает меньше ситуаций, когда пользователи просто не могут оценить платформу с точки зрения полезной функциональности, потому что мешает блокер.
Работа с фича‑реквестами уже чуть сложнее и тоньше, здесь используются другие алгоритмы приоритизации, которые также учитывают голоса пользователей, например, RICE. Здесь важно не упустить ситуации, когда отсутствует какая‑то фича и это очень мешает разработчику жить.
При заполнении фича‑реквеста у пользователя платформы есть возможность самостоятельно оценить критичность пожелания. Затем тикет отправляется ответственным, которые определяют приоритет на основе похожей процедуры триажа. Все фича‑реквесты делятся по компонентам: фронтенд, бэкенд, CI, кодонавигация и так далее. Лиды этих направлений выстраивают упорядоченный бэклог с учётом приоритетов.
Весь этот опыт помогал создавать платформу полного цикла, которой хочется пользоваться самим. А выстроенная система приоритетов также помогала определить порядок выкатки инструментов вовне — это внесло свой вклад в продуктовый роадмап.
Что разработчики уже могут протестировать в SourceCraft
Доступ к возможностям SourceCraft решили открывать поэтапно, и на стадии технического превью в первую очередь предложили такой набор функций:
git‑совместимая система хранения кода,
встроенный AI‑ассистент для работы с кодом SourceCraft Code Assistant,
кодонавигация и поиск по коду,
возможности совместной работы,
Continuous Integration (CI),
миграция из GitHub,
возможности интеграции в экосистему облака: система ролей и доступов, организации и сквозная аутентификация.
В будущем также добавятся импортёры из BitBucket, GitLab, зеркалирование и так далее. Пока, исходя из профиля работы пользователей, разработчики сосредоточились на проектах, которые находятся в опенсорсе и могут захотеть переехать на новый инструмент.
Немного подробнее о том, что появилось нового в платформе с момента первых анонсов.
Система контроля версий. В основе системы лежит GitCore — отказоустойчивый и масштабируемый git‑сервер. Это собственная имплеменатция git‑сервера, в основе которого лежит популярная библиотека go‑git. Если в обычном git слой хранения находится в локальной файловой системе, то в проекте создания платформы команда SourceCraft переработала библиотеку go‑git и перенесла слой хранения в облако: в Yandex Object Storage и Managed Service for PostgreSQL. Так удалось перейти к stateless‑архитектуре и получить горизонтальную масштабируемость, высокую доступность и отказоустойчивость.
Работа с кодом внутри SourceCraft. Мы уже рассказывали о том, как работали над навигацией по коду внутри платформы и добивались того, чтобы все типовые задачи было комфортно решать в одном интерфейсе. Но эта цель включает в себя не только удобную реализацию Go to Declaration, Get usages и Quick Info для каждого коммита и пул‑реквеста, но и несколько других возможностей:
Интерактивный просмотрщик кода. Команда разработки рассмотрела несколько вариантов движка для отрисовки кода, но все они не подходили по критериям скорости и расширяемости. Специально для SourceCraft был создан собственный быстрый движок. Разработчики использовали виртуализацию при отрисовке, но при этом удалось достичь быстродействия и не сломать нативный браузерный поиск (как это происходит зачастую при виртуализации).
Также просмотрщик независим от конкретного инструмента подсветки кода.
SourceCraft Code Assistant. С момента открытия бесплатного пробного доступа к AI‑помощнику от Яндекса его протестировали тысячи пользователей. Сейчас в Code Assistant поддерживается более 30 языков программирования, инструмент доступен для VSCode и JetBrains как отдельный плагин.
Работа с пул‑реквестами. Чтобы обеспечить качество принимаемых пул‑реквестов, в платформе есть несколько инструментов: удобный итеративный процесс для код‑ревью, CI для подключения автоматизированных проверок, подробная информация в том случае, когда вливаемая ветка содержит конфликты с целевой.
Для описания правил код‑ревью и настройки CI используется конфигурационный yaml‑файл. Команда разработки изучала prior art и дорабатывала синтаксис во время догфудинга, для того чтобы формат был простым для восприятия.
Какие ещё интересные идеи появились благодаря коллегам
Поскольку в репозитории команды лежит код модулей, разрабатываемых разными подкомандами, появилась одна из идей — разделить пулы ревьюверов, ответственных за проверку изменений.
Также на базе внутренней технологии Codesearch в платформе появились возможности поиска по коду. В основе технологии лежит квадграммный индекс и эффективные кодеки векторизированного сжатия чисел. Поиск по кодовой базе размером 20 ГБ отрабатывает за 44мс в 99-м перцентиле.
Справа видим зону с результатами поиска и предпросмотром кода Из опыта использования Yandex Tracker родилась функциональность Issues — инструмента, где можно заводить тикеты, репортить баги и отслеживать историю изменений в удобном интерфейсе. Команда внутреннего трекера создавала Issues как лёгкий и понятный инструмент для разработчиков. Из догфудинга появилась идея разметки тикетов через лейблы, а также создания приватных и публичных тикетов.
Сейчас вся обратная связь и сообщения об ошибках собираются при помощи Issues, тикеты публичны, за них можно голосовать и комментировать.
Благодаря Markdown editor, у пользователей появилась возможность выбирать, в каком редакторе работать: можно писать в Markdown, а можно использовать WYSIWYG. Это тоже результат внутренней работы над корпоративной wiki, которая дорабатывается по обратной связи сотрудников.
Большое количество замечаний и пожеланий к UI/UX также помогло учесть предпочтения разработчиков к организации рабочего места: от расположения кнопок до цветовой схемы, которая была скорректирована в результате догфудинга.
Что ещё в планах
В ближайшее время в платформе также появятся функции сканирования секретов и поиска уязвимостей в цепочках поставок. Также к моменту публичного превью добавится публичный API и будет реализовано больше сценариев интеграции с Yandex Cloud, когда развернуть проект в облачной инфраструктуре можно одной кнопкой. Одновременно с этим, в будущем SourceCraft будет работать по модели on‑premise — для использования на собственных серверах.
Помимо этого, в платформе будут дальше развиваться средства автоматизации. В том числе, появятся новые AI‑инструменты для облегчения рутинных задач.
Полезные ссылки, чтобы первыми узнать о новостях проекта
Заявка на тестирование платформы — для участия в техническом превью.
Комьюнити-чат — новости и общение с командой SourceCraft в Telegram.
Вакансии в команде SourceCraft — если хотите постигать догфудинг с нами.
![[Записки тимлида] Битрикс: от модулей к сервисам 3](/upload/resize_cache/iblock/cdc/105_70_0/cdcb79e507f883250ddeeb89d9b22d94.png "[Записки тимлида] Битрикс: от модулей к сервисам 3")
