В докладе Gartner методология Platform Engineering определена в качестве одного из стратегических технологических трендов на 2024 год, что свидетельствует о дальнейшем эволюционном развитии подходов DevOps. Несмотря на это, для многих компаний Platform Engineering и Internal Development Platform (IDP) как один из примеров реализации прохода до сих остается «черным ящиком». 

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

Типовая архитектура IDP

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

Ниже представлена структурная схема IDP, какой ее видит наша команда.



Как видно из схемы, количество компонентов, входящих в IDP, достаточно велико. Скорее, это идеальная картина того, как должно быть и к чему стоит стремиться. Тем не менее можно выделить основные и вспомогательные сервисы IDP. Без основных разработка в принципе невозможна, а вспомогательные обеспечивают повышение качества, безопасность и совместную работу нескольких команд, другие преимущества и дополнительные возможности.

В состав основных сервисов, как правило, входят:

• Портал IDP. Центральный компонент платформы, обеспечивающий участникам команд разработки доступ к инструментам платформы. На уровне этого компонента осуществляется централизованное управление доступом, обеспечивается разграничение работы команд (Multitenancy), отсюда доступен каталог типовых услуг, здесь же реализуется логическое деление: по организациям, проектам, командам. С портала IDP начинается пользовательский путь к инструментам, на портале доступны настройки «общих» служб: нотификации, интеграции с внешними системами (webhooks, etс.), профиля пользователя и других. Портал также является точкой интеграции с API (API Endpoint), выступая фронтом для инструментов автоматизации.
  
• ALM-система (Application Lifecycle Management, в упрощенном варианте — Task Tracker). Данный компонент позволяет создать виртуальное пространство для организации работы команды. Именно здесь происходит управление рабочим процессом разработки: ведется бэклог ПО, заводятся баги, создаются и назначаются задачи, определяются ответственные, планируются инкременты продукта (релизы, спринты, итерации и пр.) и многое другое. Абсолютно все участники типовой команды разработки пользуются данным инструментом, и, как правило, каждый новый рабочий день команды стартует здесь.
  
• Wiki. Используется для создания внутренней документации с целью шеринга знаний как внутри команды, так и в организации в целом.
  
• VCS на базе Git. Основная функция этого компонента — хранение и версионирование исходного кода. Здесь выполняется основная работа с кодом: хранится код, ведется история изменений, осуществляется ветвление кода для обеспечения параллельной разработки и релизного процесса, обеспечивается доступ к коду со стороны участников команды и сторонних инструментов (инструментов CI/CD, AppSec-решений, систем тестирования и других). Почти все участники команды работают с репозиториями хранения кода.
  
• Инструменты CI/CD (Continuous Integration / Continuous Delivery). Данные инструменты используются для выстраивания конвейеров сборки, интеграции и развертывания ПО. Инструменты данного типа позволяют интегрировать в конвейер запуск тестирования и проверки исходного кода, а также позволяют развернуть уже собранные артефакты в целевой рабочей среде (ВМ, K8s, FaaS и пр.). По сути, инструменты CI/CD обеспечивают трансформацию кода из статичного состояния в репозиториях в артефакты, которые потом запускаются в целевой среде и обеспечивают работу ПО.
  
• Репозитории хранения артефактов. Основное назначение этого компонента — обеспечивать хранение, загрузку и распространение готовых или созданных в процессе разработки артефактов. К артефактам могут относиться пакеты Nuget, Pypi, образы Docker или просто бинарные файлы неопределенного типа. Основными потребителями репозиториев артефактов являются разработчики, DevOps-инженеры и инструменты CI/CD. Как правило, участники команды разработки ограничиваются загрузкой из репозиториев необходимых для разработки пакетов. В то же время инструменты CI/CD используют репозитории более активно: загружают необходимых артефакты для сборки ПО, выгружают собранные артефакты обратно в репозитории и используют артефакты в репозиториях для развертывания в целевой среде.
  

 Список вспомогательных сервисов более обширен:

• Система управления тестированием (TMS). Как правило, тест-система — основное рабочее пространство тестировщиков, которые формируют здесь тестовые планы и разрабатывают тест-кейсы, проводят тестирования ПО, работают с отчетами о тестировании, заводят баги и выполняют другие операции.
  
• Сервис развертывания инфраструктуры. Инструмент используется для автоматизированного развертывания и настройки инфраструктуры и приложений в рабочей среде. С его помощью можно создать шаблоны типовой инфраструктуры и типовых стендов, учтя в них требования всех заинтересованных лиц: от ИБ и ИТ до отдельных команд разработки. После создания шаблоны публикуются в каталоге услуг, к которому имеют доступ продуктовые команды. Данный сервис позволяет развертывать одобренные в компании типовые элементы инфраструктуры без согласования, то есть в режиме самообслуживания.
  
• Сервис аналитики. Данный сервис собирает аналитические данные со всех сервисов и инструментов и позволяет их просматривать в виде специальных виджетов. При помощи сервиса можно контролировать сквозные метрики разработки (DORA metrics, скорость закрытия задач, количество выполненных успешных сборок, статистику потребления ресурсов и др.).
  
• AppSec and Quality Tools. Данные инструменты и сервисы обеспечивают сканирование кода, бинарных файлов и запущенных приложений на наличие уязвимостей (Secret Detection, SCA, OSA, SAST, DAST), а также выявляют плохие практики, примененные в разработке (определение % дубликатов кода, использование плохих практик и не только). Таким образом, внедрение инструментов AppSec и Quality Tools в платформу повышает надежность самой платформы со всем доступным стеком, а также помогает нативно выполнять многие требования безопасной разработки. 
  

Подробнее об AppSec можно почитать здесь, о безопасной разработке — здесь, об организации безопасной разработки на уровне процессов — здесь.

• Реестр сервисов. По сути, это реестр, разрабатываемых в организации сервисов с сопутствующей полезной информацией: имя сервиса, его зависимости (входящие и исходящие), документация по сервису (OpenAPI и другие). Данный сервис особенно востребован в крупных компаниях, где проводится разработка широкой линейки продуктов, сильно связанных друг с другом. Благодаря этому сервису можно быстро определить точки интеграции с соседним сервисом и развернуть тестовые экземпляры этого сервиса, проведя необходимые интеграции. В идеальном случае эти операции можно выполнить без взаимодействия с владельцем сервиса. Одним из примеров такого реестра может выступать Backstage.
  
• Удаленное пространство разработки. Сервисы этой категории обеспечивают доступ участникам команд разработки к их рабочим местам. Классический пример — VDI. Плюсы очевидны: рабочее место со всеми инструментами и доступами создается за пару минут (то есть ускоряется Onboarding), а с другой — VDI позволяет учесть требования безопасности (сложную структуру контуров и сегментов, запрет на разработку на личных устройствах и другие). Помимо VDI, могут использоваться и другие формы удаленных окружений разработки — например, GitHub Codespaces.
  
• Data Management. Данные сервисы позволяют предоставить разработчикам доступ к каталогу данных, доступным для разработки. Здесь осуществляется выстраивание ETL-процесса, обезличивание данных, подготовка и публикация в каталоге данных. Это позволяет командам получить доступ к актуальным данным, необходимым в разработке. Классическим примером такого класса ПО является Delphix.
  

Взаимодействие сервисов внутри IDP

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

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

• Интеграция с Git — для создания веток в Git, ассоциированных с разными задачами, контроля выполнения задач, отслеживания коммитов и других операций. Такая связь позволит продактам наблюдать за тем, сколько ресурсов команды потребовалось для решения задачи, а разработчикам — удобно отчитываться о своей работе, закрывая задачи прямо из Git.
  
• С тест-системой — чтобы связывать тестовые сценарии с элементами таск-трекера (User Story, задача и пр.) для выстраивания сквозной Visibility между поставленной задачей и разработанными для нее тестами, а также для отслеживания достаточности тестов и успешности их прохождения. Такая интеграция таск-трекера с тест-системой и Git позволяет контролировать качество исполнения задач.
  
• С CI/CD — для связи конвейеров интеграции и деплоя с определенными задачами, итерациями разработки, релизами, версиями продукта. Примеры таких интеграций: в случае неуспешной релизной сборки на уровне CI/CD создается задача на доске и назначается специалист для исправления, а в случае успешной сборки сборка появляется в атрибутах задачи, созданной под релиз. Это позволяет установить связь всех закрытых задач / пользовательских историй со сборкой, отправленной в релиз.
  
• С аналитическим модулем — чтобы при помощи виджетов посмотреть статистику по закрытым задачам, диаграмму «сгорания задач» и другие метрики.
  
• С инструментами AppSec — чтобы в случае обнаружения уязвимостей иметь возможность быстро «зарегистрировать» дефект и поставить задачу на его устранение. Такая связь «таск-трекер — инструменты AppSec» сводит к минимуму риск того, что ошибка будет потеряна или проигнорирована.
  

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

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



Другим примером являются инструменты CI/CD, которые также тесно интегрируются с остальными компонентами IDP.

Например, при построении пайплайна в CI/CD-инструменте при помощи «умных» код-сниппетов можно выбрать уже созданные репозитории артефактов, определить, какие таски будут созданы в таск-трекере после сборки, а также назначить, куда загружать результаты тестирования. Такие интеллектуальные автоподстановки значительно упрощают выстраивание процессов сборки и развертывания.

Компоненты внутри IDP должны формировать полноценную экосистему. То есть инструменты должны быть совместимы между собой и иметь широкий набор интеграций друг с другом.

Причем в рамках подобной экосистемы важно, чтобы переключаться между инструментами можно было бесшовно. В таком случае при переходе от инструмента к инструменту пользователям не придется повторно логиниться, стараться учесть потенциально разные права доступа и другие нюансы. Эту задачу обычно решают с помощью технологии единого входа (Single Sign-On, SSO).

IDP и внешняя ИТ-инфраструктура

Важна не только сам IDP, но и то, с какой инфраструктурой он взаимодействует, как интегрируется.

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



Как правило, в цикле разработке используются различные окружения (экземпляры инфраструктуры), в которые приложение развертывается. Важно отметить, что технологическая платформа всех стендов (dev, test, qa, stage, prod) должна быть в идеале идентичной. Тогда приложение, работающее в stage, с большей долей вероятности будет корректно функционировать и в prod.

От типа инфраструктуры, в которой будут развертываться приложения, также зависят возможности IDP. Не секрет, что множество современных продуктов имеют адресные интеграции с On-prem-решениями на базе VMware vSphere, OpenStack и публичными облаками.

Сервис развертываний и CI/CD-инструменты, как правило, работают с инфраструктурой напрямую. Интеграция осуществляет за счет системы плагинов, которые позволяют взаимодействовать с отдельными компонентами инфраструктуры (IaaS, PaaS, Observability-сервисами и ИБ-службами). Чем больше у данных сервисов IDP различных плагинов, упрощающих взаимодействие с внешней инфраструктурой, тем проще и быстрее можно выстроить конвейер сборки и развертывания или создать типовой стенд для публикации в каталоге услуг.

IDP: инструменты и процессы

Помня про важность инструментов, не стоит забывать про процессы. Уверен многие читатели помнят, как Билл Палмер по совету Эрика Рида ( герои книги «Проект «Феникс» как DevOps устраняет хаос и ускоряет развитие компании») открывал новые для себя типы работы, приземлял их на существующие или внедряемые в компании процессы, систематизируя, а иногда «закручивая гайки». И поскольку IDP – это своеобразный оркестратор сервисов, то используемые его инструменты должны не только нести ценность сами по себе, но и сводить все действия участников в единый, управляемый и контролируемый процесс. Иногда это даже может означать ограничение возможности некоторых действий для разработчиков. Получается такой оксюморон: с одной стороны IDP — это сервис «единого окна» с задачей дать командам больше возможностей, с другой — потенциальный инструмент ограничений.

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

Главное на наш взгляд, что IDP – должен иметь возможность оркестрировать не только инструменты, но и процессы.

Варианты реализации

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

• использовать в основе IDP готовые DevOps-платформы;
  
• разрабатывать собственную платформу с нуля на базе Open-Sources-решений.
  

Каждый из вариантов имеет свои преимущества и недостатки:

• Использовать готовое решение быстрее и проще, но возможности настройки такой платформы будут ограничены. Здесь компании придется отталкиваться от того, что уже есть. Исключение — платформы на базе Open-Sources-инструментов, в которых нивелирована проблема «негибких решений».
  
• Создание платформы на базе Open-Sources-решений — самый сложный с точки зрения реализации подход, требующий больших ресурсов и команды опытных специалистов. Соответственно, стоимость развития, обновления и обслуживания такого кастомного решения будет существенно выше. Но есть и плюс: целевая платформа будет адресно заточена под нужды компании и ее бизнес-процессы. Такая платформа позволит выстроить собственный Golden Path to Production.
  

Примеры готовых решений

В качестве основы для IDP можно использовать две наиболее популярные DevOps-платформы: Azure DevOps и GitLab. Это комплексные решения, сочетающие в себе основные сервисы IDP. 
Безусловно, для полноты решения к этим продуктам придется добавить портал собственной разработки и дополнительные сервисы — например, системы тестирования, инструменты AppSec, оркестраторы инфраструктуры и другие.

Azure DevOps — DevOps-платформа от Microsoft, которая предоставляет инструменты для управления жизненным циклом приложений. Объединяет в себе инструменты для разработки, тестирования, развертывания и управления программным обеспечением, в том числе:

• Azure Boards — инструмент для управления задачами и проектами, который позволяет отслеживать прогресс работы, назначать задачи, планировать инкременты в продукте;
  
• Azure Repos — система контроля версий, которая позволяет хранить код в репозитории и работать с ним удаленно;
  
• Azure Pipelines — инструмент для автоматизации процессов сборки, тестирования и развертывания приложений;
  
• Azure Test Plans — инструмент для управления тестированием приложений, который позволяет создавать тестовые планы и кейсы, запускать их, собирать результаты и так далее;
  
• Azure Artifacts — система управления артефактами, которая позволяет хранить и распространять пакеты, библиотеки и другие ресурсы, необходимые для разработки и развертывания приложений.
  

Таким образом, компоненты Azure DevOps формируют классическое ядро IDP и покрывают весь цикл разработки. Портал продукта также позволяет подключать при необходимости дополнительные инструменты.

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

GitLab — популярная DevOps-платформа, которая позволяет участникам команд разработки работать вместе над кодом, документацией, проблемами и релизами. Как и Azure DevOps, GitLab также предлагает практически полную экосистему решений, необходимых для формирования ядра IDP. Среди них:

• GitLab Issues — инструмент, который позволяет совместно работать над идеями, планировать рабочие процессы и решать проблемы;
  
• GitLab Repository — инструмент для хранения и версионирования исходного кода;
  
• GitLab CI/CD — инструмент для автоматизации процесса разработки, который позволяет автоматически тестировать, собирать и развертывать код;
  
• GitLab Insights — инструмент для анализа данных и метрик, связанных с использованием GitLab.
  

С точки зрения процессов в GitLab тоже есть контрольные точки (типа MR approvals) и шаги конвейера с необходимостью ручного подтверждения действия. Но в GitLab эти настройки не нативны и не встроены в сам процесс.

Итого: Azure DevOps и GitLab во многом являются конкурирующими решениями. Вместе с тем выбор между Azure DevOps и GitLab зависит от потребностей и предпочтений команды разработчиков. Если команда хочет получить все преимущества IDP при работе, в том числе с внешней ИТ-инфраструктурой, то Azure DevOps может быть лучшим выбором за счет тесной интеграции с Azure Cloud, где есть множество дополняющих IDP-сервисов: сервисы Observability, инфраструктура развертывания и другие. В данном случае будет синергия от экосистемы Azure DevOps и Azure Cloud.

Также сильной стороной Azure DevOps являются инструменты контроля за процессом разработки — End-to-end Governance, благодаря которым можно контролировать каждый аспект на пути кода в Production.

Наряду с Azure DevOps и GitLab, работа с которыми в текущих реалий затруднена или полностью недоступна, в своей платформе для разработки Dev Platform мы реализуем экосистемный подход и предоставляем в рамках одного окна:

• таск-трекер,
  
• Git,
  
• CI/CD,
  
• сервисы развертывания окружений,
  
• тест-систему,
  
• репозиторий для хранения и версионирования исходного кода,
  
• сервисы VDI (Virtual Desktop Infrastructure) и не только.
  

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

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

Подробнее о реализации Dev Platform и том, что именно у нее под капотом, расскажем в третьей статье серии — не пропустите.

Главное из статьи

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

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

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

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

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

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

Мы хотим больше узнать о приоритетах команд при разработке платформ. Помогите нам — пройдите опрос. Он займет не более 5 минут.