Внутренние платформы разработки (Internal Development Platform, IDP), как один из артефактов реализации платформенного подхода (Platform Engineering), становятся важной точкой роста для многих компаний, занимающихся разработкой: помогают унифицировать стек, снизить нецелевую нагрузку на команды, сократить time-to-market. Поэтому многие компании начинают двигаться в сторону создания  своих IDP. 

Мы продолжаем серию статей о Platform Engineering и Internal Development Platform (IDP). В первом и втором материалах цикла мы уже рассмотрели базовую теорию, познакомились с типовой архитектурой IDP и вариантами реализации. А в этой статье остановимся на обзоре Dev Platform, разрабатываемой командой VK Cloud.

Немного контекста

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

Internal Development Platform (IDP) — внутренняя платформа разработки, которая является одним из вариантов реализации платформенного подхода. Классически IDP представляет собой портал, который в формате «единого окна» дает разработчикам доступ к инструментам, ресурсам, выстроенным пайплайнам, шаблонам стендов, другим преднастроенным компонентам и решениям. 

О Dev Platform 

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

На этапе зарождения Dev Platform мы рассматривали два варианта реализации решения:

• в виде набора продуктов, имеющих интеграцию между собой (пример — стек Atlassian);

• в виде большого комбайна all-in-one, который включает все сервисы сразу и не предполагает поставку сервисов отдельно (пример — Azure DevOps или Gitlab).

Первый вариант, безусловно, имеет ряд преимуществ — разработка отдельных сервисов легко выделяется в отдельное направление и имеет свой трек продаж. Например, Task Tracker может быть разработан отдельно и продан независимо от других компонентов.

Но наши исследования показали, что лучший Developer Experience был в решениях, построенных по типу All-in-one. Более того, степень интеграции сервисов между собой в решениях такого типа, как правило, выше. Поэтому, чтобы команды разработки с нашим продуктом получали максимум возможностей, мы выбрали путь создания единого решения, которое бы включало все необходимые сервисы «из коробки».

От концепции к реализации

После определения границ продукта и выбора варианта поставки, нам надо было определить, что именно должно стать «центральным ядром» для работы команд с нужными им ресурсами внутри продукта: проект, репозиторий или конкретный сервис. От этого также зависит Developer Experience пользователей платформы.

Например, в github все процессы выстроены вокруг репозитория. То есть реализуется подход repo-first. Это удобно для open-source разработки, когда работа ведется с одним или несколькими публично доступными репозиториями. Например, это отличное решение для inner-source подхода при работе с кодом. Тут очевидно — такой фокус делает сложным насыщение платформы новыми сервисами и их ресурсами, поскольку репозиторий будет на первом месте, даже несмотря на то, что является лишь одним из инструментов команды. 

В gitlab — другой подход. Здесь также преобладает repo-first, но репозиториторий вписан в проект, который, в свою очередь, является центральной точкой работы с ресурсами: окружениями, кодом, CI/CD, тасками. То есть, проект можно насыщать дополнительными сервисами и ресурсами. Например, если появится новый сервис — он просто станет доступен в проекте. Таким образом реализуется project-first подход. 

Но у этой реализации в gitlab есть недостаток — один проект всегда соответствует одному репозиторию. То есть присутствует неявная зависимость проекта от репозитория. 

Этот недостаток устранен в Azure Devops. Так, здесь проект, как и в gitlab, является центральным местом работы команды, но отсутствует жесткая привязка проекта к репозиторию. То есть, репозиторий — один из ресурсов, и их может быть несколько. Это удобно, если в одном проекте, где работает команда, нужно несколько репозиториев — например, для DevOps, QA, Front, Back.

Так или иначе, в github, gitlab и Azure DevOps проекты и репозитории оборачиваются в некую иерархию: 

• в Azure DevOps и Github — это организации;

• в Gitlab — это группы (организации будут скоро также добавлены). 

Такая иерархия очень удобна для организации multitenancy (актуально для SaaS и некоторых on-prem заказчиков) и работы в одном продукте нескольких подразделений одного холдинга.

Взвесив все плюсы и минусы существующих решения, для реализации Dev Platform мы остановились на project-first подходе без жесткой привязки к конкретному ресурсу (по примеру Azure DevOps). Это позволит нам масштабировать сервисы в продукте без изменения пользовательского опыта и иерархии ресурсов. Для реализации multitenancy и предоставления гибкости крупным компаниям, мы сейчас работаем над организациями, в которые будут вписаны проекты.

Таким образом, в рамках Dev Platform мы реализуем подход All-in-One с организационно-проектно-ориентированной моделью. Это позволяет нашим пользователям работать с такими однозначными и ясными понятиями как: организация, проект, сервис и ресурс. С одной стороны, это дает возможность поддержать организационную структуру наших клиентов в продукте, а с другой — поможет выстроить работу каждой отдельной команды разработки в режиме единого окна. 

Состав Dev Platform 

Пользователям Dev Platform мы предоставляем доступ к таким сервисам как:

• таск-трекер;

• git-репозитории;

• CI/CD;

• сервисы развертывания инфраструктуры;

• система управления качеством кода.

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

• позволяем интегрировать платформу в любой окружающий ландшафт;

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

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

Варианты поставки Dev Platform

Уже сейчас доступен on-premise вариант поставки Dev Platform — решение может быть установлено в инфраструктуре Заказчика (поверх частного облака VK). Также в ближайшее время обеспечим возможность развертывания в Публичном Облаке VK, в качестве single-tenant инсталляции. В планах на 2025 год планируется реализация и SaaS-версии продукта.

При этом, как мы уже упоминали в предыдущих статьях (здесь и здесь), наибольший положительный эффект дает экосистема. То есть, максимальное раскрытие потенциала Dev Platform возможно в связке с VK Cloud (как с публичным, так и с частным облаком). Причем на базе платформы VK Cloud можно не только разворачивать инфраструктуру под IDP, но и строить каталог услуг. Использование всего стека инструментов, доступных на облачной платформе, и развертывание Dev Platform поверх VK Cloud позволяет выстраивать полностью экосистемное решение и получать больше ценности за счет глубокой интеграции с механизмами управления облачной инфраструктурой. Причем в данном случае, чтобы разработчик получил необходимые ресурсы, не нужны дополнительные согласования, сложные интеграции и длительные ожидания. 

Также в перспективе с Dev Platform можно будет работать без привязки к облаку VK Cloud — на той инфраструктуре или платформе, которая есть у пользователя.

Dev Platform как IDP

Dev Platform при построении IDP может выступать в качестве готового «ядра» с предварительно настроенными, проинтегрированными и совместимыми сервисами. Причем реализовать такую интеграцию Dev Platform в IDP можно минимальными усилиями со стороны пользователя — решение поставляется в виде «коробки», которая устанавливается при помощи инсталлятора.

Внедрение Dev Platform закрывает в первую очередь greenfield-проекты, которые подразумевают разработку нового решения или инициативы. Объективно, командам гораздо легче начать использовать платформу для разработки нового продукта.

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

Вместе с тем, надо понимать, что установка Dev Platform as-is, к сожалению, не приведет само по себе к перестройке организации и взрывному росту культуры разработки. Следуя Team Topologies, для получения максимального профита от внедрения IDP в компании зоны ответственности должны быть разделены. Так, нужны: 

• команды продукта (функциональные команды), которые разрабатывают продукты;

• платформенная команда, которая администрирует Платформу; 

• команда вовлечения (enabling team), которая помогает остальным участникам процесса максимально быстро и эффективно втянуться в новые реалии.  

Что «под капотом»

«Под капотом» нашей платформы собраны как распространенные инструменты с открытым исходным кодом, так и сервисы, разработанные VK. Например: 

•  ядро платформы в качестве оркестратора компонентов решения;

•  портал самообслуживания как единое окно для участников команд разработки;

•  окружения — компонент, управляющий ресурсами в VK Cloud;

• репозиторий артефактов представлен Nexus Repository;

• сервис развертывания окружений представлен нашей собственной разработкой, которая на базе Terraform-файлов деплоит инфраструктуру в VK Cloud;

• задачи ALM-системы выполняет партнерское решение (на выбор: Devprom ALM или TeamStorm);

• для анализа качества кода доступен SonarQube. 

Вместе с тем, в большинстве своем Dev Platform базируется на open-source компонентах. Выбор в пользу open-source осознан и дает ряд важных преимуществ.

• Низкий порог входа. Многие компании работают с open-source-инструментами, поэтому перейти на Dev Platform могут практически бесшовно — в большинстве случаев не придется сложно и мучительно перестраивать пайплайн с нуля, отказываться от самописных реализаций и скриптов, осваивать новые решения.

• Сокращение рисков vendor lock-in. Поставляя пользователям сервисы с открытым исходным кодом, мы исключаем ситуации, при которых инструмент может стать недоступным по решению компании-разработчика. Так мы позволяем строить стабильные платформы разработки.

Но мы не довольствуемся возможностями open-source «в чистом виде», и в рамках своего продукта расширяем их, а также планируем добавить в ближайшее время:

• multiple approvers in code review;

• merge request approval settings;

• запрет мержа без получения апрува всех ревьюверов;

• merge request approval rules;

• merge rules;

• code owners;

• remote repository pull mirroring.

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

Особенности нашей реализации

• Dev Platform предоставляет портал, который является единой точкой входа с поддержкой SSO (single sign-on) для быстрого, удобного и, главное, безопасного доступа к инструментам. 

• В рамках Dev Platform все инструменты уже проинтегрированы между собой, практически сразу готовы к работе и поставляются в виде единого инсталлятора. При этом за обновление и администрирование компонентов Dev Platform отвечает команда VK Cloud, снимая нагрузку с пользователей. Настройка всех компонентов остается на стороне пользователя, что позволяет гибко адаптировать Dev Platform под специфические задачи компании.

• Портал Dev Platform позволяет осуществлять централизованное управление ролевой моделью, чтобы распределять права доступа к инструментам, функциям и рабочим средам. Благодаря этому, можно реализовывать логическое деление по командам, проектам и даже организациям (что особенно важно в случае привлечения специалистов на аутсорсе). Причем то, что настроено через портал, нельзя изменить на уровне отдельного инструмента — это исключает риск несанкционированного изменения прав доступа.

• Вместе с платформой мы поставляем набор различных практик, преднастроенных Terraform- и CI/CD-шаблонов, которые позволят ускорить сборку и развертывание приложений на инфраструктуре VK Cloud.

• Порог входа в работу с Dev Platform минимален. Во-первых, вместе с платформой мы поставляем набор методических рекомендаций с гайдами по развертыванию решений, настройке, примерами лучших практик и другими материалами. Во-вторых, мы предлагаем обучение и консалтинговые услуги в части настройки инструментов, перестройки процессов, аудита, сопровождения, внедрения Application Security компонентов, выстраивания end-to-end процесса разработки и других задач. 

• Dev Platform позволяет централизованно управлять инфраструктурой. Также решение дает возможность управлять разработкой не только в рамках проектов, но и в рамках организаций.

• В Dev Platform реализован инструмент интеграции внешних систем для простого подключения новых решений по API и веб-хукам. Это предопределяет возможность дальнейшего расширения стека Dev Platform и функциональности платформы в целом.

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

Сценарии работы с Dev Platform

Dev Platform — all-in-one-продукт, поэтому с ним можно работать по-разному.

• Построение IDP. Базовый сценарий, который подразумевает применение Dev Platform в качестве основы для построения IDP. В таком сценарии пользователь может быстро развернуть из инсталлятора готовый набор преднастроенных и проинтегрированных инструментов, сокращая затраты ресурсов и времени на подготовку IDP.

• Настройка собственного процесса разработки. Во многих enterprise-компаниях важен комплаенс с точки зрения безопасности и ИТ-инфраструктуры. Dev Platform позволяет на уровне портала ограничить функции инструментов и настроить шаблоны работы с ними (например, в части хранения, CI/CD, деплоя и не только), чтобы унифицировать пайплайн, повысить контроль над циклами разработки и исключить нецелевое использование ресурсов.

• Обеспечение безопасной разработки. Сейчас приоритетом многих компаний является безопасная разработка и интеграция с инструментами DevSecOps. Поэтому в Dev Platform, совместно с крупнейшими компаниями в области информационной безопасности, реализованы интеграции с AppSec-инструментами. Это позволяет полностью закрыть end-to-end цикл с учетом требований security software development lifecycle (SSDLC). 

• Разделение на различные контуры разработки. Многие компании реализовывают разделение по контурам — например, на Dev и Prod. При этом полученные сущности максимально между собой развязаны — как правило, у пользователей разные доступы к каждому из сегментов. Например, Prod контур является более доверенным, и для попадания в него кода или артефакта должны быть пройдены ряд проверок. Если развертывать среды с помощью Dev Platform, за счет максимальной идентичности инструментов и окружений, при переносе кода в прод не возникает никаких проблем с совместимостью. Аналогично дополнительный экземпляр Dev Platform можно разворачивать для создания тестового контура out-source-разработки, тесно связанного с основным контуром.

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

Как это все работает

Для наглядности кратко разберем возможности работы с Dev Platform для пользователей двух категорий:

• менеджера проекта (либо любого другого человека, отвечающего в компании за запуск разработки и имеющего права на выделение ресурсов);

• разработчика.

Менеджер проекта

В Dev Platform менеджеру проекта доступна возможность создания нового проекта или работы с уже существующим.

Помимо этого, из единого окна он может:

• создавать и настраивать необходимые компоненты;

• управлять пользователями и/или группами пользователей (интегрированных с AD);

• выдавать доступы (например, DevOps-инженеру для настройки стендов) и не только.

Тут сразу нужно сделать несколько ремарок.

• Облачный проект нужно предварительно добавить. Делает это специалист, ответственный за виртуальные ресурсы, либо сам DevOps, которому передали креды. Добавление происходит через механизм service connection.

• Разворачивая окружение, DevOps использует terraform-скрипт, с помощью которого создаются необходимые ресурсы в выбранном облачном проекте.

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

Примечание: Реализацию взаимодействия между нашей платформой и облаком VK Cloud мы рассмотрим в рамках отдельной статьи.

Разработчик

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

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

Что дальше?

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

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

Помимо этого наш приоритет на среднесрочную перспективу — повышение технологической независимости и локализации инструментов, входящих в стек платформы. Для этого мы планируем постепенный переход на решения собственной разработки и сервисы партнеров, разрабатываемые в РФ. 

Мы уже сейчас плотно работаем с Dev Platform для решения внутренних задач, в том числе при разработке Dev Platform — закрываем с ее помощью значительную часть пайплайна разработки. Вместе с тем, в перспективе мы планируем перевести на Dev Platform разработку не только внутри VK Tech. Что из этого получится — расскажем в следующих статьях.