Разработка основы самообслуживания разработчика
Получив хорошее представление о целевом объекте для инженерных систем, вы можете создать более сложные возможности самообслуживания разработчиков. Самообслуживание разработчика основано на основах концепций, шаблонов и компонентов.
Хотя вам может не потребоваться все, что описано здесь в вашей организации сегодня, следует учитывать эти понятия, если вы создаете что-то пользовательское или оцениваете связанные продукты. Модель самообслуживания разработчика может быть состоит из сочетания домашних продуктов, вне полки и продуктов с открытым кодом. Продукты или наборы средств портала с открытым кодом, такие как Backstage.io , могут использовать различные термины для некоторых элементов модели, описанных ниже, но модель по-прежнему может помочь вам сориентироваться.
Автоматизация рабочих процессов, агрегатных данных, запуск простых и постепенное развертывание
Ваша цель заключается в том, чтобы обеспечить самообслуживание с помощью контролируемых, управляемых задач выполнения и подготовки, а также централизованной видимости. Области, которые являются наиболее ценными для фокуса, являются те, которые либо мучены, либо являются тем, что разработчик не может сделать самостоятельно из-за сложности или разрешений. Этот последний фрагмент важен, чтобы вы могли следовать принципу наименьших привилегий, не заставляя разработчиков выполнять процесс службы вручную.
Хотя вы можете расширить набор DevOps в соответствии с этими потребностями, вам, скорее всего, потребуется поддерживать несколько платформ приложений с течением времени, а также конкретные инструменты и процессы, которые поддерживают их, также потребуется изменить. Основная проблема заключается в том, что ваши стандарты являются движущимся целевым объектом. Как заявил один специалист по проектированию платформы:
Трудности включают стандартизацию ... и иметь дело с "заброшенным" ... Стандартизация часто не достигается из-за потенциальных нарушений автоматизированных процессов и потребляющей времени задачи выявления необходимых изменений. - Мартин, инженер DevOps, крупная логистическая компания
Быстрое переключение на новый или обновленный стандарт, как правило, невозможно, и отказ от существующих процессов создает риск. Ваша организация уже может использовать несколько наборов DevOps или различные сочетания отдельных средств и служб разработчиков по сценариям. Даже с центральной командой и стандартным решением, так как ваше самообслуживание нуждается в увеличении, переменность неизбежно. Таким образом, вы хотите включить управляемое экспериментирование, где назначенные команды могут попробовать новые технологии, стратегии развертывания и т. д., а затем преднамеренное внедрение и добавочное развертывание.
Как правило, возможности самообслуживания делятся на две основные категории: автоматизация и агрегирование данных.
Хотя агрегирование данных создает хороший интерфейс пользователя, автоматизация важнее:
Автоматизация является ключом и будет любима всеми. Агрегирование [data] является вторичным. – Питер, руководитель разработки платформы, многонациональная компания Tech
В пути разработки платформы вы определили проблемы, которые потенциально решаются автоматизацией. Помимо снижения когнитивной нагрузки и нагрузки разработчика, автоматизация также может помочь обеспечить подключение приложений к лучшим средствам и службам для операций, безопасности и других ролей для выполнения их работы.
Однако если вы работаете с несколькими системами для управления автоматизацией, некоторый уровень агрегирования данных полезен для отслеживания автоматических запросов и связанных результатов. Для начала можно связаться с внешними системами в соответствии с другими потребностями или подробными сведениями о детализации. Агрегирование и видимость данных также важно для аудита, управления и уменьшения отходов (например, неиспользуемых сред).
Автоматизация таких действий, как подготовка инфраструктуры, может быть выполнена с помощью системных интеграции, но вы также можете активировать и упростить процесс ручного рабочего процесса, который выглядит автоматизированным для разработчика. Это полезно на ранних этапах платформы, для новых продуктов, которые вы приносите в экосистему, или в тех областях, которые вы не сделали или не можете автоматизировать использование системы (например, назначение лицензий на программное обеспечение). При правильном проектировании можно начать с ручного процесса, облегчаемого таким образом, как Power Automate, переключение на полностью автоматизированный поток с течением времени. Таким образом, проектирование для автоматизации с самого начала.
Начните с простого использования существующих инвестиций, таких как ваши инженерные системы или внутренний портал, а затем создайте интерфейсы CLIs, базовые веб-страницы или даже Power Pages, Power BI или панели мониторинга Microsoft Fabric , а также расширение по мере возникновения необходимости. Благодаря согласованному ИНТЕРФЕЙСу API, который затем используется, вы можете поддерживать несколько интерфейсов по мере изменения потребностей и настроек.
Компоненты платформы самообслуживания разработчика: API, граф, оркестратор, поставщики и метаданные
Рассмотрим основы самообслуживания разработчика:
Как показано на рисунке, следующие компоненты составляют основу концепции самостоятельного фонда разработчика:
| Компонент | Description |
|---|---|
| API платформы разработчика | Это ваша единственная точка контакта для взаимодействия с пользователем. Это фактически контракт системы с другими системами. |
| Граф платформы разработчика | Управляемый и безопасный граф данных, позволяющий обнаруживать, связывать и использовать различные виды сущностей и шаблонов. Сущность — это объект, который позволяет агрегирование данных из нескольких источников, а шаблоны управляют входными данными пользователей, которые обеспечивают автоматизацию. |
| Оркестратор платформы разработчика | Возможность маршрутизации и отслеживания запросов на основе шаблонов для выполнения действий в системе или вручную. Эти запросы направляются в один из наборов поставщиков платформ разработчиков, которые могут интегрироваться в любое количество различных систем рабочих процессов или других служб. |
| Поставщики платформы разработчиков | Набор компонентов, которые инкапсулируют логику, необходимую для интеграции с подчиненными системами для поддержки операций CRUD в сущностях и /или выполнении запросов на основе шаблонов. Каждый поставщик может поддерживать собственный тип шаблонов и выдавать уникальные или распространенные типы сущностей. |
| Профиль пользователя и метаданные группы | Возможность сохранять сведения о наборе лиц, привязанных к концептуальной команде для группировки и доступа к API платформы разработчиков. Пользователь тесно связан с учетной записью поставщика удостоверений (например, вход в Систему Microsoft Entra ID), но и она, и команда могут связать любое количество связанных подчиненных системных представлений. Одной из реализаций этого хранилища данных является повторное использование графа платформы разработчика. Фонд самообслуживания разработчика может установить общий тип сущности как для пользователя, так и для команды, и сохранить эти сведения в графе. Тем не менее, мы будем хранить этот магазин отдельно для ясности здесь. |
Эти базовые компоненты позволяют использовать и переключать различные стандартные блоки с течением времени.
Нужно ли создавать все это, чтобы приступить к работе?
№ Во-первых, это концептуальная модель, чтобы помочь вам подумать, что фундамент, как это должно быть в состоянии сделать после этого. Во-вторых, особенности реализации менее важны, учитывая, что API платформы разработчика становится ключевым интерфейсом. Начальная реализация может начать использовать интерфейсы и классы в коде для различных слоев, описанных или смешанных в других продуктах. Вы также можете опустить аспекты, так как разработка клиентов сообщает вам, что это просто более низкий приоритет. Начните с того, что у вас есть и расти.
API платформы разработчика
Вы должны определить API платформы разработчика, чтобы выступать в качестве контракта вашей системы. API используется различными пользовательскими интерфейсами для включения доступа к данным или подготовки дисков и других действий.
Этот API выступает в качестве важного уровня проверки подлинности и безопасности путем ограничения доступа к необработанным базовым API в других системах более конкретным, контролируемым данными и операциями. API предоставляет доступ к собственному представлению профиля пользователя, высокоуровневой роли пользователя в платформе (член группы, администратор и т. д.), а также к основным идентификаторам системы поставщика удостоверений. Дополнительные сведения см. в разделе "Пользователи и команды".
Поставщики платформы разработчиков
Учитывая широту внутренней платформы разработчика, создайте или определите системы, которые следуют модели расширяемого поставщика, чтобы внедрить функциональные возможности в API. Идея заключается в том, что ключевые функции, такие как автоматизация и агрегирование данных, обеспечиваются взаимодействием с подключаемыми компонентами с хорошо определенными интерфейсами. Это свободное подключение помогает вам подключиться к тому, что вам нужно добавочно и повышает удобство обслуживания, так как вы можете протестировать функциональные возможности независимо от остальной части основы.
Это также важный способ включить масштабируемую внутреннюю менталитет источника для вашей платформы. Как правило, внутренние усилия по разработке платформы не могут получить тяги из-за проблем с текущим обслуживанием. Другие команды могут быть готовы внести свой вклад в функциональные возможности, но, скорее всего, будут готовы поддерживать и тестировать что-то внутри ядра вашей платформы. И наоборот, любая централизованная команда имеет ограниченную емкость для поддержания кода или даже проверки запросов на вытягивание. Концепция поставщика платформы разработчика облегчает эту напряженность, позволяя независимо написанному коду "подключаться" к основным функциям в рамках самостоятельной платформы разработчика. Хотя вы должны тщательно управлять используемыми поставщиками, просматривать любой код поставщика и ограничивать область поверхности, доступ к которой данный поставщик может получить в вашей платформе разработчика, подключаемый подход может помочь вам сделать больше, масштабируя усилия в более широкой части организации.
Основные понятия поставщика платформы разработчика
Сущности
Концепция сущности — это то, что разработчик или другая система на внутренней платформе разработчика должна отслеживать, обновлять, представлять или действовать. Сущности могут иметь связи друг с другом, которые при объединениях составляют граф , предоставляющий критически важные сведения о фрагментах внутренней платформы разработчика. Затем поставщики платформы разработчиков могут выводить сущности для включения основных возможностей, в том числе:
- Поиск внешних подготовленных ресурсов или сред или доступных API для обнаружения и использования
- Предоставление связей для анализа зависимостей, анализа влияния, обнаружения и т. д.
- Поиск сведений о поддержке и владельцах для обнаружения и совместной работы
- Поиск дополнительных данных для использования в пользовательском интерфейсе
Инкапсулируя эту функцию в четко определенный интерфейс поставщика платформы разработчиков, упрощает интеграцию и тестирование, обеспечивает независимое развертывание и позволяет разработчикам за пределами основной внутренней группы платформы разработчиков участвовать и управлять поставщиками. Это важно в крупных или отделальных организациях, где не каждый инструмент, служба или платформа управляются централизованно, но более широкая организация по-прежнему хочет совместно использовать возможности. Таким образом, даже если вы не возглавляете этот путь изначально, это что-то думать о долгосрочной перспективе.
Общие свойства
Каждая сущность должна иметь набор общих свойств, чтобы разрешить Фонду управлять ими. Некоторые свойства, которые следует учитывать, включают:
- Уникальный идентификатор
- Имя.
- Исходный поставщик
- Необязательные связи:
- владельца
- Команда владельцев
- Другие объекты
Свойства пользователя и команды важны по трем причинам: управление доступом на основе ролей (RBAC), обнаружение и агрегирование данных (например, сводки на уровне команды). Создание в RBAC с самого начала крайне важно для безопасности и роста внутренней платформы разработчика с течением времени. Учитывая развитие является командным спортом, обнаружив, кто говорить с сущностью быстро станет критически важной для повторного использования, поддержки и внутренних источников.
Общие и поставщики конкретных сущностей
Вы также можете установить набор общих высокоуровневых нормализованных сущностей, которые могут выводить несколько поставщиков. Например:
- Среды
- Ресурсы
- Программные интерфейсы
- Репозитории
- Компоненты
- Инструменты
Как правило, они должны находиться на высоком уровне, например, в контексте модели C4 или на наиболее высоких схемах компонентов. Например, для среды вам не нужно включать сведения о топологии внутренней инфраструктуры: вам просто нужна достаточная информация для перечисления и связывания различных концептуальных сред из нескольких поставщиков в одном пользовательском интерфейсе. Сущность может указывать на более низкие уровни детализации вне системы, а не пытаться использовать все. Они предоставляют начальные точки для обнаружения, которые являются центральными для включения агрегирования данных с течением времени.
Другие будут характерны для конкретного варианта использования или поставщика, поэтому вы должны подумать о том, как можно разместить растущий набор типов сущностей с течением времени.
Шаблоны
Концепция шаблона в этом контексте отличается от идеи сущностей в том, что они предназначены для выполнения действия. Примеры сценариев включают подготовку инфраструктуры, создание репозитория и другие длительные процессы. Эти шаблоны также должны быть доступны через расширяемых поставщиков платформы разработчиков и должны поддерживать те же общие свойства, что и сущности, включая ассоциации сущностей.
Однако они также могут определять необходимые входные данные, указанные системой или пользователем, которые необходимы для выполнения действия. Они могут варьироваться от именования ресурса до необязательных дополнений.
Примеры шаблонов:
- Шаблоны infrastructure-as-code (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 и использовать REST API Actions для запуска рабочего процесса события отправки рабочего процесса. Каждый рабочий процесс может поддерживать набор входных данных, добавив конфигурацию 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 заключается в том, что они часто настраиваются для поддержки произвольных clIs, поэтому вам не нужен первый класс, уникальная интеграция для всего, что вы делаете. Их можно добавить по мере необходимости.
Большая часть того, что описано в этом примере, применяется к тому, как могут функционировать другие типы поставщиков. Также важно отметить, что использование GitHub Actions или Azure Pipelines в этом контексте не требует их использования для фактических конвейеров CI/CD.
Другие примеры
Ниже приведены некоторые примеры других типов поставщиков платформ разработчиков, которые могут обрабатывать шаблоны.
| Пример | Description |
|---|---|
| Операции управления версиями | В некоторых случаях может потребоваться создать или обновить репозиторий, отправить PR или выполнить другую другую операцию управления версиями. Хотя общие асинхронные обработчики рабочих процессов могут управлять этими типами операций, что позволяет выполнять базовые операции Git без использования. |
| Средства подготовки инфраструктуры | Хотя GitHub Actions и Azure Pipelines хорошо работают для управления подготовкой инфраструктуры, вы также можете выбрать более прямую интеграцию. Выделенный поставщик может упростить настройку и избежать затрат. Службы, такие как среды развертывания Azure или Terraform Cloud , более непосредственно сосредоточены на включении подготовки на основе шаблонов IaC и безопасной и безопасной. Другие примеры могут включать такие вещи, как создание пространств имен Kubernetes для приложений в общих кластерах или использование git с рабочими процессами GitOps с помощью Flux или Argo CD в качестве определенного типа поставщика. Даже более ориентированные на приложения модели, такие как экспериментальный проект инкубации Radius OSS с собственными clIs, могут иметь собственные поставщики платформ разработчиков со временем. Ключевое дело заключается в том, чтобы искать и планировать расширяемость, чтобы вы могли адаптироваться. |
| Создание шаблонов приложений и засеяние | Шаблоны приложений являются важной частью того, где со временем ведет проектирование платформы. Вы можете поддерживать выбранный обработчик шаблонов, предоставив выделенному поставщику платформы разработчика, который предназначен не только для формирования шаблона исходного дерева приложения, но и создания и отправки содержимого в репозиторий исходного кода и добавления результирующей сущности в граф. Каждая экосистема имеет собственные предпочтения шаблонов приложений, будь то Yeoman, cookiecutter или что-то подобное интерфейсу командной строки разработчика Azure, поэтому модель поставщика здесь может позволить вам поддерживать несколько из одних интерфейсов. Здесь снова это расширяемость, которая является ключом. |
| Ручные процессы | Независимо от того, будет ли автоматически создаваться запросы на утверждение вручную или вручную для пользователей, не являющихся разработчиками, реагировать на использование такой модели, как Power Platform, в поставщике платформы разработчиков можно использовать ту же модель на основе шаблонов. С течением времени вы даже можете перейти к более автоматизированным шагам. |
Несмотря на то, что вам может потребоваться не все эти поставщики, вы можете увидеть, как расширяемость с помощью поставщика платформы разработчика может помочь в росте возможностей автоматизации с течением времени.
Пользователи и команды
Проектирование платформы, по сути, является многосистемным делом, поэтому важно спланировать, как самослужебная основа должна справиться с более сложными проблемами при интеграции этих систем вместе. Ниже приведена стратегия решения распространенных проблем с удостоверениями, пользователями и командами.
| Рекомендация | Description |
|---|---|
| Интеграция API платформы разработчика непосредственно с поставщиком удостоверений для оптимальной безопасности | Чтобы защитить API платформы разработчика, мы рекомендуем напрямую интегрироваться с поставщиком удостоверений, таким как Идентификатор Microsoft Entra, учитывая его надежные возможности управления доступом на основе ролей (RBAC). Существует множество преимуществ непосредственно с помощью собственных пакетов SDK и API поставщика удостоверений (например, через идентификатор MSAL Entra) вместо абстракции. Вы можете обеспечить сквозную безопасность и полагаться на ту же модель RBAC на протяжении всего времени, обеспечивая непрерывное вычисление политик условного доступа (а не только во время входа). |
| Использование интеграции групп поставщиков удостоверений и единого входа в подчиненных системах | Интеграция единого входа должна использовать тот же поставщик удостоверений и клиент, который вы используете для API платформы разработчика. Кроме того, не забудьте воспользоваться поддержкой любых протоколов, таких как SCIM для провода в группах поставщиков удостоверений (например, группы AD). Связывание этих групп поставщиков удостоверений в подчиненные системные разрешения не всегда является автоматическим, но как минимум, вы можете вручную связать группы поставщиков с концепциями группирования каждого средства без ручного управления членством. Например, вы можете объединить поддержку корпоративного пользователя GitHub (EMU) и вручную использовать возможность связать группы поставщиков удостоверений с командами GitHub. Azure DevOps имеет аналогичные возможности. |
Создание концепции команды за пределами одной группы поставщика удостоверений
По мере продолжения разработки платформы вы, скорее всего, обнаружите, что группы поставщиков удостоверений отлично подходят для управления членством, но несколько групп действительно должны объединиться, чтобы сформировать концепцию команды для управления доступом на основе ролей (RBAC) и агрегирования данных.
В контексте проектирования платформы мы определяем команду как набор людей в разных ролях, которые работают вместе. Для агрегирования данных идея группы с несколькими ролями важна для обнаружения питания и свертки информации в таких местах, как панели мониторинга отчетов. С другой стороны, группа является общей концепцией поставщика удостоверений для набора пользователей и разработана с идеей добавления нескольких пользователей в определенную роль, а не наоборот. Благодаря RBAC команда может связаться с несколькими группами поставщиков удостоверений с помощью разных ролей.
Источник данных команды может поступать из нескольких разных мест. Например, если вы используете команды в качестве шаблона кода (TaC), поставщик платформы разработчика может отслеживать изменения файлов в репозитории и кэшировать их в профиле пользователя и хранилище метаданных команды. Кроме того, вы можете интегрироваться непосредственно с проектом Azure Центр разработки, который уже имеет эти основные конструкции RBAC.
Создание модели интеграции с подчиненными системами на уровне команды или пользователя
Хотя некоторые средства разработчика и операционные инструменты и службы изначально интегрируются и используют концепции поставщика удостоверений напрямую, многие абстрагируют это в собственное представление группы или пользователя (даже с единым входом). Помимо включения доступа между инструментами, эта реальность также может представлять проблемы для агрегирования данных. В частности, можно найти, что API в нижней системе используют собственные идентификаторы, а не идентификаторы поставщика удостоверений (например, идентификатор объекта в идентификаторе Entra ID не используется напрямую). Это затрудняет фильтрацию и связывание данных на уровне пользователя или группы, если вы не можете сопоставить их между различными идентификаторами.
Различия между группами и группами
Такие шаблоны, как TaC , позволяют хранить и получать доступ к связям между командой или группами каждой системы, чтобы можно было сопоставить их. Чтобы вернуться, безопасный репозиторий Git, доступный для аудита, становится источником команды, и PR предоставляют управляемый пользовательский интерфейс для внесения обновлений. После этого системы CI/CD могут обновлять подчиненные системы и сохранять связанные связи идентификаторов для команды, которая использовалась для этого.
Например, это позволяет хранить следующие связи в вызовах API:
Если вы предпочитаете использовать источник данных, отличный от файлов в репозитории, то это же общее понятие можно применить с помощью оркестратора платформы разработчика для выполнения той же задачи. В рамках этой модели поставщик платформы разработчика для источника данных команды может активировать событие обновления команды, которое получают все остальные поставщики и действуют соответствующим образом.
Устранение проблем с идентификатором пользователя
Еще одной связанной проблемой для доступа к данным и агрегирования является различия идентификаторов пользователей. Как и в случае команды, если вы используете интеграцию системы с системой для запроса данных о пользователе, вы не можете предположить, что собственный идентификатор поставщиков удостоверений (например, идентификатор объекта для идентификатора записи) поддерживает данный 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 могут быть следующим портом вызова. Чтобы объединить данные группы, можно подключиться к базе данных Foundation или перейти через API платформы разработчиков. Например, как описано в разделе "Планирование и приоритет", одно место, где может потребоваться пользовательская панель мониторинга, измеряет успех внутренней платформы разработчика.
Выборка с каждым дополнительным интерфейсом, который вы создаете
Хотя это может быть привлекательно для повторного создания существующих возможностей в чем-то подобном общем портале, имейте в виду, что вам также потребуется сохранить его. Это область, в которой важно следующее за мышлением продукта. Интерфейсы стилей панели мониторинга легко представить и понять, но разработчики могут найти больше ценности в другом месте.
Тем не более чем модель здесь позволяет использовать агрегированные данные на графе платформы разработчика для создания пользовательских возможностей. Сущности должны иметь встроенную поддержку, чтобы они могли связаться с пользователем или командой. Это позволяет API платформы разработчиков применять выходные данные (а также использовать индексирование и кэширование).
Однако даже если вам нужно создать пользовательский интерфейс, а не глубокую связь, извлечение всех данных на граф платформы разработчика обычно не является лучшим подходом. Например, рассмотрим ситуацию, в которой может потребоваться отобразить журналы в пользовательском интерфейсе, у которого уже есть хорошо определенный и управляемый дом. Используйте сведения в связанных сущностях, чтобы помочь пользовательскому интерфейсу собирать сведения непосредственно из подчиненных систем.
Чтобы приступить к подключению, может потребоваться использовать интеграцию между системами, но после реализации одной из моделей, описанных в пользователях и командах, при необходимости можно использовать любые сохраненные нижестоящие идентификаторы пользователей или команд или маркеры проверки подлинности пользователей.
Ниже приведены некоторые примеры распространенных возможностей, которые следует рассмотреть.
| Пример | Description |
|---|---|
| Обнаружение и исследование | Как говорит один специалист по проектированию платформы, "Что замедляет проекты коммуникации, а не навыки разработчика". - Даниэль, облачный инженер, Fortune 500 Media Company. Так как программное обеспечение является командным спортом, создание пользовательского интерфейса для обнаружения команд, и сущности, которыми они владеет, как правило, являются одним из первых вещей для решения. Кросс-командный поиск, обнаружение и документация помогают повысить повторное использование и помощь в совместной работе для внутреннего обеспечения или поддержки. Teams также извлекает выгоду из одного магазина, чтобы найти вещи, которые они имеют, включая среды, репозитории и другие ресурсы, такие как документация. |
| Регистрация сред или ресурсов вручную | Хотя многие вещи можно подготовить и отслеживать с помощью оркестратора платформы разработчиков, вы также можете зарегистрировать ресурсы или среды, которые уже существуют или еще не автоматизированы. Простой поставщик, который принимает информацию из репозитория Git и добавляет сведения в ресурсы или управление средой, может быть полезным здесь. Если у вас уже есть каталог программного обеспечения, он также становится способом интеграции его в модель. |
| Каталог API | Отслеживание API-интерфейсов, которые разработчики должны использовать, могут пройти долгий путь. Если у вас еще нет ничего, вы можете даже начать с простого репозитория Git с рядом файлов, представляющих API, их состояние, используйте PRs для управления рабочим процессом утверждения. Их можно добавить в граф платформы разработчика, чтобы их можно было отображать или связывать с другими сущностями. Для более надежных возможностей можно интегрировать что-то подобное Центру API Майкрософт или другому продукту. |
| Соответствие лицензий | В некоторых случаях также может потребоваться обеспечить видимость соответствия лицензий программного обеспечения и потребления лицензий. Платформы разработчиков также могут добавлять автоматизацию, необходимую для использования лицензий, но даже если лицензии назначаются вручную (например, с помощью процесса pr в репозитории Git), разработчик может узнать о том, что у них есть (и возможность администратора видеть все). |
| Ориентированное на приложение представление Kubernetes | При использовании общего кластера Kubernetes разработчикам может быть трудно найти и понять состояние своих приложений с помощью пользовательского интерфейса администратора кластера. Различные организации могут по-разному обрабатывать эту проблему, но использование пространства имен для представления приложения является одним из известных способов этого. Оттуда можно использовать сущности для установления связей между пространством имен приложения в кластере и командой, а также создавать более ориентированное на разработчика представление о состоянии приложения и предоставлять глубокие ссылки на другие инструменты или веб-интерфейсы UIs. |
Возможности для пользователя
Различные роли в организации имеют инструменты или службы, представляющие центр тяжести для повседневной работы. Вытягивание этих систем может сделать его трудным для новых пользовательских возможностей за пределами этих центров тяжести, чтобы получить тяги. В идеальном мире разработчики, операции и другие роли могут продолжать работать в среде, которая имеет смысл для них - часто те, которые они уже используют.
Учитывая это, планирование нескольких пользовательских интерфейсов по мере прогресса в разработке платформы является хорошей идеей. Это также может предоставить возможность начать простой, доказать значение и увеличиться в сторону более сложных интерфейсов по мере возникновения необходимости.
Интеграция того, что у вас есть
Если вы прочитали статьи о применении программных систем и статьях о платформах приложений, скорее всего, вы определили системы, которые вы хотите продолжать использовать. В любом случае оцените, можете ли вы улучшить и расширить то, что у вас есть, прежде чем приступить к созданию новых возможностей с нуля. (Спросите себя, будут ли люди реагировать лучше на другой новый интерфейс пользователя или улучшенную версию того, что у них сейчас?)
Некоторые инструменты, служебные программы или веб-приложения, которые вы хотите продолжить использовать, будут настраиваемыми, и это хорошие кандидаты на улучшение. Но не забудьте обратить внимание на то, есть ли у ваших любимых инструментов и служб модель расширяемости, которую можно использовать. Вы получите много преимуществ от начала там. Это может устранить проблемы обслуживания и безопасности и позволит вам сосредоточиться на проблеме, которую вы пытаетесь решить
Например, вы можете расширить следующие области, которые вы уже используете:
- Редакторы и идентификаторы.
- Набор DevOps.
- CLIs все чаще расширяемы.
- Среды с низким уровнем кода или нет кода, такие как 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, это может быть естественным способом интеграции с другими разработчиками пользовательского интерфейса и связанными ролями операций, которые используются каждый день. Кроме того, все эти продукты имеют модель расширяемости.
Инвестиции на новый портал разработчика
Если у вас нет существующего портала или интерфейса, который вы хотите использовать в качестве базы, вы можете выбрать новый портал разработчика. Подумайте об этом как о назначении, а не о начальной точке. Если у вас еще нет команды разработчиков, работая с вами, это время, чтобы сделать это. Каждая организация отличается, поэтому нет единого ответа на то, что должно быть в таком опыте. В результате нет ответа defacto для предварительно упаковаемого продукта, который вы можете вращать и использовать как есть для чего-то подобного сегодня.
Для пользовательских встроенных локальных параметров общие платформы веб-портала не являются новыми, и команды разработчиков уже могут использовать один из них. Если вы пытаетесь получить что-то перед пользователями для ранних отзывов, вы можете даже начать с чего-то так просто, как низкокодовые Power Pages для подключения к общему API платформы разработчика.
Более последние усилия на портале разработчика более мнения. Например, Backstage.io — это пользовательский набор средств портала разработчика, изначально созданный для удовлетворения потребностей Spotify. Он включает интерфейс командной строки для загрузки исходного дерева так же, как create-react-app для React.js.
В качестве набора средств на портале требуется работа, чтобы получить и настроить, требуется знание TypeScript, Node.js и React. Тем не менее, большая вещь об этом заключается в том, что, как набор средств, вы можете изменить почти что-нибудь. Он также имеет собственный каталог программного обеспечения и механизм шаблонов, но их использование не требуется, и он имеет четко определенный способ принести новый 1-й и 3-й сторонний код, называемый подключаемыми модулями.