Создаем технологическую платформу для разработки: практический опыт

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

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

· Стандартные библиотеки логирования – объединяют в себе типичный набор функций, который не меняется от продукта к продукту: состав логов, требования к фиксированию и трассировке данных и проч.

· Шаблоны микросервисов – позволяют командам создавать новые микросервисы буквально за несколько минут.

· Шаблоны проектов в Azure DevOps – создают единое представление об управлении проектами: и на верхнем уровне, где менеджеры планируют развитие продукта, и на нижнем, где разработчики выполняют задачи и поставляют релизы заказчику.

· Quality Gates – автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки.

· Feature Flags – переключатели функций в коде, обеспечивают бизнесу рычаги для управления возможностями продукта.

· Архитектурная нотация С4 – удобная модель для всестороннего описания программных архитектур.

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

Эти библиотеки обеспечивают командам одинаковое представление о требованиях к логированию. Они объединяют в себе некий набор функциональных характеристик, которые не меняются от продукта к продукту, например, состав логов, средства и стандарты трассировки данных и т.д..

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

Здесь смысл в том, чтобы команды могли создавать новые микросервисы буквально за несколько минут, по единым стандартам архитектуры.

Эти средства тоже успешно используются во всех новых продуктах. Суммарно за последний квартал три наши команды сэкономили 60-80 часов уже на старте проектов.

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

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

Эти шаблоны успешно используют все команды. В результате и рутины с TFS меньше, и иерархия задач у всех одинаковая, и способ именования веток. Из ближайших планов – предстоит разобраться с размерностью задач, чтобы таски и PBI включали примерно одинаковое количество часов, но это уже рабочие мелочи.

В данном случае речь о статическом анализе кода, для чего мы используем SonarQube. Сейчас бэковые сервисы в наших новых проектах проверяются везде, покрытие юнит-тестами составляет 80-100%.

В данный момент на проверке SonarQube находится 121 репозиторий, из которых 81 развиваются активно (есть коммиты за последние полгода). Как видим по результатам проверок, сложность поддержки, безопасность и надежность кода в целом находится на хорошем уровне по стандартам SonarQube.

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

Одно из самых актуальных направлений сейчас для нас – это внедрение Trunk-Based Development и фича-флагов. Важное новшество новых проектов в том, что команды создают отдельные репозитории под каждый микросервис – это сильно упрощает раздельное разворачивание. Особенно хорошо положительный эффект дает о себе знать в сочетании с шаблонами микросервисов, которые разгружают руки разработчиков.

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

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

Команды избавились от необходимости поддерживать диаграммы в отдельных базах знаний, а данные об архитектуре обновляются автоматически. Вне зависимости от того, какие инструменты используют команды (одни сейчас работают с PlantUML, другие – с MermaidJS).

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