Разработка основы самообслуживания разработчика

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

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

Автоматизируйте рабочие процессы, агрегируйте данные, начните с простого и расширяйтесь постепенно

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

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

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

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

Как правило, возможности самообслуживания делятся на две основные категории: автоматизация и агрегирование данных.

Хотя агрегирование данных создает хороший интерфейс пользователя, автоматизация важнее:

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

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

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

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

Начните с простого использования существующих инвестиций, таких как ваши инженерные системы или внутренний портал, а затем перейдите к созданию интерфейсов CLIs, базовых веб-страниц или даже Power Pages, Power BI или панелей мониторинга Microsoft Fabric и развернитесь по мере возникновения необходимости. Имея согласованный API, который затем используется UX, вы сможете со временем поддерживать несколько интерфейсов по мере изменения ваших потребностей и предпочтений.

Компоненты платформы самообслуживания разработчика: API, граф, оркестратор, поставщики и метаданные

Рассмотрим основы самообслуживания разработчика:

Как показано на рисунке, следующие компоненты составляют основу концепции самостоятельного фонда разработчика:

Компонент	Description
API платформы разработчика	Ваша единая точка контакта для взаимодействия с пользователями. Это фактически контракт системы с другими системами.
Граф платформы разработчика	Управляемый и безопасный граф данных, позволяющий обнаруживать, связывать и использовать различные виды сущностей и шаблонов. Сущность — это объект, который позволяет агрегирование данных из нескольких источников, а шаблоны управляют входными данными пользователей, которые обеспечивают автоматизацию.
Оркестратор платформы для разработчиков	Возможность маршрутизации и отслеживания запросов на основе шаблонов для выполнения действий в системе или вручную. Эти запросы направляются в один из наборов поставщиков платформ разработчиков, которые могут интегрироваться в любое количество различных систем рабочих процессов или других служб.
Поставщики платформы разработчиков	Набор компонентов, которые инкапсулируют логику, необходимую для интеграции с нижестоящими системами для поддержки CRUD операций с сущностями или выполнения запросов, основанных на шаблонах. Каждый поставщик может поддерживать собственный тип шаблонов и выдавать уникальные или распространенные типы сущностей.
Профиль пользователя и метаданные группы	Возможность сохранять сведения о наборе лиц, привязанных к концептуальной команде для группировки и доступа к API платформы разработчиков. Пользователь тесно связан с учетной записью поставщика удостоверений (например, вход идентификатора Microsoft Entra), но и она, и команда могут связать любое количество связанных системных представлений нижестоящего типа. Одной из реализаций этого хранилища данных является повторное использование графа платформы разработчика. Фонд самообслуживания разработчика может установить общий тип сущности как для пользователя, так и для команды, и сохранить эти сведения в графе. Тем не менее, в целях ясности мы будем держать этот магазин отдельно.

Эти базовые компоненты позволяют использовать и заменять различные стандартные блоки по мере необходимости.

Нужно ли создавать все это, чтобы приступить к работе?

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

API платформы разработчика

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

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

Поставщики платформы разработчиков

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

Это также важный способ обеспечить масштабируемый подход inner source в вашей платформе. Как правило, внутренние инициативы по платформенной инженерии не получают распространения из-за проблем с текущим обслуживанием. Другие команды могут быть готовы внести свой вклад в функциональность, но вряд ли будут готовы поддерживать и тестировать что-то в ядре вашей платформы. И наоборот, любая централизованная команда имеет ограниченные возможности для поддержки внесенного кода или даже проверки пулл-реквестов. Концепция поставщика платформы разработчика устраняет эту напряженность, позволяя независимо написанному коду подключаться к основным функциям в рамках самостоятельной платформы разработчика. Хотя вы должны тщательно управлять используемыми поставщиками, просматривать любой код поставщика и ограничивать область поверхности, доступ к которой данный поставщик может получить в вашей платформе разработчика, подключаемый подход может помочь вам сделать больше, масштабируя усилия в более широкой части организации.

Основные понятия поставщика платформы разработчика

Entities

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

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

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

Общие свойства

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

• Уникальный идентификатор
• Имя
• Исходный поставщик
• Необязательные ассоциации:
  • Владение пользователем
  • Команда владельцев
  • Другие объекты

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

Общие сущности и сущности, специфичные для поставщика

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

• Окружающая среда
• Ресурсы
• Программные интерфейсы
• Репозитории
• Components
• Tools

Как правило, они должны находиться на высоком уровне, например, в контексте модели C4 или на наиболее высокоуровневых схемах компонентов. Например, для среды не требуется включать сведения о топологии внутренней инфраструктуры; Достаточно информации для перечисления и связывания различных концептуальных сред с несколькими поставщиками в одном пользовательском интерфейсе. Сущность может указывать на более низкие уровни детализации вне системы, вместо того чтобы поглощать всё. Они предоставляют начальные точки для обнаружения, которые являются ключевыми для обеспечения агрегирования данных с течением времени.

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

Шаблоны

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

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

Примеры шаблонов:

• Шаблоны инфраструктуры как кода (IaC)
• Шаблоны приложений (справа) или репозитории шаблонов
• Построение шаблонов конвейеров/рабочих процессов
• Конвейер развертывания или шаблоны рабочих процессов
• Параметризованные скрипты
• Параметризованные потоки Power Automate (например, http-запрос активировал облачный поток)
• Шаблоны сообщений электронной почты

Как и сущности, шаблоны могут включать свойства, относящиеся к поставщику.

Каждый шаблон может иметь другое представление, уникальное для поставщика. Они могут варьироваться от шаблонов Terraform или ARM до диаграмм Helm, параметризованных рабочих процессов GitHub Actions или Azure Pipelines, простых скриптов или пользовательских форматов.

Фактические сведения о базовом шаблоне не обязательно должны храниться централизованно. Они могут существовать в разных репозиториях, реестрах или каталогах. Например, можно использовать репозитории шаблонов GitHub для шаблонов приложений, в то время как шаблоны IaC могут существовать в ограниченном репозитории каталога, к которому разработчики могут получать доступ только через такие среды развертывания Azure. Другие шаблоны IaC могут храниться в реестре артефактов OCI, таких как диаграммы Helm. В других случаях шаблон может быть ссылкой на параметризованную конечную точку HTTP. Поставщик платформы для разработчиков должен предоставить достаточно информации о каждом типе шаблона, чтобы на них можно было ссылаться, а также о любых параметрах, предоставленных для использования в пользовательских интерфейсах. Но сами шаблоны можно разместить в наиболее естественном расположении для ваших вариантов использования.

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

Граф платформы разработчика

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

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

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

Оркестратор платформы для разработчиков

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

Вы можете использовать GitHub Actions, Azure Pipelines или другой обработчик рабочих процессов в качестве оркестратора. Это разумное место для начала, но может потребоваться немного абстракции, чтобы разрешить различным типам шаблонов использовать разные базовые механизмы. Это может быть полезно по нескольким причинам:

• Во-первых, вы, скорее всего, захотите выбрать различные механизмы выполнения рабочих процессов и задач с течением времени без необходимости вырезать. Разрешив использование более чем одного движка, можно постепенно перейти или просто использовать новый движок для новых действий, не затрагивая старые.
• Некоторые процессы, в оркестрации которых вы хотите помочь, могут потребовать выполнения шагов вручную, даже если позже вы планируете их полностью автоматизировать.
• Другие действия могут быть нацелены на роли за пределами команды разработчиков, такие как расчёты с поставщиками или администратор лицензий. Платформы с минимальным кодированием, такие как Power Automate, часто хорошо подходят для этих ролей.
• Другие действия могут обрабатываться с помощью простых HTTP-запросов, где запуск такого, как GitHub Actions или Azure Pipelines, не требуется или не является экономически эффективным для масштабирования.

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

Ниже приведена общая концепция:

• Шаблоны могут дополнительно указать набор входных данных, которые пользователь может ввести. Когда разработчик активирует определенное действие, они выбирают шаблон (даже если не описаны таким образом) и вводят входные данные.
• Ссылка на входные данные, связанные с шаблоном, становится запросом в API платформы разработчика.
• После отправки запроса компонент маршрутизации и обработки запросов в оркестраторе начинает отслеживать жизненный цикл запроса. Компонент маршрутизации и обработки запросов направляет шаблон в запросе к поставщику платформы разработчика, где этот шаблон был создан.
• Затем поставщик платформы разработчика выполняет соответствующие шаги для его реализации.
• (Необязательно) Поставщик платформы разработчика обновляет состояние запроса по мере выполнения действия.
• После выполнения запроса поставщик платформы разработчика может вернуть набор сущностей для добавления или обновления в графе платформы разработчика. Это могут быть специфичные для провайдера или общие сущности.

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

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

Пример использования GitHub Actions или Azure Pipelines

Давайте кратко рассмотрим, как будет работать GitHub Actions или Azure Pipelines в качестве поставщика платформы разработчика.

Для GitHub Actions важность заключается в том, что поставщик платформы для разработчиков может подключиться к указанному экземпляру GitHub и использовать Actions REST API для инициирования события запуска рабочего процесса. Каждый рабочий процесс может поддерживать набор входных данных, добавив конфигурацию workflow_dispatch в файл YAML рабочего процесса. Триггеры Azure DevOps аналогичны, и вы также можете использовать API Конвейера Azure DevOps для выполнения. Скорее всего, вы увидите те же возможности в других продуктах.

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

• Инженеры платформы или члены команды DevOps могут поддерживать рабочие процессы и конвейеры в одной или нескольких центральных репозиториях, к которым сами разработчики не имеют доступа, но поставщик платформы разработчика настроен для использования. Этот же репозиторий может включать скрипты и фрагменты кода IaC, используемые рабочими процессами или конвейерами.
• Чтобы разрешить этим рабочим процессам или конвейерам взаимодействовать с соответствующей подчиненной системой, ops или другими членами команды разработчиков платформы, можно добавить необходимые секреты в центральное репозиторие. Дополнительные сведения о том, как это сделать, см. в документации по GitHub Actions и Azure DevOps , или вы можете выбрать централизацию секретов с помощью Azure Key Vault.
• Эти рабочие процессы и конвейеры затем могут следовать модели, в которой они публикуют любые полученные сущности в виде артефакта сборки или развертывания (документация GitHub, документация Azure DevOps).
• Во время выполнения поставщик платформы разработчика может отслеживать состояние рабочего процесса/конвейера и обновлять состояние жизненного цикла в оркестраторе до его завершения. Например, вы можете использовать веб-перехватчики с GitHub Actions и ресурсные перехватчики служб с Azure Pipelines для отслеживания обновлений.
• После завершения поставщик может использовать опубликованный артефакт для включения в граф платформы разработчика по мере необходимости.

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

Отличная особенность использования системы CI/CD заключается в том, что они часто настраиваются для поддержки работы произвольных CLI, поэтому вам не нужна специальная, уникальная интеграция для всего, что вы делаете. Их можно добавить по мере необходимости.

Большая часть того, что описано в этом примере, относится к тому, как другие типы поставщиков могут функционировать. Также важно отметить, что использование GitHub Actions или Azure Pipelines в этом контексте не требует их использования для фактических конвейеров CI/CD.

Другие примеры

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

Example	Description
Операции в системе управления версиями	В некоторых случаях может потребоваться создать или обновить репозиторий, отправить запрос на извлечение или выполнить другую операцию, связанную с управлением исходным кодом. Хотя общие асинхронные обработчики рабочих процессов могут управлять этими типами операций, возможность выполнять базовые операции Git без их использования может быть полезной.
Инструменты для предоставления инфраструктуры	Хотя GitHub Actions и Azure Pipelines хорошо работают для управления подготовкой инфраструктуры, вы также можете выбрать более прямую интеграцию. Выделенный поставщик может упростить настройку и избежать затрат. Службы, такие как среды развертывания Azure или Terraform Cloud, более непосредственно сосредоточены на позволении подготовки на основе шаблонов инфраструктуры как код (IaC), безопасной и надежной. Другие примеры могут включать такие вещи, как создание пространств имен Kubernetes для приложений в общих кластерах или использование Git с рабочими процессами GitOps с помощью Flux или Argo CD в качестве определенного типа поставщика. Даже более ориентированные на приложения модели, такие как экспериментальный проект инкубации Radius OSS с собственными CLI, со временем могут иметь собственных поставщиков платформ для разработчиков. Ключевое дело заключается в том, чтобы искать и планировать расширяемость, чтобы вы могли адаптироваться.
Создание шаблонов приложений и засеяние	Шаблоны приложений являются важной частью того, куда со временем движется инженерия платформы. Вы можете поддерживать выбранный движок шаблонов, предоставив поставщика платформы, выделенного для разработчиков, который предназначен не только для структурирования дерева исходного кода приложения, но и для создания и отправки содержимого в репозиторий исходного кода и добавления полученных сущностей в граф. Каждая экосистема имеет собственные предпочтения шаблонов приложений, будь то Yeoman, cookiecutter или что-то подобное интерфейсу командной строки разработчика Azure, поэтому модель поставщика здесь может позволить вам поддерживать несколько из одних интерфейсов. Здесь снова это расширяемость, которая является ключом.
Ручные процессы	Независимо от того, создается ли автоматически PR для утверждения вручную или шаги ручного рабочего процесса предназначены для того, чтобы пользователи, не являющиеся разработчиками, могли реагировать с помощью таких инструментов, как Power Platform, в платформе разработчика можно использовать ту же модель на основе шаблонов. С течением времени вы даже можете перейти к более автоматизированным шагам.

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

Пользователи и команды

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

Recommendation	Description
Интегрируйте API платформы разработчика непосредственно с поставщиком удостоверений для оптимальной безопасности.	Чтобы защитить API платформы разработчика, мы рекомендуем напрямую интегрироваться с поставщиком удостоверений, таким как Microsoft Entra ID, учитывая его надежное управление идентификацией и возможности RBAC Entra ID. Существует множество преимуществ при непосредственном использовании встроенных пакетов SDK и API поставщика удостоверений (например, через MSAL Entra ID) вместо использования абстракции. Вы можете обеспечить сквозную безопасность и полагаться на ту же модель RBAC на всем протяжении, обеспечивая непрерывную оценку политик условного доступа (а не только во время входа).
Используйте интеграцию единого входа и интеграцию с группами поставщиков удостоверений в системах последующего уровня.	Ваши интеграции единой точки входа (SSO) должны использовать того же поставщика удостоверений и клиента, которые вы используете для API платформы для разработчиков. Кроме того, не забудьте воспользоваться поддержкой любых протоколов, таких как SCIM, для интеграции с группами поставщиков удостоверений (например, группы Active Directory (AD)). По крайней мере, можно вручную связать группы поставщиков удостоверений личности с концепциями группировки каждого инструмента в подчиненных системах, без последующего ручного управления членством. Например, вы можете объединить поддержку корпоративного управляемого пользователя GitHub (Enterprise Managed User, EMU) и вручную использовать возможность связывать группы провайдеров удостоверений с командами GitHub. Azure DevOps имеет аналогичные возможности.

Создание концепции команды за пределами одной группы поставщика удостоверений

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

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

Источник данных команды может поступать из нескольких разных мест. Например, если вы используете шаблон «teams as code» (TAC), поставщик платформы для разработчиков может отслеживать изменения файлов в репозитории и кэшировать их в профиле пользователя и хранилище метаданных команды. Или вы можете интегрировать непосредственно с проектом Центра разработки Azure , который уже имеет эти основные конструкции RBAC.

Создание модели интеграции с подчиненными системами на уровне команды или пользователя

Хотя некоторые инструменты/услуги для разработчиков и операций изначально интегрируют и используют концепции поставщиков удостоверений напрямую, многие абстрагируют их в собственное представление группы или пользователя (даже с единым входом). Помимо обеспечения доступа между инструментами, эта ситуация также может создавать проблемы для агрегирования данных. В частности, вы можете обнаружить, что API в зависимой системе используют свои собственные идентификаторы, а не идентификаторы поставщика удостоверений (например, идентификатор объекта в Entra ID не используется напрямую). Это затрудняет фильтрацию и связывание данных на уровне пользователя или группы, если вы не можете сопоставить их между различными идентификаторами.

Устранение различий на уровне команд и групп.

Такие шаблоны, как TaC , позволяют хранить и получать доступ к связям между командой или группами каждой системы, чтобы можно было сопоставить их. Подводя итоги, безопасный репозиторий Git, доступный для аудита, становится источником для команды, а запросы на извлечение (PR) предоставляют управляемый пользовательский интерфейс для внесения обновлений. После этого системы CI/CD могут обновлять подчиненные системы и сохранять связанные связи идентификаторов для команды, которая использовалась для этого.

Например, это позволяет хранить следующие связи в вызовах API:

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

Устранение проблем с идентификатором пользователя

Еще одной связанной проблемой для доступа к данным и агрегирования является различия идентификаторов пользователей. Как и в случае команды, если вы используете интеграцию системы с системой для запроса данных о пользователе, вы не можете предположить, что собственный идентификатор поставщиков удостоверений (например, идентификатор объекта для Entra ID) поддерживает любой API. Здесь еще раз хранение сопоставления для идентификатора пользователя, который обращается к данным через API платформы разработчика, может помочь. Например, рассмотрим GitHub:

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

Обратитесь к использованию нескольких пользовательских токенов

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

• API платформы разработчика может поддерживать кэш пользовательских токенов, специфичных для поставщика, для использования с нисходящими системами.
• Любые взаимодействия с заданным поставщиком, инициируемым API, будут включаться в маркер пользователя поставщика, если он доступен.
• Чтобы справиться с ситуацией, когда маркер пользователя не был доступен, поставщик активирует поток OAuth, чтобы получить его.
• Для начала API платформы разработчика будет возвращать обратно URI для проверки подлинности в рамках потока OAuth вместе с URI перенаправления, который был передан поставщику. Переданный URI будет включать одноразовый код.
• Затем API возвращает не прошедший проверку подлинности ответ с помощью URI.
• Затем любой ПОЛЬЗОВАТЕЛЬСКИЙ интерфейс может использовать этот универсальный код ресурса (URI) для надлежащего потока проверки подлинности в браузере.
• После перенаправления платформа разработчика получит необходимый маркер пользователя и кэширует его для последующей ссылки вместе с идентификатором пользователя.
• Затем клиент может повторить вызов API, который затем завершится успешно.

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

Используйте контекстно-зависимые гиперссылки на инструменты и системы отчетности

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

Даже если это не связано с автоматизацией, поставщики платформ разработчиков могут генерировать любые необходимые сущности. Однако в целом вы, вероятно, не хотите переносить все подробные данные со всей вашей внутренней платформы разработчиков в граф вашей платформы разработчика. Панели мониторинга в решениях для наблюдения, таких как Grafana, Prometheus, DataDog, аналитика кода в продуктах, таких как SonarQube, а также встроенные функции в наборах DevOps, таких как GitHub и Azure DevOps, обладают всеми необходимыми возможностями. Вместо этого лучше всего создавать глубокие связи с этими другими системами. Ваши сущности могут предоставлять достаточно информации для создания ссылок без необходимости содержать подробные данные, такие как содержимое журналов.

В случаях, когда требуется агрегировать и суммировать данные в разных инструментах или требуется использовать пользовательские метрики, решения отчетов Power BI или Microsoft Fabric могут быть следующим портом вызова. Чтобы объединить данные группы, можно подключиться к базе данных фонда или перейти через API платформы разработчиков. Например, как описано в Планирование и приоритезация, одной из областей, где может потребоваться пользовательская панель мониторинга, является измерение успеха вашей внутренней платформы для разработчиков.

Будьте разборчивы с каждым дополнительным опытом, который вы создаёте

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

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

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

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

Ниже приведены некоторые примеры распространенных возможностей, которые следует рассмотреть.

Example	Description
Обнаружение и исследование	Как говорит один специалист по проектированию платформы, "Что замедляет проекты коммуникации, а не навыки разработчика". - Даниэль, облачный инженер, Fortune 500 Media Company. Поскольку разработка программного обеспечения — командная деятельность, создание пользовательского интерфейса для обнаружения команд и сущностей, которыми они владеют, как правило, является одной из первых задач, которые нужно решить. Кросс-командный поиск, обнаружение и документация помогают повысить повторное использование и помощь в совместной работе для внутреннего обеспечения или поддержки. Команды также извлекают выгоду из единого центра для поиска принадлежащих им ресурсов, включая среды, репозитории и другие ресурсы, такие как документация.
Регистрация сред или ресурсов вручную	Хотя многие вещи можно подготовить и отслеживать с помощью оркестратора платформы разработчиков, вы также можете зарегистрировать ресурсы или среды, которые уже существуют или еще не автоматизированы. Простой поставщик, который принимает информацию из репозитория Git и добавляет сведения в ресурсы или управление средой, может быть полезным здесь. Если у вас уже есть каталог программного обеспечения, он также становится способом интеграции его в модель.
Каталог API	Отслеживание API-интерфейсов, которые разработчики должны использовать, может быть очень полезным. Если у вас еще нет ничего, вы можете даже начать с простого репозитория Git с рядом файлов, представляющих API, их состояние, используйте PRs для управления рабочим процессом утверждения. Их можно добавить в граф платформы разработчика, чтобы их можно было отображать или связывать с другими сущностями. Для более надежных возможностей можно интегрировать что-то подобное Центру API Майкрософт или другому продукту.
Контроль наличия лицензий	В некоторых случаях также может потребоваться обеспечить видимость соответствия лицензий программного обеспечения и потребления лицензий. Платформы разработчиков также могут добавлять автоматизацию, необходимую для использования лицензий, но даже если лицензии назначаются вручную (например, через процесс Pull Request (PR) в репозитории Git), разработчики могут иметь видимость того, что у них есть, а администраторы могут видеть всё в совокупности.
Представление Kubernetes с акцентом на приложение	При использовании общего кластера Kubernetes разработчикам может быть трудно найти и понять состояние своих приложений с помощью пользовательского интерфейса администратора кластера. Различные организации могут по-разному обрабатывать эту проблему, но использование пространства имен для представления приложения является одним из известных способов этого. Оттуда можно использовать сущности для установления связей между пространством имен приложения в кластере и командой, а также создавать более ориентированное на разработчика представление о состоянии приложения и предоставлять глубокие ссылки на другие инструменты или веб-интерфейсы UIs.

Взаимодействие с пользователями

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

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

Интеграция того, что у вас есть

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

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

Например, вы можете расширить следующие области, которые вы уже используете:

• Редакторы и среды разработки
• Ваш набор DevOps
• CLI становятся более расширяемыми
• Среды с низким или отсутствующим кодом, такие как Power Pages

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

Рассмотрим расширения веб-редактора для создания портала разработчика

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

Помимо таких служб, как GitHub Codespaces, vscode.dev является бесплатной веб-версией редактора VS Code без вычислений, но включает поддержку определенных типов расширений , включая те, которые используют веб-представления для пользовательского пользовательского интерфейса.

Даже если разработчики не используют сам VS Code, пользовательский интерфейс хорошо известен и можно найти в других средствах разработчика. С помощью vscode.dev можно предоставить удобный и знакомый веб-интерфейс для разработчиков в дополнение к самому инструменту.

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

ChatOps

Еще одна возможность, которая часто упускается из виду, — внедрение интерфейса ChatOps. Учитывая увеличение интерфейсов на основе чата из-за роста продуктов искусственного интеллекта, таких как ChatGPT и GitHub Copilot, команды действий или команды косой черты , могут обеспечить полезный способ активации рабочих процессов автоматизации, проверки состояния и т. д. Учитывая, что большинство платформ CI/CD приложений предоставляют встроенную поддержку таких систем, как Microsoft Teams, Slack или Discord, это может быть естественным способом интеграции с интерфейсами, которые разработчики и операционные роли используют каждый день. Кроме того, все эти продукты имеют модель расширяемости.

Инвестиции на новый портал разработчика

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

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

Более современные усилия по созданию портала для разработчиков приобретают больше определенности в своих подходах. Например, Backstage.io — это пользовательский набор средств портала разработчика, изначально созданный для удовлетворения потребностей Spotify. Он включает интерфейс командной строки, который помогает настроить дерево исходного кода, так же, как create-react-app для React.js.

В качестве инструментального набора для портала требуется работа для настройки и адаптации, а также знание TypeScript, Node.js и React. Тем не менее, главное преимущество заключается в том, что, как набор инструментов, вы можете изменить почти всё. Он также имеет собственный каталог программного обеспечения и механизм шаблонов, но их использование не требуется, и это четко определенный способ ввести новый код, называемый плагинами.

Связанный контент

• Microsoft Power Pages
• Backstage.io
• Применение систем проектирования программного обеспечения