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 a continuación, 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 límites de protección a través de la ejecución y el aprovisionamiento de tareas controladas y controladas, 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 los admitan también tendrán que cambiar. El problema principal es que los estándares son un destino móvil. Como un profesional de ingeniería de plataformas indicó:

Las dificultades implican la estandarización... y tratar con '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, Large Logistics Company

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á habilitar 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á amado por todos los usuarios. La agregación [Data] es secundaria. – Peter, jefe de ingeniería de plataformas, compañía multinacional tecnológica

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 está trabajando 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 las inversiones existentes, como los sistemas de ingeniería o un portal interno, la creación de CLIs, páginas web básicas o incluso power Pages, Power BI o paneles de Microsoft Fabric y la expansión a medida que surjan las necesidades. 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 base como esta debería ser capaz de hacer una vez que se haya hecho. 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 le 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, etcetera.) y 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, cree o identifique 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 en 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 "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

Entidades

El concepto de una entidad es algo que un desarrollador u otro sistema de la plataforma de desarrollador interna necesita realizar un seguimiento, actualizar, presentar o actuar. 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, etcetera.
• Información sobre el mantenedor o propiedad para la detección 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 se dirige inicialmente a este camino, es algo que pensar a largo plazo.

Propiedades comunes

Cada entidad debe tener un conjunto de propiedades comunes para permitir que Foundation 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 compilación en RBAC desde el principio es fundamental para la seguridad y aumentar la plataforma de desarrollo interna a lo largo del tiempo. Dado el desarrollo es un deporte de equipo, descubrir a quién hablar sobre una entidad se convertirá rápidamente en fundamental para reutilizar, apoyar e interiormente.

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:

• Entornos
• Recursos
• API existentes
• Repositorios
• Componentes
• Herramientas

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 serán 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.

Templates (Plantillas [C++])

El concepto de una plantilla en este contexto difiere de la idea de las entidades en que están pensadas para impulsar una acción. Entre los escenarios de ejemplo se incluyen el aprovisionamiento de infraestructura, 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 entradas necesarias, ya sea el sistema o el usuario especificados, que son necesarios 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 (Iniciar 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 (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 los 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 el autoservicio del desarrollador 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 tratamos el orquestador de la plataforma para desarrolladores en un poco.

Gráfico de la plataforma para desarrolladores

Puede pensar en un grafo de la 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 ajusten a todos.

El gráfico es eficaz cuando se usa con entidades comunes que varios proveedores podrían contribuir. Por ejemplo, una lista de API puede provenir de un producto como El Centro de API de Azure, pero también puede que quiera alimentar automáticamente las implementaciones y los entornos de los 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 implementación tenga un proveedor de plataforma para desarrolladores, todavía debe poder realizar la asociación.

Cada una de las experiencias de usuario que se crean a partir de este grafo puede aprovechar una API común para la detección de energía, 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 críticas que querrá asegurarse de que forma parte de 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 más de un motor, puede migrar con el tiempo o simplemente el uso del nuevo motor a nuevas acciones sin afectar a las 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 plataforma para desarrolladores para cubrir los pasos de automatización de desencadenamiento y seguimiento 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. Plantilla de rutas de componentes de enrutamiento y control de solicitudes en la solicitud al proveedor de la plataforma para desarrolladores donde se originó la plantilla.
• Después, el proveedor de la plataforma para desarrolladores realizaría 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 del proveedor o comunes.

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 puentee lo que se ha reunido como parte de Aplicar sistemas de ingeniería de 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ía un proveedor de plataforma de desarrollo de Acciones de GitHub o Azure Pipelines.

Para Acciones de GitHub, la clave para realizar este trabajo es que un proveedor de plataformas de desarrollador puede conectarse a la instancia de GitHub especificada y usar la API REST actions para desencadenar un evento de distribución de flujo de trabajo para desencadenar una ejecución de 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 e fragmentos de código iaC que usan los flujos de trabajo o las canalizaciones.
• Para permitir que estos flujos de trabajo o canalizaciones interactúen con el sistema de bajada adecuado, las 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 ver el estado del flujo de trabajo o canalización y actualizar el estado del ciclo de vida en el orquestador 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 gráfico 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án configurados para admitir la ejecución de CLIs arbitrarios, por lo que no se necesita una primera clase, integración única para todo lo que haga. Puede agregarlos con el tiempo según sea necesario.

Gran parte de lo que se describe en este ejemplo aplica 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 que todos estos proveedores se inicien, puede ver cómo la extensibilidad a través de algo como un proveedor de plataforma para desarrolladores puede ayudar a que las funcionalidades 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 el control de acceso basado en rol (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 de varios roles es fundamental para la detección de energía e información de acumulación en lugares como paneles 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 usa los equipos como patrón de código (TaC), un proveedor de plataforma para desarrolladores puede observar los cambios de archivo en un repositorio y almacenarlos en caché en un almacén de metadatos de equipo y perfil de usuario. O bien, puede integrarse directamente con algo parecido a un proyecto de Azure Centro de desarrollo que ya tiene estas construcciones RBAC principales disponibles.

Establecimiento de un modelo para la integración con sistemas de bajada en el nivel de equipo o usuario

Aunque algunas herramientas y servicios de desarrollador y operaciones integrarán y usarán de forma nativa los conceptos del proveedor de identidades directamente, muchos lo abstraerán 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 de bajada usen sus propios identificadores en lugar de identificadores del proveedor de identidades (por ejemplo: el identificador de objeto de Entra ID no se usa directamente). Esto dificulta el filtrado y la asociación de datos de nivel de usuario o equipo a menos que pueda asignar entre distintos identificadores.

Abordar las diferencias de nivel de grupo y equipo

Los patrones como TaC pueden permitirle almacenar y acceder a las relaciones entre los identificadores de grupo o equipo de cada sistema para que pueda asignar entre ellos. Para volver a resumir, un repositorio git seguro y auditable se convierte en el origen de un equipo y las solicitudes de incorporación de cambios proporcionan una interfaz de usuario controlada para realizar actualizaciones. Los sistemas de CI/CD pueden actualizar los sistemas de bajada y conservar las relaciones de identificador relacionadas para el equipo que usó 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 del sistema a sistema para consultar datos sobre un usuario, no puede suponer que el identificador nativo de 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 acceda 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 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.

Revierte al uso de varios 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 de identificadores 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 de bajada.
• Cualquier interacción con un proveedor determinado desencadenado por la API 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 flujo de OAuth con un URI de redirección que se pasó al proveedor. El URI pasado incluiría un código nonce/de uso único.
• 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.
• Después, el cliente podría volver a intentar la llamada API, lo que sería correcto.

Este concepto describe una manera de tratar con la autenticación complicada, ya que puede reutilizar los identificadores siempre que sea posible y no es necesario mantener URI de redirección independientes por sistema de bajada.

Uso de vínculos profundos con reconocimiento del contexto a herramientas y sistemas de informes

Hasta este punto hemos estado hablando del aspecto de automatización del espacio de problemas. Esto solo puede tardar mucho, ya que la interfaz de usuario puede usar valores de las entidades devueltas durante la automatización para crear vínculos profundos en otros sistemas para el equipo.

Incluso si no está relacionado con la automatización, los proveedores de plataformas de desarrollo pueden emitir cualquier tipo de necesidad de entidad. Sin embargo, por lo general no quiere incluir todos los datos detallados en toda la plataforma de desarrollador interna en el gráfico de la plataforma para 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 muy 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 de equipo, puede conectarse a la base de datos de Foundation o pasar por una API de plataforma para desarrolladores. Por ejemplo, como se describe en Planeamiento y prioridad, un lugar en el que puede que quiera que un panel personalizado mida el éxito de la plataforma de desarrollador interna.

Ser selectivo con cada experiencia adicional que cree

Aunque puede ser atractivo volver a crear funcionalidades existentes en algo como un portal común, tenga en cuenta que también tendrá que mantenerla. Este es el área en la que es importante seguir una mentalidad de producto. Las interfaces de estilo de panel son fáciles de concebir y comprender, pero los desarrolladores pueden encontrar más valor en otro lugar.

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. Use información en las entidades relacionadas para ayudar a la experiencia del usuario a recopilar información directamente desde sistemas de bajada.

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 extracción de estos sistemas puede dificultar las nuevas experiencias de usuario fuera de estos centros de gravedad para ganar tracció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.

Integración de lo que tiene

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á 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 IDE.
• Su conjunto de DevOps.
• Las CLIs también son cada vez más extensibles.
• Entornos de poco código o sin código, como Power Pages.

Cada uno podría proporcionar un mejor punto de partida para un rol determinado que algo que configuró desde cero, ya que son centros de gravedad existentes. Tener una API de plataforma para desarrolladores común como línea base le permitirá 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 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 un formulario conocido que también se puede traducir 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 tienen compatibilidad integrada con sistemas como Microsoft Teams, Slack o Discord, esto puede ser una manera natural de integrarse con otros desarrolladores de la interfaz de usuario y los roles de operaciones relacionados usan todos los días. 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, por lo que no hay respuesta única para todo para lo que debe estar en este tipo de experiencia. Como resultado, no hay ninguna respuesta defacto para un producto preempaquetado que puede poner en marcha y usar tal cual para algo como este hoy.

En el caso de las opciones autohospedadas personalizadas, los marcos de portal web generales no son nuevos y es posible que los equipos de desarrollo ya usen uno en el que pueda acceder. Si intenta sacar algo delante de los usuarios para recibir comentarios anticipados, incluso podría empezar con algo tan sencillo como las páginas de Power Pages de poco código para conectarse a la API de plataforma para desarrolladores común.

Los esfuerzos más recientes del portal para desarrolladores se opinan más. 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 arrancar el árbol de origen de forma muy similar a la de create-react-app para React.js.

Como kit de herramientas del portal, requiere trabajo para ponerse en marcha y personalizar 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 tiene una manera bien definida de traer código nuevo de 1^st y 3^rd party llamado plugins.

Contenido relacionado

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