Процесс разработки SubQuery

Летом после девятого класса я поехал на велосипеде 🚴 в Париж.

Ночевали мы с пацанами по дороге в кемпингах. В Париже кемпинг находился в Булонском лесу, известном определёнными "услугами аренды". Хотя шёл 2002 год, уже тогда на рынке было немало Гендерно Модифицированных Организмов, особенно в Булонском лесу. И чтобы как-то показать натуральность продукта, перед проходящими "арендаторами" приоткрывалась верхняя часть "упаковки". Способ грубый, но действенный: такой приличный молодой человек, как я, едва успевал отворачиваться.

Это я к чему? В интернете засилье нейрослопа, в том числе среди веб-приложений. И как понять, кому можно доверять, кто стоит за разработкой, — решительно неясно. Я решил воспользоваться известным с детства "булонским методом" и показать нашу внутрянку. Без прикрас, без вылизанных PR-текстов. Просто показать, как мы работаем на самом деле. Чтобы вы, глядя на наш продукт, понимали: за ним живые люди, а не промпт из гопоты.

Ну что, поехали? Только вы, пожалуйста, не отворачивайтесь 😅

Организация задач

В клиентских проектах мы в основном сталкиваемся с Jira. Бывали Bitrix и YouTrack — каждый со своим букетом. Но для себя выбрали YouGile. Почему? Потому что он бесплатный и не делает мозги.

У нас есть отдельные доски по разработке и маркетингу - это слишком уж разные направления. И отдельная доска для крупного проекта — BI. В ней живёт и работает Григорий со своими порядками и планами.

Задачи разработки ездят по четырем столбцам:

flowchart LR
    A[📋 Бэклог] --> B[🔧 В работе]
    B --> C[👀 На ревью]
    C --> D[🚀 В проде]
    D -.->|фидбек| A

Скорее всего позже добавим "Тестирование", но пока не требуется (столбец не требуется!!!).

Ещё мы помечаем задачи тегами.
Во-первых, теги модулей: dbt, озеро данных, ноутбуки, маркетинг.
Во-вторых, теги приоритетов: баг, дискомфорт, hold, обсудить. В целом приоритезация отражена в порядке задач в столбце, а теги обращают внимание на задачи. Например, обсудить означает, что по задаче есть вопросы.

Наполнение бэклога

Откуда берутся задачи? Из двух источников:

Запросы от пользователей. С энтерпрайз клиентами поддерживаем связь в выделенных чатах. Читаем ваши обращения на почте и в общедоступных каналах. И у нас есть лидерборд по пользователям, иногда сами дергаем кого-нибудь из топа по поводу фидбэка.
Собственные идеи. Их очень много, СЛИШКОМ много. Я без конца накидываю, а потом не знаю, за что взяться. Благо, коллеги приземляют.

Бэклог — это такая помойка ценных идей. Там может лежать задача «пофиксить баг с авторизацией» рядом с «а давайте сделаем тёмную тему в виде космоса с летающими единорогами». И это нормально. Груминг для того и нужен, чтобы отделить зёрна от плевел. Надо только успевать следить, а то однажды у нас появилась возможность кастомизировать интерфейс SubQuery 😅

Планирование

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

flowchart TD
    subgraph "До груминга"
        A[📋 Бэклог<br/>50 задач] --> B{Груминг}
    end
    
    subgraph "Груминг"
        B --> C[❌ Отсев<br/>«Это мы не будем делать никогда»]
        B --> D[📅 В планы<br/>«Вот это берём»]
        B --> E[🔬 Исследование<br/>«Надо подумать»]
    end
    
    subgraph "После груминга"
        D --> F[🔧 Спринт<br/>на 2-3 недели]
        E --> G[📋 Исследовательский<br/>бэклог]
    end

Таким образом мы обеспечиваем себя задачами на несколько недель и убеждаемся, что все задачи в работе имеют понятное описание. Потому что нет ничего хуже, чем открыть задачу с описанием «сделай хорошо» и пытаться угадать, что имел в виду автор. Да я, блин, сам иногда забываю, что имел ввиду, даже если прошла всего пара недель. В сумасшедшие времена живём, коллеги.

На планирование зовём менеджера продукта и ведущего разработчиком. Иногда встречаемся и чаще — если задачи выполняются быстрее ожидаемого и план срочно требует пополнения.

Статусы

Раз в неделю у нас созвон со всей командой. Рассказываем, что сделано, смотрим демки, раздаём задачи, запланированные на реализацию, поясняем их. Обсуждаем новости. Это не стендап в классическом понимании, это скорее «шоу талантов», где каждый показывает, что накодил за неделю, а остальные пытаются вежливо не заснуть, если демка затягивается.

Шучу конечно. Демки и объяснения реализаций - самая интересная часть. Коллективный разум от этого становится сильнее.

А ещё на статусах задачи из "В проде" помечаются сделанными и пропадают с доски в архив, чтобы не захламлять.

Подписывайтесь на наш telegram канал

Исследование

Некоторые идеи требуют помощи коллективного разума. Инициатор проводит предварительное исследование самостоятельно, фиксирует свои наработки в документах, и мы созваниваемся, чтобы посмотреть на это вместе.

Это как защита диплома, только без комиссии и без мантии. Человек говорит: «Я тут покопался, вот что нашёл, вот как предлагаю сделать». А мы такие: «А что если?..», «А не упадёт ли?..», «А не проще ли?..». В общем, классический code review, только на уровне идей. Цель вопросов и споров тут не в блокировке идеи, а в её проверке и доработке. К сожалению, и некоторые мои идеи тут отбрасываются, и идут коптиться дальше

flowchart TD
    A[💡 Идея] --> B[🔬 Исследование]
    B --> C[📝 Документ<br/>с выводами]
    C --> D[👥 Командный<br/>колл]
    D --> E{Решение}
    E -->|Одобрено| F[📋 В бэклог]
    E -->|На доработку| B
    E -->|Отклонено| G[🗑️ В корзину]

Демонстрации пользователям

С любимыми клиентами мы иногда проводим демонстрации последних фич и тизерим грядущие планы. Цель — вовлечь их, дать пищу для размышлений, обязать попробовать и дать фидбэк, обременив чувством вины (простите, коллеги).

На самом деле фидбэк от пользователей — это наше всё. Можно сколько угодно строить идеальные архитектуры на белой доске, но реальность всегда вносит коррективы. Пользователи — лучшие тестировщики. Особенно когда пытаются сделать что-то, что мы даже представить не могли. Типа «а можно эти данные локально выгрузить?». И мы такие: «Ну, вообще-то нет, но дай нам неделю».

Инфраструктура

Мы хостимся в Яндекс Облаке. Пробовали также облако от Сбера — Cloud.ru. Там несколько ПОД-облаков, так сказать: платформа от Huawei, что-то от VMware и новая разработка Evolution, которая, как я понимаю, теперь целевое решение.

Из этих двух что-то лучше, что-то хуже — не готов конкретное рекомендовать. Яндекс я выбрал как более зрелое решение (по сравнению с Evolution), хотя на деле не всегда так получается: некоторые сервисы в Cloud.ru работали стабильнее. Но в IT, как и в отношениях, всегда приходится идти на компромиссы.

Ещё я детальнее смотрел облако от VK. Там меня при регистрации заставили закинуть косарь на счёт, чтобы просто в интерфейсе потыкать объектное хранение. Объектное хранение не пригодилось, а мой косарь так и остался лежать у них на счетах. Фу такими быть.

Кстати, объектное хранение я пересмотрел у всех отечественных облачных провайдеров, которых смог найти, когда искал поддержку vended credentials. Не нашёл. Тоже одна из причин выбора Яндекса — там хотя бы самостоятельно можно выписывать временные креды. Остальные предлагали либо статические ключи, либо «напишите в поддержку, спасибо, до свидания».

Разработка

Разработка происходит в основном на локальных машинах. При этом запускается основное приложение на Node.js и подключаются сервисы, развёрнутые в нашем облаке в dev-контуре через специально настроенный VPN.

flowchart LR
    subgraph "Локальная машина"
        A[💻 IDE] --> B[Node.js<br/>приложение]
    end
    
    subgraph "Облако (dev)"
        C[База данных]
        D[Vault]
        E[DBT сервер и тд]
    end
    
    B <-->|🔒 VPN| C
    B <-->|🔒 VPN| D
    B <-->|🔒 VPN| E

Это даёт нам скорость разработки, близкую к максимальной, и при этом позволяет не поднимать всю инфраструктуру локально, в чём есть смысл только зимой.

Регистрируйтесь на SubQuery

Релизы

После реализации фичи отправляется PR на ревью. Проверяется и мерджится в stage. Потом происходит билд, и новая версия всего приложения выкатывается в stage-контур, где её может посмотреть менеджер самостоятельно и дополнительно протестировать в среде, почти идентичной боевой.

После стейджа версия попадает в prod, и её видят пользователи.

flowchart TD
    A[👨‍💻 Фича] --> B[📤 PR]
    B --> C[👀 Code Review]
    C --> D[🔀 Мердж в stage]
    D --> E[🏗️ Билд]
    E --> F[🧪 Stage-контур]
    F --> G[✅ QA / Менеджер]
    G --> H[🚀 Прод]

Когда подрастём, возможно, сделаем ещё несколько dev стендов с возможностью подымать версию с превью конкретной фичи до мерджа в основную ветку.

Изоляция

Я уже упомянул три контура разработки: dev, stage, prod.

Помимо этого изоляция происходит по используемым базам: отдельная база у прода и стейджа и отдельные dev-базы у каждого разработчика. Потому что миграции - это непросто. Если б я терял волос каждый раз, когда призма угрожает стереть все данные из-за расхождения схемы..

Изоляция используемых секретов сделана через коллекции в HashiCorp Vault. Там есть как общие коллекции, так и отдельные для разработчиков и контуров. Пароли, токены, ключи — всё лежит в Vault, а не в .env файлах, которые кто-то случайно пушит в репозиторий. Да, мы все через это проходили. Кто не пушил .env в публичный репозиторий — пусть первый бросит камень. Или хотя бы признается, что ему просто повезло.

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

Предварительный просмотр для пользователей

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

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

Вот так мы и живём. Без вылизанных процессов, без идеального аджайла из учебников, но зато честно. Если у вас есть вопросы — пишите.

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