Привет, Хабр! Меня зовут Ирина Львова, я ведущий эксперт по технологиям в СберТехе — компании, которая создаёт Platform V, цифровую платформу Сбера для разработки бизнес-приложений.

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

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

Эта статья — продолжение цикла материалов о Platform V Works, семействе инструментов для agile-разработки. В предыдущей статье мой коллега Сергей Петровский рассказывал о другом компоненте бандла — инструменте генерации связанных синтетических тестовых данных для сквозных интеграционных тестов, вот его статья.

История вопроса

В Сбере несколько тысяч команд разработки, а количество релизов может достигать 4 000 в месяц. Ориентироваться в таком производственном процессе без agile-инструментов невозможно: путаница в статусах и задачах может привести к снижению скорости и росту time-to-market, а это одни из ключевых показателей для банка.

Большинство процессов, связанных с разработкой программных продуктов, как и у многих других компаний, строилось на инструментах Atlassian. Так было до тех пор, пока в банке не началась цифровая трансформация, которая подтолкнула к постепенному отказу от иностранного программного обеспечения.

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

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

Планирование и подготовка

В качестве основы для разработки мы взяли GitLab CE (распространяется по лицензии MIT). Среди всех DevOps-платформ и инструментов для Agile-планирования GitLab обладал наиболее зрелой функциональностью, а его OSS-версия закрывала большинство функциональных блоков Atlassian, в том числе в части управления требованиями, планирования и предоставления репозитория для исходных кодов.

Вот наглядный пример — сравнение функциональности GitLab и одного из его ключевых конкурентов, CircleCI.

Но в актуальной на тот момент функциональности GitLab как минимум не хватало:

• настраиваемого workflow;

• кастомных полей;

• управления тестовой моделью;

• иерархии задач, возможности добавлять задачи разных типов, например task, story, bug, изменять типы и настраивать для них отдельный workflow;

• приоритетов и аналитики по задачам;

• диаграмм Ганта и сгорания задач;

• скрам- и канбан-досок;

• дашбордов и продвинутого поиска.

Нужно было добавить все эти фичи в наш продукт и учесть требования заказчика: обеспечить варианты представления on-premise и managed-service в облаке; реализовать поддержку кластерной базы данных, горизонтального масштабирования и кластеризации, чтобы обеспечить высокую доступность. При этом продукт и его сервисы должны были быть независимыми как от остальных продуктов Platform V, так и от стороннего ПО.

Одним из главных вызовов для команды стало встраивание наших доработок в архитектурный ландшафт базового open source software (OSS). Мы сохранили обратную совместимость и доступ к обновлениям GitLab, обеспечивающего 1 мажорный и 4 минорных релиза в год. Для этого пришлось разработать целую методику, позволившую совмещать наши доработки с изменениями со стороны комьюнити и самого GitLab.

В работе использовали следующие технологии.

Для backend:

• Ruby 2.7.4

• Rails 6.1.3.2

• Postgres 12.6

• Redis 6.0.15

• GraphQL         

• RSpec 3.10

• Grape 1.5.2

• HAML

Для frontend:

• VueJS 2.6.12

• Vuex 3.6.0

• Jest 26.5.2

• Axios 0.20.0

• Apollo-client 2.6.10

• jQuery

Командная работа была выстроена в SCRUM двухнедельными спринтами, каждый из которых завершался внешним демо с неограниченным количеством участников. Нам нужен был гибкий подход, чтобы быстро оценивать результаты на небольших отрезках времени. Только так можно было быстро реагировать на требования, поступавшие из различных источников, и перестраивать процессы на лету.

Первые месяцы ушли на расширение функциональности управления задачами. Мы добавили возможность создавать истории, баги, запросы на изменения, связывать задачи горизонтально и вертикально именованными связями. Внедрили механизм независимой настройки workflow для каждого типа задач.

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

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

Год спустя: результаты и эксплуатация

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

За год активной разработки и эксплуатации мы создали 4 инструмента на базе GitLab: для управления задачами, требованиями, тестированием и репозиториями дистрибутивов. Все они вошли в финальную линейку Platform V Works. Ниже расскажем о каждом подробнее.

Управление задачами

Инструмент с широким спектром возможностей для работы с требованиями, оформленными в таски.

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

Если внутри задачи не хватает системных полей, пользователь может создать custom fields, обратившись к администратору пространства. Новые поля для каждого типа сущности легко настроить, указав простой список с единственным выбором, список со множественным выбором, численное значение или свободную форму.

Для удобного управления загрузкой команды есть диаграмма Ганта и фильтрация, которая помогает сфокусироваться на определённых задачах.

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

Управление требованиями

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

Все вики-страницы организованы в строгое иерархическое дерево, отображающееся в правом меню. Объекты связаны так, чтобы сохранялась прозрачность последовательности действий — от проектирования до кода. Скажем, если страница была случайно удалена, администратор может её восстановить. У пользователя есть доступ к просмотру истории изменений существующих страниц с возможностью вернуть необходимую версию.

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

Управление тестированием

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

Управление репозиториями

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

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

Для интеграции инструментов доступен GraphQL API, который облегчает агрегацию данных из нескольких источников. Для описания данных используются системы типов.

Подводим итоги

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

Функциональность инструментов на базе Platform V Works сильно превосходит возможности GitLab и не уступает основным решениям Atlassian.

Platform V Works активно используется и представляет реальную альтернативу зарубежным аналогам. При этом продукт является полностью российской разработкой и не имеет vendor-lock-зависимостей. В случае любых форс-мажоров и при любых внешних обстоятельствах наши инструменты останутся работоспособными на 100% и продолжат развиваться.

Все сервисы Platform V Works могут поставляться в виде SaaS- и on-premise-решений. Вместе с продуктами наши команды готовы предоставить аудит производственного процесса и методологию разработки ПО, основанную на лучших практиках Сбера и отработанную на тысячах команд на протяжении нескольких лет.