Diseño de una base de autoservicio para desarrolladores

Una vez que tenga una buena comprensión de su destino para sus sistemas de ingeniería, puede crear experiencias de autoservicio de desarrollador más sofisticadas. Una experiencia de autoservicio para desarrolladores se basa en conceptos, patrones y componentes.

Aunque es posible que no necesite todo lo descrito aquí en su organización hoy en día, debe tener en cuenta estos conceptos si crea algo personalizado o evalúa productos relacionados. El modelo de experiencia de autoservicio del desarrollador se puede componer de una combinación de productos caseros, de fuera de la estantería y de código abierto. Los productos o los kits de herramientas del portal de código abierto, como Backstage.io , pueden usar términos diferentes para algunos elementos del modelo descritos aquí, pero el modelo todavía puede ayudarle a orientarse.

Automatización de flujos de trabajo, datos agregados, inicio sencillo y expansión gradual

El objetivo es habilitar el autoservicio con barreras de seguridad a través de la ejecución y el aprovisionamiento de tareas controladas y gobernadas, junto con la visibilidad centralizada. Las áreas que son las más valiosas para centrarse son aquellas que son tediosas o son cosas que el desarrollador no puede hacer por sí mismo debido a la complejidad o los permisos. Esta última pieza es importante para permitirle seguir el principio de privilegios mínimos sin forzar a los desarrolladores a través de un proceso manual del departamento de servicio.

Aunque puede optar por ampliar el conjunto de DevOps para satisfacer estas necesidades, es probable que tenga que admitir varias plataformas de aplicaciones a lo largo del tiempo y las herramientas y procesos específicos que las admiten también deben cambiar. El problema principal es que los estándares son un objetivo en constante cambio. Como un profesional de ingeniería de plataformas indicó:

Las dificultades implican la estandarización... y el tratamiento de 'abandonware'... La normalización a menudo no se logra debido a una posible interrupción de los procesos automatizados y a la tarea que consume mucho tiempo identificar los cambios necesarios. - Martin, ingeniero de DevOps, gran empresa logística

Normalmente, el cambio rápido a un estándar nuevo o actualizado no es factible y abandonar los procesos existentes crea riesgos. Es posible que su organización ya use varios conjuntos de DevOps o diferentes combinaciones de herramientas individuales y servicios para desarrolladores por escenario. Incluso con un equipo central y una solución estándar, a medida que aumentan sus necesidades de autoservicio, la variabilidad es inevitable. Por lo tanto, querrá permitir la experimentación controlada en la que los equipos designados puedan probar nuevas tecnologías, estrategias de implementación, etc., seguidos de la adopción deliberada y un lanzamiento incremental.

Por lo general, las experiencias de autoservicio se dividen en dos categorías principales: automatización y agregación de datos.

Aunque la agregación de datos crea buenas experiencias de usuario, la automatización es más importante:

La automatización es clave y será apreciada por todos. La [Data] agregación es secundaria. – Peter, jefe de ingeniería de plataformas, empresa tecnológica multinacional

En el recorrido de ingeniería de la plataforma, ha identificado problemas que podrían resolverse mediante la automatización. Además de reducir la carga cognitiva y el trabajo del desarrollador, la automatización también puede ayudar a garantizar que las aplicaciones estén conectadas a las mejores herramientas y servicios para las operaciones, la seguridad y otros roles para realizar su trabajo.

Sin embargo, si trabaja con más de un sistema para impulsar la automatización, algún nivel de agregación de datos es útil para ayudar a realizar un seguimiento de las solicitudes automatizadas y los resultados asociados. Puede empezar vinculando a sistemas externos para satisfacer otras necesidades o para obtener detalles detallados. La agregación y visibilidad de datos también es importante para auditar, gobernanza y reducir los residuos (por ejemplo, entornos sin usar).

La automatización de cosas como el aprovisionamiento de infraestructura se puede realizar mediante integraciones del sistema, pero también puede desencadenar y facilitar un proceso de flujo de trabajo manual que parece automatizado para el desarrollador. Esto es útil en las primeras fases de la plataforma, para los nuevos productos que está incorporando al ecosistema o en áreas que no tiene o no puede automatizar mediante un sistema (por ejemplo, la asignación de licencias de software). Con el diseño adecuado, puede empezar con un proceso manual facilitado por algo como Power Automate que cambie a un flujo totalmente automatizado a lo largo del tiempo. Por lo tanto, diseñe una automatización desde el principio.

Comience de forma sencilla mediante la reutilización de inversiones existentes, como los sistemas de ingeniería o un portal interno, después pase a la creación de CLIs, páginas web básicas o incluso power Pages, Power BI o paneles de Microsoft Fabric y expanda según surja la necesidad. Tener una API coherente que UX usa puede ayudarle a admitir varias interfaces a lo largo del tiempo a medida que cambian sus necesidades y preferencias.

Componentes de la plataforma de autoservicio para desarrolladores: API, grafo, orquestador, proveedores y metadatos

Tenga en cuenta los fundamentos del autoservicio del desarrollador:

Como se muestra en la ilustración, los siguientes componentes constituyen el núcleo del concepto de base de autoservicio para desarrolladores:

Estos componentes fundamentales permiten usar e intercambiar diferentes bloques de creación a lo largo del tiempo.

¿Tengo que crear todo esto para empezar?

No. En primer lugar, se trata de un modelo conceptual que le ayudará a pensar en lo que una fundación como esta debería ser capaz de hacer una vez completado. En segundo lugar, los detalles de implementación son menos importantes aquí, dado que la API de la plataforma de desarrollador se convierte en la interfaz clave. La implementación inicial podría empezar a usar interfaces y clases en el código para las distintas capas descritas o mezclarlas en otros productos. También puede omitir aspectos porque el desarrollo de clientes te indica que es simplemente una prioridad menor. Empieza con lo que tienes y creces.

API de plataforma para desarrolladores

Debe definir una API de plataforma para desarrolladores para que actúe como contrato del sistema. Las interfaces de usuario diferentes usan la API para habilitar el acceso a datos o controlar el aprovisionamiento y otras acciones.

Esta API actúa como una capa de autenticación y seguridad importante limitando el acceso a las API subyacentes sin procesar en otros sistemas a datos y operaciones más específicos y controlados. La API proporciona acceso a su propia representación de un perfil de usuario, el rol de alto nivel de un usuario dentro de la plataforma (miembro del equipo, administrador, etc.) y los identificadores del sistema del proveedor de identidades principal. Para obtener más información, consulte Usuarios y equipos.

Proveedores de plataformas para desarrolladores

Dada la amplitud de una plataforma de desarrollador interna, debe crear o identificar sistemas que siguen un modelo de proveedor extensible para introducir funcionalidad en la API. La idea es que la funcionalidad clave, como la automatización y la agregación de datos, se proporciona mediante la interacción con componentes conectables con interfaces bien definidas. Este acoplamiento flexible le ayuda a conectar en lo que necesita incrementalmente y mejora la capacidad de mantenimiento, ya que puede probar la funcionalidad independientemente del resto de la base.

También es una manera importante de habilitar una mentalidad de origen interno escalable para su plataforma. Normalmente, los esfuerzos de aprovisionamiento interno en torno a la ingeniería de plataformas no obtienen tracción debido a los desafíos con el mantenimiento continuo. Es posible que otros equipos estén dispuestos a contribuir a la funcionalidad, pero es menos probable que estén dispuestos a mantener y probar algo dentro del núcleo de la plataforma. Por el contrario, cualquier equipo centralizado tiene una capacidad limitada para mantener el código contribuido o incluso revisar las solicitudes de incorporación de cambios. El concepto de proveedor de plataformas para desarrolladores alivia esta tensión al permitir que el código escrito de forma independiente se conecte a la funcionalidad básica dentro de la base de autoservicio del desarrollador. Aunque debe administrar cuidadosamente qué proveedores usa, revisar cualquier código de proveedor y limitar el área expuesta a la que un proveedor determinado puede acceder en su plataforma de desarrollador, un enfoque conectable puede ayudarle a realizar más tareas mediante el escalado del esfuerzo en una parte más amplia de la organización.

Conceptos clave del proveedor de la plataforma para desarrolladores

Entities

El concepto de una entidad es algo que un desarrollador u otro sistema en tu plataforma interna de desarrolladores necesita rastrear, actualizar, presentar o actuar sobre. Las entidades pueden tener relaciones entre sí que, cuando se toman juntas, componen un grafo que proporciona información crítica sobre los fragmentos de la plataforma de desarrollador interna. Los proveedores de plataformas de desarrollador pueden generar entidades para habilitar las funcionalidades principales, entre las que se incluyen:

• Exponer recursos o entornos aprovisionados externamente o API disponibles para la detección y el uso
• Exponer relaciones para el análisis de dependencias, el análisis de impacto, la detección, etc.
• Información sobre el responsable de mantenimiento o titularidad para facilitar el descubrimiento y la colaboración
• Exponer más datos para su uso en experiencias de usuario

Encapsular esta funcionalidad en una interfaz de proveedor de plataforma de desarrollador bien definida simplifica la integración y las pruebas, permite la implementación independiente y permite a los desarrolladores fuera del equipo principal de la plataforma de desarrolladores interna contribuir y administrar proveedores. Esto es importante en organizaciones grandes o divisionales en las que no todas las herramientas, servicios o plataformas se administran de forma centralizada, pero la organización más amplia aún quiere compartir funcionalidades. Por lo tanto, incluso si no inicia por este camino inicialmente, es algo en lo que pensar a largo plazo.

Propiedades comunes

Cada entidad debe tener un conjunto de propiedades comunes para permitir que la base las administre. Algunas propiedades que se deben tener en cuenta incluyen:

• Identificador único
• Nombre
• Proveedor de origen
• Asociaciones opcionales para:
  • Usuario propietario
  • Equipo propietario
  • Otras entidades

Las propiedades de usuario y equipo son importantes por tres razones: control de acceso basado en rol (RBAC), detección y agregación de datos (como resúmenes de nivel de equipo). La incorporación de RBAC desde el principio es fundamental para la seguridad y el crecimiento de la plataforma de desarrollo interna a lo largo del tiempo. Dado que el desarrollo es un deporte de equipo, descubrir con quién hablar sobre una entidad se convertirá rápidamente en fundamental para reutilizar, apoyar y la aplicación interna.

Entidades comunes y específicas del proveedor

También debe poder establecer un conjunto de entidades comunes de alto nivel normalizadas que pueden generar varios proveedores. Por ejemplo:

• Environments
• Recursos
• APIs (Interfaz de Programación de Aplicaciones)
• Repositorios
• Components
• Tools

Por lo general, deben estar en un nivel alto, como lo haría en el contexto del modelo C4 o en la mayoría de los diagramas de componentes de alto nivel. Por ejemplo, para un entorno, no es necesario incluir los detalles de la topografía de la infraestructura interna; Solo necesita suficiente información para enumerar y asociar diferentes entornos conceptuales de varios proveedores en la misma experiencia de usuario. La entidad puede apuntar a niveles inferiores de detalle fuera del sistema en lugar de intentar consumir todo. Estos proporcionan puntos de partida para la detección que son fundamentales para habilitar la agregación de datos a lo largo del tiempo.

Otros son específicos de un caso de uso o proveedor concretos, por lo que debe pensar en cómo puede adaptarse a un conjunto creciente de tipos de entidad a lo largo del tiempo.

Plantillas

El concepto de una plantilla en este contexto se diferencia de la idea de las entidades, ya que están diseñadas para impulsar una acción. Entre los escenarios de ejemplo se incluyen el aprovisionamiento de infraestructuras, la creación de un repositorio y otros procesos de larga duración. Estas plantillas también deben estar disponibles a través de proveedores extensibles de plataforma para desarrolladores y deben admitir las mismas propiedades comunes que las entidades, incluidas las asociaciones de entidades.

Sin embargo, también pueden definir los requisitos de entrada necesarios, ya sea especificados por el sistema o por el usuario, que son imprescindibles para realizar la acción. Pueden variar desde cualquier cosa como asignar un nombre al recurso a adiciones opcionales.

Entre los ejemplos de plantillas se incluyen:

• Plantillas de infraestructura como código (IaC)
• Plantillas de aplicación (inicio derecho) o repositorios de plantillas
• Compilación de plantillas de canalización o flujo de trabajo
• Canalización de implementación o plantillas de flujo de trabajo
• Scripts con parámetros
• Flujos de Power Automate con parámetros (por ejemplo, un flujo de nube desencadenado por una solicitud HTTP)
• Plantillas de correo electrónico

Al igual que las entidades, las plantillas pueden incluir propiedades específicas del proveedor.

Cada plantilla puede tener una representación diferente que sea única para el proveedor. Estos pueden oscilar entre Terraform o plantillas de ARM, gráficos de Helm, flujos de trabajo de Acciones de GitHub con parámetros o Azure Pipelines, scripts simples o formatos personalizados.

Los detalles reales de la plantilla subyacente no necesitan almacenarse de forma centralizada. Podrían existir en repositorios, registros o catálogos diferentes. Por ejemplo, podría usar repositorios de plantillas de GitHub para las plantillas de aplicación, mientras que las plantillas de IaC podrían existir en un repositorio de catálogo restringido que los desarrolladores solo pueden acceder indirectamente a través de algo parecido a los entornos de implementación de Azure. Otras plantillas de IaC se pueden almacenar en un registro de artefactos de OCI, como los gráficos de Helm. En otros casos, la plantilla podría ser una referencia a un punto de conexión HTTP con parámetros. Un proveedor de plataforma para desarrolladores debe proporcionar suficiente información sobre cada tipo de plantilla para que se pueda hacer referencia a ellas y las opciones expuestas para su uso en experiencias de usuario. Sin embargo, las plantillas se pueden alojar en la ubicación más natural para tus casos de uso.

Los ingenieros de plataforma o expertos en una área determinada escriben plantillas y, a continuación, los comparten con los equipos de desarrollo para su reutilización. La centralización del uso de estas plantillas a través de un sistema permite al desarrollador autoservicio y crea barreras de protección que ayudan a aplicar el cumplimiento de las directivas o estándares de la organización. Más información sobre esto cuando tratemos el orquestador de la plataforma para desarrolladores en un momento.

Gráfico de la plataforma para desarrolladores

Puede pensar en un grafo de plataforma para desarrolladores como algo que le permite asociar entidades y plantillas de varios proveedores a un grafo que se puede buscar. Sin embargo, los datos reales de las entidades no necesariamente deben conservarse directamente en una base de datos específica de grafos. En su lugar, las interacciones con proveedores se pueden almacenar en caché junto con los metadatos necesarios para que se integren en conjunto.

El gráfico es eficaz cuando se usa con entidades comunes que varios proveedores podrían contribuir. Por ejemplo, una lista de APIs puede provenir de un producto como Azure API Center, pero también podría querer integrar automáticamente las implementaciones y los entornos desde sus sistemas de implementación continua. Con el tiempo, podría cambiar entre diferentes sistemas de implementación o incluso admitir más de un sistema de implementación. Siempre que cada sistema de despliegue tenga un proveedor de plataforma para desarrolladores, aún debería ser posible establecer la asociación.

Cada una de las experiencias de usuario que se crean a partir de este gráfico puede aprovechar una API común para el descubrimiento, la búsqueda, la gobernanza y mucho más. Un orquestador de plataforma de desarrollador puede aprovechar este mismo grafo para que las acciones realizadas por un proveedor de plataformas de desarrollador contribuyan automáticamente a las entidades disponibles para la misma API.

Orquestador de la plataforma para desarrolladores

Un orquestador de plataforma para desarrolladores permite a los desarrolladores o sistemas crear solicitudes para realizar una acción mediante una plantilla. No realiza estas acciones en sí, sino que se coordina con un motor de tareas, un motor de flujo de trabajo u otro orquestador para hacerlo. Es una de las piezas fundamentales y debe asegurarse de que esté incluida en su base de autoservicio. Permite a los desarrolladores crear solicitudes con una plantilla o ejecutar una acción sin permiso directo. Además, a diferencia del concepto de CI o CD, estas acciones no tienen que estar relacionadas con el código fuente de la aplicación.

Puede usar Acciones de GitHub, Azure Pipelines u otro motor de flujo de trabajo como orquestador. Este es un lugar razonable para empezar, pero es posible que quiera tener un poco de abstracción para permitir que diferentes tipos de plantillas usen motores subyacentes diferentes. Esto puede ser útil por algunas razones:

• En primer lugar, es probable que quiera poder elegir diferentes motores de ejecución de tareas y flujos de trabajo a lo largo del tiempo sin tener que cortar flash. Al permitir el uso de más de un motor, puede migrar al nuevo motor con el tiempo o simplemente usarlo para nuevas acciones, sin afectar a las acciones más antiguas.
• Algunos procesos que desea ayudar a organizar podrían requerir pasos manuales inicialmente incluso si planea automatizarlos completamente más adelante.
• Otras acciones pueden tener como destino roles fuera del equipo de desarrollo, como cuentas por pagar o un administrador de licencias. Los motores de código bajo, como Power Automate, suelen funcionar bien para estos roles.
• Otras acciones se pueden controlar a través de solicitudes HTTP sencillas en las que la creación de algo tan capaz como Acciones de GitHub o Azure Pipelines no es necesaria o rentable para escalar.

Afortunadamente, la expansión de la idea de un proveedor de plataformas de desarrollo para cubrir la activación y seguimiento de pasos de automatización puede proporcionar esta abstracción necesaria. Tenga en cuenta la siguiente ilustración:

Este es el concepto general:

• Opcionalmente, las plantillas pueden especificar un conjunto de entradas que el usuario puede escribir. Cuando un desarrollador desencadena una acción determinada, selecciona una plantilla (incluso si no se describe de esa manera) y escribe las entradas.
• Una referencia a las entradas relacionadas con la plantilla se convierte en una solicitud en la API de la plataforma para desarrolladores.
• Una vez enviada una solicitud, un componente de enrutamiento y control de solicitudes dentro del orquestador comienza a realizar el seguimiento del ciclo de vida de la solicitud. El componente de enrutamiento y manejo de solicitudes dirige la plantilla en la solicitud al proveedor de plataformas para desarrolladores donde se originó la plantilla.
• A continuación, el proveedor de la plataforma para desarrolladores realiza los pasos adecuados para su implementación.
• (Opcional) El proveedor de la plataforma para desarrolladores actualiza el estado de la solicitud a medida que realiza la acción.
• Una vez completada la solicitud, el proveedor de la plataforma para desarrolladores puede devolver un conjunto de entidades para agregar o actualizar en el gráfico de la plataforma para desarrolladores. Pueden ser entidades específicas o comunes del proveedor.

Opcionalmente, para admitir interacciones más avanzadas, los proveedores de plataformas de desarrollo pueden llamar directamente a la API de la plataforma para desarrolladores para obtener más entidades como entradas o incluso solicitar otra acción relacionada.

Elija un proveedor de plataforma para desarrolladores que use una tarea general o un motor de flujo de trabajo. Más concretamente, desea que algo sirva de puente lo que ha reunido como parte de Aplicar sistemas de la ingeniería del software. Un motor de ejecución de tareas o flujo de trabajo general en el que invertir es un sistema de CI/CD.

Ejemplo de uso de Acciones de GitHub o Azure Pipelines

Veamos brevemente cómo funcionarían Acciones de GitHub o Azure Pipelines como proveedores de plataformas de desarrollo.

Para GitHub Actions, la clave para realizar este proceso es que un proveedor de plataformas para desarrolladores pueda conectarse a la instancia de GitHub especificada y usar la API REST de Actions para activar un evento de despacho de flujo de trabajo y así iniciar una ejecución del flujo de trabajo. Cada flujo de trabajo puede admitir un conjunto de entradas agregando una configuración de workflow_dispatch al archivo YAML de flujo de trabajo. Los desencadenadores de Azure DevOps son similares y también puede usar la API de canalización de Azure DevOps para ejecuciones. Es probable que vea las mismas funcionalidades en otros productos.

Estos flujos de trabajo o canalizaciones no necesitan estar en repositorios de código fuente de la aplicación. El concepto sería aprovechar este hecho para hacer algo parecido a esto:

• Los ingenieros de plataforma o los miembros del equipo de DevOps pueden mantener los flujos de trabajo o canalizaciones en uno o varios repositorios centrales a los que los propios desarrolladores no tienen acceso, pero el proveedor de la plataforma para desarrolladores está configurado para su uso. Este mismo repositorio puede incluir scripts y fragmentos de código IaC que utilizan los flujos de trabajo o las canalizaciones.
• Para permitir que estos flujos de trabajo o canalizaciones interactúen con el sistema descendente adecuado, el equipo de operaciones u otros miembros del equipo de ingeniería de plataforma pueden agregar los secretos necesarios en el repositorio central. Consulte la documentación de Acciones de GitHub y Azure DevOps para más información sobre cómo hacerlo, o puede optar por centralizar los secretos mediante algo como Azure Key Vault.
• Estos flujos de trabajo o canalizaciones pueden seguir un modelo en el que publican las entidades resultantes como un artefacto de compilación e implementación (documentos de GitHub, documentos de Azure DevOps).
• Durante una ejecución, el proveedor de la plataforma para desarrolladores puede monitorear en el orquestador el estado del flujo de trabajo o canalización y actualizar el estado del ciclo de vida hasta que se complete. Por ejemplo, puede usar web hooks con Acciones de GitHub y enlaces de servicio con Azure Pipelines para realizar un seguimiento de las actualizaciones.
• Una vez completado, el proveedor puede consumir el artefacto publicado para su inclusión en el grafo de la plataforma para desarrolladores, según sea necesario.

Por último, puede configurar este proveedor de plataforma para desarrolladores para generar un conjunto de plantillas en el gráfico de la plataforma para desarrolladores que haga referencia al repositorio y flujo de trabajo o canalización adecuados, junto con entradas para una tarea determinada.

Lo bueno de usar un sistema de CI/CD es que a menudo está configurado para ejecutar comandos CLI arbitrarios, por lo que no necesitas una integración única y específica para cada cosa que haces. Puede agregarlos con el tiempo según sea necesario.

Gran parte de lo que se describe en este ejemplo se aplica a cómo pueden funcionar otros tipos de proveedores. También es importante tener en cuenta que el uso de Acciones de GitHub o Azure Pipelines en este contexto no requiere que también los use para las canalizaciones de CI/CD reales.

Otros ejemplos

Estos son algunos ejemplos de otros tipos de proveedores de plataformas para desarrolladores que podrían procesar plantillas.

Aunque es posible que no necesite todos estos proveedores para empezar, puede ver cómo la extensibilidad a través de algo como un proveedor de plataformas de desarrollo puede ayudar a que sus capacidades de automatización crezcan con el tiempo.

Usuarios y equipos

La ingeniería de plataformas es inherentemente un asunto de varios sistemas, por lo que es importante planear cómo una base de autoservicio debe controlar los problemas más difíciles con la integración de estos sistemas juntos. Esta es una estrategia para abordar desafíos comunes con la identidad, los usuarios y los equipos.

Establecimiento del concepto de un equipo más allá de un único grupo de proveedores de identidades

A medida que continúa el recorrido de ingeniería de la plataforma, es probable que encuentre que los grupos de proveedores de identidades son excelentes para administrar la pertenencia, pero que varios grupos realmente necesitan reunirse para formar el concepto de un equipo para RBAC y la agregación de datos.

En el contexto de la ingeniería de plataformas, definimos un equipo como un conjunto de personas en diferentes roles que trabajan juntos. Para la agregación de datos, la idea de un equipo multirole es fundamental para habilitar el descubrimiento y consolidación de información en lugares como los tableros de informes. Por otro lado, un grupo es un concepto de proveedor de identidades general para un conjunto de usuarios y está diseñado con la idea de agregar varias personas a un rol específico, en lugar de hacerlo de otra manera. Con RBAC, un equipo puede relacionarse con varios grupos de proveedores de identidades a través de roles diferentes.

El origen de los datos del equipo puede provenir de algunos lugares diferentes. Por ejemplo, si estás utilizando el patrón teams as code (TAC), un proveedor de plataforma para desarrolladores puede monitorear los cambios en los archivos de un repositorio y almacenarlos en caché en un almacén de metadatos de perfiles de usuario y equipos. O bien, puede integrarse directamente con algo parecido a un proyecto del Centro de desarrollo de Azure que ya tiene estas construcciones RBAC principales disponibles.

Establecer un modelo para integrar con sistemas descendentes en el nivel de equipo o usuario

Aunque algunas herramientas y servicios de desarrollador y operaciones integran y usan de forma nativa los conceptos del proveedor de identidades directamente, muchos abstraen esto en su propia representación de un grupo o usuario (incluso con SSO). Además de habilitar el acceso entre herramientas, esta realidad también puede suponer problemas para la agregación de datos. En concreto, es posible que las API del sistema descendente usen sus propios identificadores en lugar de los identificadores del proveedor de identidad (por ejemplo, el identificador de objeto de Entra ID no se usa directamente). Esto dificulta el filtrado y la asociación de datos a nivel de usuario o equipo a menos que puedas mapear entre diferentes identificadores.

Abordar las diferencias de nivel entre equipo y grupo

Los patrones como TaC pueden permitirle almacenar y acceder a las relaciones entre los identificadores de equipo o grupo de cada sistema, de modo que pueda hacer una correspondencia entre ellos. En resumen, un repositorio Git seguro y auditable se convierte en el origen de un equipo, y los Pull Requests (PRs) proporcionan una interfaz de usuario controlada para realizar actualizaciones. Los sistemas de CI/CD pueden entonces actualizar los sistemas posteriores y mantener las relaciones de identificadores relacionadas para el equipo que los utilizó para hacerlo.

Por ejemplo, esto permite almacenar las siguientes relaciones en las llamadas API:

Si prefiere usar un origen de datos distinto de los archivos de un repositorio, los equipos pueden aplicar este mismo concepto general mediante el orquestador de la plataforma para desarrolladores para lograr lo mismo. En este modelo, un proveedor de plataforma para desarrolladores para el origen de los datos del equipo puede desencadenar un evento de actualización de equipo en el que todos los demás proveedores reciben y actúan según corresponda.

Abordar los desafíos del identificador de usuario

Otro desafío relacionado para el acceso a datos y la agregación es las diferencias de identificador de usuario. Al igual que en el caso del equipo, si usa una integración de sistema a sistema para consultar datos sobre un usuario, no puede suponer que la ID nativa de los proveedores de identidades (por ejemplo, ID de objeto para Entra ID) admite una API determinada. Aquí de nuevo, almacenar una asignación para un identificador de usuario que tenga acceso a los datos a través de la API de la plataforma para desarrolladores puede ayudar. Por ejemplo, considere GitHub:

Para cada sistema, si puede realizar una búsqueda de un identificador de usuario en otro sistema a través de una API sin un token de usuario, un proveedor de plataforma de desarrollador determinado puede generar esta asignación sobre la marcha. En algunos casos, esto puede resultar complicado, ya que es posible que tenga que realizar esta operación de forma masiva y almacenar en caché los resultados para mantener el rendimiento.

Recurre al uso de múltiples tokens de usuario

En situaciones en las que los proveedores necesitan acceder a los datos de nivel de usuario sin una manera de realizar la traducción del identificador de usuario que funcionaría, la API de la plataforma para desarrolladores se puede configurar para administrar varios tokens de usuario. Por ejemplo:

• La API de la plataforma para desarrolladores podría admitir una caché de tokens de usuario específicos del proveedor para su uso con sistemas posteriores.
• Cualquier interacción con un proveedor determinado activado por la API se incluiría en el token de usuario del proveedor, si está disponible.
• Para controlar el caso en el que no había ningún token de usuario disponible, el proveedor desencadenaría un flujo de OAuth para obtener uno.
• Para empezar, la API de la plataforma para desarrolladores devolvería un URI de autenticación para un proceso de OAuth con un URI de redirección que se envió al proveedor. El URL pasado incluiría un código nonce o de un solo uso.
• A continuación, la API devuelve una respuesta no autenticada con el URI.
• Después, cualquier experiencia de usuario puede usar este URI para impulsar el flujo de autenticación adecuado en un explorador.
• Una vez que se produce la redirección, la plataforma para desarrolladores recibiría el token de usuario necesario y la almacenaría en caché para futuras referencias junto con el identificador de usuario.
• Entonces, el cliente podría intentar de nuevo realizar una llamada a la API, que entonces tendría éxito.

Este concepto describe una manera de gestionar la autenticación complicada, ya que puede reutilizar los identificadores siempre que sea posible y no es necesario mantener URIs de redirección independientes por cada sistema aguas abajo.

Uso de vínculos profundos contextuales a herramientas y sistemas de informes

Hasta este punto hemos estado hablando del aspecto de automatización del espacio de problemas. Esto por sí solo puede ser de gran ayuda, ya que la interfaz de usuario puede utilizar los valores de las entidades que se devuelven durante la automatización para crear enlaces profundos en otros sistemas para el equipo.

Incluso cuando no están relacionados con la automatización, los proveedores de plataformas de desarrollo pueden emitir cualquier tipo de entidad necesaria. Sin embargo, por lo general usted no desee llevar todos los datos detallados de toda su plataforma interna de desarrolladores al gráfico de su plataforma de desarrolladores. Los paneles de soluciones de observabilidad como Grafana, Prometheus, DataDog o inteligencia de código en productos como SonarQube y funcionalidades nativas en conjuntos de DevOps, como GitHub y Azure DevOps, son capaces. En su lugar, el mejor enfoque suele ser crear vínculos profundos en estos otros sistemas. Las entidades pueden proporcionar información suficiente para crear vínculos sin contener directamente información detallada, como el contenido del registro.

En los casos en los que desea agregar y resumir datos entre herramientas o necesita impulsar métricas personalizadas, las soluciones de informes de Power BI o Microsoft Fabric pueden ser el siguiente puerto de llamada. Para combinar datos del equipo, puede conectarse a la base de datos de su organización o pasar por una API de plataforma de desarrolladores. Por ejemplo, como se describe en Planificar y priorizar, un lugar donde podría querer un panel personalizado es para medir el éxito de su plataforma de desarrollo interna.

Sea selectivo con cada experiencia adicional que cree

Aunque puede ser atractivo recrear capacidades existentes en algo similar a un portal común, tenga en cuenta que también tendrá que mantenerlas. Este es el área en la que es importante seguir una mentalidad de producto. Las interfaces estilo cuadro de mando son fáciles de concebir y comprender, pero los desarrolladores pueden encontrar más valor en otras áreas.

Dicho esto, el modelo aquí permite usar datos agregados en el gráfico de la plataforma para desarrolladores para crear experiencias de usuario personalizadas. Las entidades deben tener compatibilidad integrada para que puedan vincularse a un usuario o equipo. Esto permite a la API de la plataforma de desarrollador definir el ámbito de la salida (junto con el uso de la indexación y el almacenamiento en caché).

Sin embargo, incluso si necesita crear una experiencia de usuario personalizada en lugar de un vínculo profundo, extraer todos los datos en el gráfico de la plataforma para desarrolladores normalmente no es el mejor enfoque. Por ejemplo, considere una situación en la que es posible que quiera mostrar los registros en la experiencia de usuario que ya tiene un hogar bien definido y administrado. Utilice la información en las entidades relacionadas para ayudar a su equipo de experiencia de usuario a recopilar información directamente desde sistemas descendentes.

Para empezar, es posible que tenga que usar una integración del sistema a sistema para conectarse, pero una vez que haya implementado uno de los modelos descritos en usuarios y equipos, puede usar cualquier identificador de usuario o equipo de nivel inferior almacenado o tokens de autenticación de usuario si es necesario.

Estos son algunos ejemplos de experiencias comunes que se deben tener en cuenta:

Experiencias de usuario

Los distintos roles de su organización tienen herramientas o servicios que representan un centro de gravedad para su trabajo diario. La atracción de estos sistemas puede dificultar que las nuevas experiencias de usuario fuera de estos centros de gravedad ganen aceptación. En un mundo perfecto, los desarrolladores, las operaciones y otros roles pueden seguir trabajando en un entorno que tenga sentido para ellos, a menudo aquellos que ya usan.

Teniendo esto en cuenta, planear varias interfaces de usuario a medida que avanza en su recorrido de ingeniería de plataforma es una buena idea. Esto también puede proporcionar una oportunidad para iniciar interfaces simples, probar valor y crecer hacia interfaces más complejas a medida que surge la necesidad.

Integra lo que tienes

Si ha leído los artículos Aplicación de sistemas de ingeniería de software y Refinación de la plataforma de aplicaciones, es probable que haya identificado los sistemas que desea seguir usando. En cualquier caso, evalúe si puede mejorar y ampliar lo que tiene antes de empezar a crear nuevas experiencias desde cero. (Pregúntate, ¿reaccionarán mejor a otra nueva experiencia de usuario o a una versión mejorada de algo que tengan ahora?)

Algunas de las herramientas, utilidades o aplicaciones web que desea seguir usando serán personalizadas y son buenas candidatas para mejorar. Pero no olvide prestar atención a si sus herramientas y servicios favoritos tienen un modelo de extensibilidad que puede usar. Obtendrás muchas ventajas de empezar allí. Esto puede eliminar los dolores de cabeza de mantenimiento y seguridad y permitirle centrarse en el problema que intenta resolver.

Por ejemplo, es posible que pueda ampliar las siguientes superficies que ya usa:

• Editores e IDEs
• Su conjunto de DevOps
• Las CLIs son cada vez más extensibles también
• Entornos de poco código o sin código, como Power Pages

Cada uno de ellos podría proporcionar un mejor punto de partida para un rol determinado que si lo configurara desde cero, ya que son centros de gravedad existentes. Tener una API de plataforma para desarrolladores común como línea base le permite intercambiar cosas, experimentar y cambiar con el tiempo.

Considere la posibilidad de que las extensiones del editor web creen un portal para desarrolladores.

Si busca una experiencia basada en web para desarrolladores, tenga en cuenta que una tendencia reciente es versiones basadas en web de editores e IDE. Muchos, como los que usan VS Code, tienen compatibilidad con la extensión. Con VS Code, todo lo que cree para estas experiencias web se traduce localmente para obtener una doble ventaja.

Más allá de los servicios como GitHub Codespaces, vscode.dev es una versión web gratuita del editor de VS Code sin proceso, pero incluye compatibilidad con determinados tipos de extensiones , incluidas las que usan vistas web para la interfaz de usuario personalizada.

Incluso si los desarrolladores no usan VS Code, los patrones de experiencia de usuario son conocidos y se pueden encontrar en otras herramientas de desarrollo. El uso de vscode.dev puede proporcionar una base web cómoda y familiar para experiencias de desarrollador además de la propia herramienta.

Estos pueden actuar como un portal centrado en desarrolladores en una forma familiar y que además puede adaptarse al uso local.

ChatOps

Otra oportunidad que a menudo se pasa por alto es implementar una interfaz de ChatOps. Dado el aumento de las interfaces basadas en chat debido al aumento de los productos de inteligencia artificial, como ChatGPT y GitHub Copilot, los comandos de acción o los comandos de barra diagonal pueden proporcionar una manera útil de desencadenar flujos de trabajo de automatización, comprobar el estado, etc. Dado que la mayoría de las plataformas de CI/CD de aplicaciones ofrecen soporte nativo para sistemas como Microsoft Teams, Slack o Discord, esta puede ser una manera natural de integrarse con otra interfaz que desarrolladores y roles de operaciones relacionados utilizan diariamente. Además, todos estos productos tienen un modelo de extensibilidad.

Invertir en un nuevo portal para desarrolladores

Suponiendo que no tiene un portal o interfaz existente que quiera usar como base, puede decidir crear un nuevo portal para desarrolladores. Piense en esto como un destino en lugar de un punto de partida. Si aún no tiene un equipo de desarrollo que trabaje con usted, iniciar este esfuerzo es el momento de hacerlo. Cada organización es diferente, así que no hay una respuesta única sobre qué debe incluirse en este tipo de experiencia personalizada. Como resultado, no hay ninguna respuesta predeterminada para un producto empaquetado que puedes poner en marcha y usar tal cual para algo como esto en la actualidad.

En el caso de las opciones autohospedadas diseñadas a medida, los marcos generales de portales web no son nuevos y es posible que los equipos de desarrollo ya usen uno al que pueda recurrir. Si intenta sacar algo delante de los usuarios para recibir comentarios anticipados, incluso podría empezar con algo tan sencillo como las Power Pages de bajo código para conectarse a la API de plataformas comunes de desarrollo.

Los esfuerzos más recientes del portal para desarrolladores tienen una perspectiva más definida. Por ejemplo, Backstage.io es un kit de herramientas del portal para desarrolladores personalizado creado inicialmente para satisfacer las necesidades de Spotify. Incluye una CLI para ayudar a inicializar la estructura de código fuente de manera similar a create-react-app para React.js.

Como kit de herramientas para el portal, requiere trabajo para configurarlo completamente y la personalización requiere conocimientos de TypeScript, Node.js y React. Sin embargo, lo genial es que, como kit de herramientas, puede cambiar casi cualquier cosa. También tiene su propio catálogo de software y mecanismo de plantillas, pero su uso no es necesario, y es una manera bien definida de incorporar código nuevo denominado plugins.

Contenido relacionado

• Microsoft Power Pages
• Backstage.io
• Aplicación de sistemas de ingeniería de software