Внутренние платформы разработки (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. Что из этого получится — расскажем в следующих статьях.