Concevoir une fondation en libre-service pour les développeurs

Une fois que vous avez une bonne compréhension de votre cible pour vos systèmes d’ingénierie, vous pouvez créer des expériences de développement en libre-service plus sophistiquées. Une expérience en libre-service pour les développeurs repose sur des concepts, des modèles et des composants.

Bien que vous n’ayez peut-être pas besoin de tout ce qui est décrit ici dans votre organisation aujourd’hui, vous devez garder ces concepts à l’esprit si vous créez un produit personnalisé ou évaluez des produits associés. Votre modèle d’expérience libre-service pour les développeurs peut être constitué d’une combinaison de produits maison, hors-service et open source. Les produits ou les boîtes à outils du portail open source comme Backstage.io peuvent utiliser des termes différents pour certains éléments du modèle décrit ci-dessous, mais le modèle peut toujours vous aider à vous orienter.

Automatiser les flux de travail, agréger des données, démarrer facilement et développer progressivement

Votre objectif est d’activer le libre-service avec des garde-fous par le biais de l’exécution et de l’approvisionnement des tâches contrôlées et régies, ainsi que la visibilité centralisée. Les domaines les plus utiles pour se concentrer sont ceux qui sont fastidieux ou sont des choses que le développeur ne peut pas faire eux-mêmes en raison de la complexité ou des autorisations. Ce dernier article est important pour vous permettre de suivre le principe du privilège minimum sans forcer les développeurs à travers un processus manuel de service desk.

Bien que vous puissiez choisir d’étendre votre suite DevOps pour répondre à ces besoins, vous devrez probablement prendre en charge plusieurs plateformes d’applications au fil du temps, et les outils et processus spécifiques qui les prennent en charge devront également changer. Le principal problème est que vos normes sont une cible mobile. Comme l’a indiqué un spécialiste de l’ingénierie de plateforme :

Les difficultés impliquent la normalisation ... et traiter avec 'abandonware'... La normalisation n’est souvent pas obtenue en raison d’une interruption potentielle des processus automatisés et de la tâche fastidieuse d’identification des modifications nécessaires. - Martin, Ingénieur DevOps, Grande Société Logistique

Le passage rapide à une norme nouvelle ou mise à jour n’est généralement pas réalisable et l’abandon des processus existants crée des risques. Votre organisation peut déjà utiliser plusieurs suites DevOps ou différentes combinaisons d’outils individuels et de services de développement par scénario. Même avec une équipe centrale et une solution standard, à mesure que vos besoins en libre-service augmentent, la variabilité est inévitable. Par conséquent, vous voudrez activer l’expérimentation contrôlée où les équipes désignées peuvent essayer de nouvelles technologies, stratégies de déploiement, et ainsi de suite, suivie d’une adoption délibérée et d’un déploiement incrémentiel.

En règle générale, les expériences en libre-service appartiennent à deux catégories principales : l’automatisation et l’agrégation de données.

Bien que l’agrégation de données crée de bonnes expériences utilisateur, l’automatisation est plus importante :

L’automatisation est essentielle et sera aimée par tout le monde. L’agrégation [Données] est secondaire. – Peter, responsable de l’ingénierie de plateforme, société multinationale tech

Dans votre parcours d’ingénierie de plateforme, vous avez identifié des problèmes potentiellement résolus par l’automatisation. Au-delà de la réduction de la charge cognitive et de l’il des développeurs, l’automatisation peut également vous aider à garantir que les applications sont connectées aux meilleurs outils et services pour les opérations, la sécurité et d’autres rôles pour effectuer leur travail.

Toutefois, si vous travaillez avec plusieurs systèmes pour piloter votre automatisation, un certain niveau d’agrégation de données est utile pour vous aider à suivre les requêtes automatisées et les résultats associés. Vous pouvez commencer par établir une liaison à des systèmes externes pour répondre à d’autres besoins ou pour obtenir des détails d’extraction. L’agrégation et la visibilité des données sont également importantes pour l’audit, la gouvernance et la réduction des déchets (exemple : environnements inutilisés).

L’automatisation de l’approvisionnement d’infrastructure peut être effectuée à l’aide d’intégrations système, mais vous pouvez également déclencher et faciliter un processus de flux de travail manuel qui semble automatisé pour le développeur. Cela est utile dans les premières étapes de votre plateforme, pour les nouveaux produits que vous apportez dans votre écosystème, ou dans les domaines que vous n’avez pas ou ne pouvez pas automatiser à l’aide d’un système (par exemple, attribution de licence logicielle). Avec la conception appropriée, vous pouvez commencer par un processus manuel facilité par quelque chose comme Power Automate que vous basculez vers un flux entièrement automatisé au fil du temps. Par conséquent, conception d’une automatisation dès le début.

Commencez par réutiliser des investissements existants tels que vos systèmes d’ingénierie ou un portail interne, puis créez des CLIs, des pages web de base, ou même Power Pages, Power BI ou des tableaux de bord Microsoft Fabric , et développez en fonction du besoin. Avoir une API cohérente que l’expérience utilisateur utilise peut ensuite vous aider à prendre en charge plusieurs interfaces au fil du temps à mesure que vos besoins et préférences changent.

Composants de plateforme libre-service pour les développeurs : API, graphe, orchestrateur, fournisseurs et métadonnées

Considérez les bases du libre-service du développeur :

Comme l’illustre l’illustration, les composants suivants constituent le cœur du concept d’une fondation en libre-service pour les développeurs :

Ces composants fondamentaux vous permettent d’utiliser et d’échanger différents blocs de construction au fil du temps.

Dois-je créer tout cela pour commencer ?

Non. Tout d’abord, il s’agit d’un modèle conceptuel pour vous aider à réfléchir à ce qu’une base comme celle-ci devrait être en mesure de faire une fois qu’elle a été effectuée. Deuxièmement, les spécificités de l’implémentation sont moins importantes ici, étant donné que l’API de la plateforme de développement devient votre interface clé. Votre implémentation initiale peut commencer à utiliser des interfaces et des classes dans votre code pour les différentes couches décrites ou mixées dans d’autres produits. Vous pouvez également omettre des aspects, car votre développement client vous indique qu’il s’agit simplement d’une priorité inférieure. Commencez par ce que vous avez et développez.

API de plateforme de développement

Vous devez définir une API de plateforme de développement pour agir comme contrat de votre système. L’API est utilisée par différentes interfaces utilisateur pour activer l’accès aux données ou le provisionnement de lecteurs et d’autres actions.

Cette API agit comme une couche d’authentification et de sécurité importante en limitant l’accès aux API sous-jacentes brutes dans d’autres systèmes à des données et opérations plus spécifiques, contrôlées. L’API fournit l’accès à sa propre représentation d’un profil utilisateur, au rôle de haut niveau d’un utilisateur au sein de la plateforme (membre de l’équipe, administrateur, etc.) et aux identificateurs de système du fournisseur d’identité principal. Pour plus d’informations, consultez Utilisateurs et équipes.

Fournisseurs de plateforme de développement

Compte tenu de l’étendue d’une plateforme de développement interne, créez ou identifiez des systèmes qui suivent un modèle de fournisseur extensible pour introduire des fonctionnalités dans l’API. L’idée est que des fonctionnalités clés telles que l’automatisation et l’agrégation de données sont fournies en interagissant avec des composants enfichables avec des interfaces bien définies. Ce couplage libre vous aide à connecter ce dont vous avez besoin de manière incrémentielle et améliore la facilité de maintenance, car vous pouvez tester les fonctionnalités indépendamment du reste de la base.

Il s’agit également d’un moyen important d’activer une mentalité de source interne évolutive à votre plateforme. En règle générale, les efforts d’approvisionnement interne autour de l’ingénierie de plateforme ne parviennent pas à gagner en traction en raison de défis liés à la maintenance continue. D’autres équipes peuvent être prêtes à contribuer aux fonctionnalités, mais sont moins susceptibles d’être prêtes à maintenir et tester quelque chose au sein du cœur de votre plateforme. À l’inverse, toute équipe centralisée dispose d’une capacité limitée pour maintenir le code fourni ou même passer en revue les demandes de tirage. Le concept d’un fournisseur de plateforme de développement atténue cette tension en autorisant le code écrit de manière indépendante à « plug-in » à des fonctionnalités principales au sein de votre fondation en libre-service pour les développeurs. Bien que vous deviez gérer soigneusement les fournisseurs que vous utilisez, passez en revue le code du fournisseur et limitez la surface d’exposition accessible par un fournisseur donné dans votre plateforme de développement, une approche enfichable peut vous aider à effectuer davantage d’efforts en mettant à l’échelle l’ensemble de l’organisation.

Concepts clés du fournisseur de plateforme de développement

Entités

Le concept d’une entité est quelque chose qu’un développeur ou un autre système de votre plateforme de développement interne doit suivre, mettre à jour, présenter ou agir. Les entités peuvent avoir des relations entre elles qui, lorsqu’elles sont prises ensemble, composent un graphique qui fournit des informations critiques sur les éléments de votre plateforme de développement interne. Les fournisseurs de plateforme de développement peuvent ensuite générer des entités pour activer les fonctionnalités principales, notamment :

• Présentation des ressources/ environnements provisionnés en externe ou des API disponibles pour la découverte et l’utilisation
• Exposition de relations pour l’analyse des dépendances, l’analyse d’impact, la découverte, etc.
• Surfacing maintenance/information de propriété pour la découverte et la collaboration
• Présentation de données supplémentaires pour une utilisation dans les expériences utilisateur

Encapsuler cette fonctionnalité dans une interface de fournisseur de plateforme de développement bien définie simplifie l’intégration et le test, permet un déploiement indépendant et permet aux développeurs en dehors de l’équipe principale de la plateforme de développement interne de contribuer et de gérer des fournisseurs. Cela est important dans les grandes organisations ou divisionnaires où tous les outils, services ou plateformes ne sont pas gérés de manière centralisée, mais l’organisation plus large souhaite toujours partager des fonctionnalités. Donc, même si vous ne vous dirigez pas vers le bas au départ, c’est quelque chose à penser à long terme.

Propriétés communes

Chaque entité doit avoir un ensemble de propriétés communes pour permettre à la Fondation de les gérer. Voici quelques propriétés à prendre en compte :

• Identificateur unique
• Nom
• Fournisseur d’origine
• Associations facultatives pour :
  • Utilisateur propriétaire
  • Équipe propriétaire
  • Autres entités

Les propriétés de l’utilisateur et de l’équipe sont importantes pour trois raisons : le contrôle d’accès en fonction du rôle (RBAC), la découverte et l’agrégation de données (telles que les résumés au niveau de l’équipe). La création dans RBAC à partir du début est essentielle à la sécurité et à la croissance de votre plateforme de développement interne au fil du temps. Étant donné que le développement est un sport d’équipe, découvrir qui parler d’une entité deviendra rapidement essentiel pour la réutilisation, le support et l’interne.

Entités communes et spécifiques au fournisseur

Vous devez également être en mesure d’établir un ensemble d’entités courantes de haut niveau normalisées que plusieurs fournisseurs peuvent générer. Par exemple :

• Environnements
• Ressources
• API
• Référentiels
• Composants
• outils

Celles-ci doivent généralement être à un niveau élevé, comme vous le feriez dans le contexte du modèle C4 ou dans la plupart des diagrammes de composants de haut niveau. Par exemple, pour un environnement, vous n’avez pas besoin d’inclure les détails de la topographie de l’infrastructure interne : vous avez simplement besoin d’informations suffisantes pour répertorier et associer différents environnements conceptuels de plusieurs fournisseurs dans la même expérience utilisateur. L’entité peut pointer vers des niveaux de détail inférieurs en dehors du système plutôt que d’essayer de consommer tout. Ils fournissent des points de départ pour la découverte qui sont essentiels à l’activation de l’agrégation de données au fil du temps.

D’autres seront spécifiques à un cas d’usage ou un fournisseur particulier. Vous devez donc réfléchir à la façon dont vous pouvez prendre en charge un ensemble croissant de types d’entités au fil du temps.

Modèles

Le concept d’un modèle dans ce contexte diffère de l’idée des entités dans lesquelles elles sont destinées à générer une action. Les exemples de scénarios incluent l’approvisionnement d’infrastructure, la création d’un référentiel et d’autres processus de longue durée. Ces modèles doivent également être disponibles via des fournisseurs de plateforme de développement extensibles et doivent prendre en charge les mêmes propriétés communes que les entités, y compris les associations d’entités.

Toutefois, ils peuvent également définir les entrées requises, que le système ou l’utilisateur spécifié soient nécessaires pour effectuer l’action. Celles-ci peuvent aller de n’importe quel nom à la ressource à des ajouts facultatifs.

Voici quelques exemples de modèles :

• Modèles IaC (Infrastructure-as-code)
• Modèles d’application (Démarrer à droite) ou référentiels de modèles
• Générer des modèles de pipeline /flux de travail
• Pipeline de déploiement / modèles de flux de travail
• Scripts paramétrables
• Flux Power Automate paramétrables (exemple : flux cloud déclenché par une requête HTTP)
• Modèles de courrier électronique

Comme les entités, les modèles peuvent inclure des propriétés spécifiques au fournisseur.

Chaque modèle peut avoir une représentation différente propre au fournisseur. Ces modèles peuvent aller de Terraform ou ARM à Helm Charts, à des workflows GitHub Actions paramétrés ou à Azure Pipelines, à des scripts simples ou à des formats personnalisés.

Les détails réels du modèle sous-jacent n’ont pas nécessairement besoin d’être stockés de manière centralisée. Ils peuvent exister dans différents référentiels, registres ou catalogues. Par exemple, vous pouvez utiliser des référentiels de modèles GitHub pour vos modèles d’application, tandis que vos modèles IaC peuvent exister dans un référentiel de catalogue restreint que les développeurs peuvent accéder indirectement via quelque chose comme les environnements de déploiement Azure. D’autres modèles IaC peuvent être stockés dans un registre d’artefacts OCI, comme les graphiques Helm. Dans d’autres cas, le modèle peut être une référence à un point de terminaison HTTP paramétrable. Un fournisseur de plateforme de développement doit fournir suffisamment d’informations sur chaque type de modèle afin qu’il puisse être référencé et toutes les options exposées pour une utilisation dans les expériences utilisateur. Toutefois, les modèles eux-mêmes peuvent être hébergés dans l’emplacement le plus naturel pour vos cas d’usage.

Les ingénieurs de plateforme ou les experts d’un domaine particulier écrivent des modèles, puis les partagent avec les équipes de développement à réutiliser. La centralisation de l’utilisation de ces modèles par le biais d’un système permet aux développeurs en libre-service et crée des garde-fous qui permettent d’appliquer la conformité aux normes ou stratégies organisationnelles. En savoir plus sur ce problème lorsque nous abordons l’orchestrateur de plateforme de développement en un peu.

Graphique de la plateforme de développement

Vous pouvez considérer un graphique de plateforme de développement comme quelque chose vous permet d’associer des entités et des modèles de plusieurs fournisseurs à un graphique pouvant faire l’objet d’une recherche. Toutefois, les données réelles pour les entités n’ont pas nécessairement besoin d’être conservées directement dans une base de données spécifique à un graphique. Au lieu de cela, les interactions avec les fournisseurs peuvent être mises en cache avec les métadonnées nécessaires pour qu’elles s’intègrent toutes.

Le graphique est puissant lorsqu’il est utilisé avec des entités communes que plusieurs fournisseurs peuvent contribuer. Par exemple, une liste d’API peut provenir d’un produit tel qu’Azure API Center, mais vous pouvez également souhaiter alimenter automatiquement les déploiements et les environnements à partir de vos systèmes de déploiement continu. Au fil du temps, vous pouvez basculer entre différents systèmes de déploiement ou même prendre en charge plusieurs systèmes de déploiement. Tant que chaque système de déploiement dispose d’un fournisseur de plateforme de développement, vous devez toujours être en mesure de créer l’association.

Chacune de vos expériences utilisateur qui s’accumulent à partir de ce graphique peut ensuite tirer parti d’une API commune pour alimenter la découverte, la recherche, la gouvernance, etc. Un orchestrateur de plateforme de développement peut ensuite tirer parti de ce même graphique afin que toutes les actions effectuées par un fournisseur de plateforme de développement contribuent automatiquement les entités disponibles à la même API.

Orchestrateur de plateforme de développement

Un orchestrateur de plateforme de développement permet aux développeurs ou aux systèmes de créer des demandes pour effectuer une action à l’aide d’un modèle. Elle n’effectue pas ces actions elle-même, mais coordonne plutôt avec un moteur de tâches, un moteur de flux de travail ou un autre orchestrateur pour le faire. Il s’agit de l’un des éléments critiques que vous souhaitez être sûr est une partie de votre fondation en libre-service. Il permet aux développeurs de créer des demandes avec un modèle ou d’exécuter une action sans autorisation directe. En outre, contrairement au concept de ci ou de CD, ces actions n’ont pas besoin d’être liées au code source de l’application.

Vous pouvez utiliser GitHub Actions, Azure Pipelines ou un autre moteur de flux de travail en tant qu’orchestrateur. Il s’agit d’un point de départ raisonnable, mais vous pouvez avoir un peu d’abstraction en place pour permettre à différents types de modèles d’utiliser différents moteurs sous-jacents. Cela peut être utile pour quelques raisons :

• Tout d’abord, vous voudrez probablement être en mesure de choisir différents moteurs d’exécution de flux de travail et de tâche au fil du temps sans avoir à flasher. En autorisant plusieurs moteurs, vous pouvez migrer au fil du temps ou simplement utiliser le nouveau moteur vers de nouvelles actions sans avoir d’impact sur les anciennes.
• Certains processus que vous souhaitez aider à orchestrer peuvent nécessiter des étapes manuelles initialement, même si vous envisagez de les automatiser entièrement ultérieurement.
• D’autres actions peuvent cibler des rôles en dehors de l’équipe de développement, comme les comptes payables ou un administrateur de licence. Les moteurs à faible code comme Power Automate fonctionnent souvent bien pour ces rôles.
• D’autres actions peuvent être gérées par le biais de requêtes HTTP simples où l’épinglage d’un élément aussi capable que GitHub Actions ou Azure Pipelines n’est pas nécessaire ou rentable à mettre à l’échelle.

Heureusement, l’expansion de l’idée d’un fournisseur de plateforme de développement pour couvrir les étapes de déclenchement et de suivi des étapes d’automatisation peut fournir cette abstraction nécessaire. Considérez l’illustration suivante :

Voici le concept général :

• Les modèles peuvent éventuellement spécifier un ensemble d’entrées que l’utilisateur peut entrer. Lorsqu’un développeur déclenche une action particulière, il choisit un modèle (même s’il n’est pas décrit de cette façon) et entre les entrées.
• Une référence aux entrées associées au modèle devient une requête dans l’API de la plateforme de développement.
• Une fois qu’une demande est envoyée, un composant de routage et de gestion des demandes au sein de l’orchestrateur commence à suivre le cycle de vie de la requête. Le modèle de routage et de gestion des composants de requête dans la requête vers le fournisseur de plateforme de développement où le modèle provient.
• Le fournisseur de plateforme de développement effectue ensuite les étapes appropriées pour son implémentation.
• (Facultatif) Le fournisseur de la plateforme de développement met à jour l’état de la demande lors de l’exécution de l’action.
• Une fois la demande remplie, le fournisseur de plateforme de développement peut retourner un ensemble d’entités à ajouter/mettre à jour dans le graphe de la plateforme de développement. Il peut s’agir d’entités spécifiques à un fournisseur ou communes.

Si vous le souhaitez, pour prendre en charge des interactions plus avancées, les fournisseurs de plateforme de développement peuvent appeler directement l’API de plateforme de développement pour obtenir plus d’entités en tant qu’entrées ou même demander une autre action associée.

Choisissez un fournisseur de plateforme de développement qui utilise une tâche générale ou un moteur de flux de travail. Plus précisément, vous voulez créer un pont entre ce que vous avez mis en place dans le cadre de l’application de systèmes d’ingénierie logicielle. Un moteur général d’exécution de flux de travail ou de tâche à investir est un système CI/CD.

Exemple utilisant GitHub Actions ou Azure Pipelines

Examinons brièvement le fonctionnement d’un fournisseur de plateforme de développement GitHub Actions ou Azure Pipelines en tant que fournisseur de plateforme de développement.

Pour GitHub Actions, la clé de ce travail est qu’un fournisseur de plateforme de développement peut se connecter à l’instance GitHub spécifiée et utiliser l’API REST Actions pour déclencher un événement de distribution de flux de travail pour déclencher une exécution de flux de travail. Chaque flux de travail peut prendre en charge un ensemble d’entrées en ajoutant une configuration workflow_dispatch au fichier YAML du flux de travail. Les déclencheurs Azure DevOps sont similaires et vous pouvez également utiliser l’API Pipeline Azure DevOps pour les exécutions. Vous verrez probablement les mêmes fonctionnalités dans d’autres produits.

Ces flux de travail ou pipelines n’ont pas besoin d’être dans les référentiels de code source de l’application. Le concept serait de tirer parti de ce fait pour faire quelque chose comme ceci :

• Les ingénieurs de plateforme ou les membres de l’équipe DevOps peuvent gérer les flux de travail / pipelines dans un ou plusieurs référentiels centraux auxquels les développeurs n’ont pas accès, mais le fournisseur de plateforme de développement est configuré pour l’utiliser. Ce même référentiel peut inclure des scripts et des extraits de code IaC que les workflows/pipelines utilisent.
• Pour permettre à ces flux de travail/pipelines d’interagir avec le système en aval approprié, les opérations ou d’autres membres de votre équipe d’ingénierie de plateforme peuvent ajouter les secrets nécessaires dans le référentiel central. Consultez la documentation GitHub Actions et Azure DevOps pour plus d’informations sur la façon de procéder, ou vous pouvez choisir de centraliser les secrets à l’aide de quelque chose comme Azure Key Vault.
• Ces flux de travail /pipelines peuvent ensuite suivre un modèle où ils publient toutes les entités résultantes en tant qu’artefact de build/déploiement (documents GitHub, documents Azure DevOps).
• Pendant une exécution, le fournisseur de plateforme de développement peut alors observer l’état du workflow/pipeline et mettre à jour l’état du cycle de vie dans l’orchestrateur jusqu’à ce qu’il soit terminé. Par exemple, vous pouvez utiliser des hooks web avec GitHub Actions et des hooks de service avec Azure Pipelines pour suivre les mises à jour.
• Une fois terminé, le fournisseur peut ensuite utiliser l’artefact publié pour l’inclusion dans le graphique de plateforme de développement en fonction des besoins.

Enfin, vous pouvez ensuite configurer ce fournisseur de plateforme de développement pour générer un ensemble de modèles dans le graphique de la plateforme de développement qui référence le référentiel et le flux de travail/pipeline appropriés, ainsi que les entrées d’une tâche donnée.

La grande chose à propos de l’utilisation d’un système CI/CD est qu’ils sont souvent configurés pour prendre en charge l’exécution de CLIs arbitraires, de sorte que vous n’avez pas besoin d’une première classe, une intégration unique pour tout ce que vous faites. Vous pouvez ajouter ces éléments au fil du temps en fonction des besoins.

La plupart des éléments décrits dans cet exemple appliquent la façon dont d’autres types de fournisseurs peuvent fonctionner. Il est également important de noter que l’utilisation de GitHub Actions ou d’Azure Pipelines dans ce contexte ne nécessite pas que vous les utilisiez également pour vos pipelines CI/CD réels.

Autres exemples

Voici quelques exemples d’autres types de fournisseurs de plateforme de développement qui peuvent traiter des modèles.

Bien que vous n’ayez peut-être pas besoin de tous ces fournisseurs pour commencer, vous pouvez voir comment l’extensibilité par le biais d’un fournisseur de plateforme de développement peut aider vos fonctionnalités d’automatisation à croître au fil du temps.

Utilisateurs et équipes

L’ingénierie de plateforme est intrinsèquement une affaire multi-système. Il est donc important de planifier la façon dont une fondation libre-service doit gérer les problèmes les plus difficiles liés à l’intégration de ces systèmes ensemble. Voici une stratégie pour relever les défis courants liés à l’identité, aux utilisateurs et aux équipes.

Établir le concept d’une équipe au-delà d’un seul groupe de fournisseurs d’identité

À mesure que votre parcours d’ingénierie de plateforme se poursuit, vous constaterez probablement que les groupes de fournisseurs d’identité sont parfaits pour gérer l’appartenance, mais que plusieurs groupes doivent vraiment se réunir pour former le concept d’une équipe pour le contrôle d’accès en fonction du rôle (RBAC) et l’agrégation de données.

Dans le contexte de l’ingénierie de plateforme, nous définissons une équipe comme un ensemble de personnes dans différents rôles qui travaillent ensemble. Pour l’agrégation des données, l’idée d’une équipe multi-rôle est essentielle pour alimenter la découverte et les informations de cumul dans des emplacements tels que les tableaux de bord de création de rapports. En revanche, un groupe est un concept de fournisseur d’identité général pour un ensemble d’utilisateurs et est conçu avec l’idée d’ajouter plusieurs personnes à un rôle spécifique, plutôt que d’une autre façon. Avec RBAC, une équipe peut donc se rapporter à plusieurs groupes de fournisseurs d’identité par le biais de rôles différents.

La source des données de votre équipe peut provenir de quelques endroits différents. Par exemple, si vous utilisez les équipes en tant que modèle de code (TaC), un fournisseur de plateforme de développement peut surveiller les modifications de fichiers dans un référentiel et les mettre en cache dans un magasin de métadonnées d’équipe et de profil utilisateur. Vous pouvez également vous intégrer directement à un projet Azure Centre de développement qui dispose déjà de ces constructions RBAC principales disponibles.

Établir un modèle pour l’intégration à des systèmes en aval au niveau de l’équipe ou de l’utilisateur

Bien que certains outils/services de développement et d’exploitation intègrent et utilisent directement les concepts du fournisseur d’identité, de nombreux développeurs et opérations l’extraitnt dans leur propre représentation d’un groupe ou d’un utilisateur (même avec l’authentification unique). Au-delà de l’activation de l’accès entre les outils, cette réalité peut également poser des problèmes d’agrégation de données. Plus précisément, vous pouvez constater que les API dans le système en aval utilisent leurs propres identificateurs plutôt que les identificateurs de fournisseur d’identité (par exemple : l’ID d’objet dans Entra ID n’est pas directement utilisé). Cela rend le filtrage et l’association des données au niveau de l’utilisateur ou de l’équipe difficiles, sauf si vous pouvez mapper entre différents ID.

Résoudre les différences au niveau de l’équipe et du groupe

Les modèles tels que TaC peuvent vous permettre de stocker et d’accéder aux relations entre l’équipe ou les identificateurs de groupe de chaque système afin de pouvoir les mapper entre eux. Pour récapitulation, un référentiel Git sécurisé et auditable devient la source d’une équipe et les demandes de tirage fournissent une interface utilisateur contrôlée pour effectuer des mises à jour. Les systèmes CI/CD peuvent ensuite mettre à jour les systèmes en aval et conserver les relations d’identificateur associées pour l’équipe utilisée pour le faire.

Par exemple, cela permet de stocker les relations suivantes dans les appels d’API :

Si vous préférez utiliser une source de données autre que des fichiers dans un référentiel, ce même concept général peut être appliqué à l’aide de l’orchestrateur de plateforme de développement pour accomplir la même chose. Dans ce modèle, un fournisseur de plateforme de développement pour la source des données d’équipe peut déclencher un événement de mise à jour d’équipe que tous les autres fournisseurs reçoivent et agissent selon les besoins.

Résoudre les problèmes liés à l’ID utilisateur

Un autre défi lié à l’accès aux données et à l’agrégation est les différences d’ID utilisateur. Comme dans le cas de l’équipe, si vous utilisez une intégration de système à système pour interroger des données sur un utilisateur, vous ne pouvez pas supposer que l’ID natif des fournisseurs d’identité (par exemple, ID d’objet pour Entra ID) prend en charge une API donnée. Là encore, le stockage d’un mappage pour un ID utilisateur qui accède aux données via l’API de plateforme de développement peut vous aider. Par exemple, considérez GitHub :

Pour chaque système, si vous pouvez effectuer une recherche d’un id utilisateur d’un autre système via une API sans jeton d’utilisateur, un fournisseur de plateforme de développement donné peut générer ce mappage à la volée. Dans certains cas, cela peut se compliquer, car vous devrez peut-être effectuer cette opération en bloc et mettre en cache les résultats de référence pour maintenir les performances.

Revenir à l’utilisation de plusieurs jetons utilisateur

Dans les cas où les fournisseurs doivent accéder aux données au niveau de l’utilisateur sans moyen d’effectuer une traduction d’ID utilisateur qui fonctionne, l’API de la plateforme de développement peut être configurée pour gérer plusieurs jetons utilisateur. Par exemple :

• L’API de la plateforme de développement peut prendre en charge un cache de jetons utilisateur spécifiques au fournisseur à utiliser avec des systèmes en aval.
• Toutes les interactions avec un fournisseur donné déclenchées par l’API incluraient dans le jeton utilisateur du fournisseur s’il est disponible.
• Pour gérer le cas où aucun jeton utilisateur n’était disponible, le fournisseur déclencherait un flux OAuth pour en obtenir un.
• Pour commencer, l’API de la plateforme de développement transmet un URI d’authentification pour un flux OAuth avec un URI de redirection qui a été transmis au fournisseur. L’URI passé inclurait un code nonce/usage unique.
• L’API retourne ensuite une réponse « non authentifiée » avec l’URI.
• Toute expérience utilisateur peut ensuite utiliser cet URI pour piloter le flux d’authentification approprié dans un navigateur.
• Une fois la redirection effectuée, la plateforme de développement reçoit le jeton utilisateur nécessaire et la met en cache pour une référence ultérieure, ainsi que l’ID utilisateur.
• Le client peut ensuite réessayer l’appel d’API, ce qui réussirait ensuite.

Ce concept décrit un moyen de gérer l’authentification compliquée, car vous pouvez réutiliser les ID dans la mesure du possible et n’avez pas besoin de gérer des URI de redirection distincts par système en aval.

Utiliser des liens approfondis avec le contexte vers des outils et des systèmes de création de rapports

Jusqu’à ce stade, nous parlons de l’aspect d’automatisation de l’espace de problème. Cela peut aller beaucoup de temps, car votre interface utilisateur peut utiliser des valeurs dans les entités retournées lors de l’automatisation pour créer des liens approfondis dans d’autres systèmes pour l’équipe.

Même s’il n’est pas lié à l’automatisation, les fournisseurs de plateforme de développement peuvent émettre n’importe quel type de besoin d’entité. Toutefois, vous ne souhaitez généralement pas importer toutes les données détaillées sur l’ensemble de votre plateforme de développement interne dans votre graphe de plateforme de développement. Les tableaux de bord dans les solutions d’observabilité telles que Grafana, Prometheus, DataDog ou l’intelligence du code dans les produits tels que SonarQube et les fonctionnalités natives dans les suites DevOps telles que GitHub et Azure DevOps sont tous très capables. Au lieu de cela, la meilleure approche consiste souvent à créer des liens profonds dans ces autres systèmes. Vos entités peuvent fournir suffisamment d’informations pour créer des liens sans contenir directement d’informations détaillées telles que le contenu du journal.

Pour les cas où vous souhaitez regrouper et résumer des données entre les outils ou avoir besoin de générer des métriques personnalisées, les solutions de création de rapports Power BI ou Microsoft Fabric peuvent être votre prochain port d’appel. Pour fusionner des données d’équipe, vous pouvez vous connecter à la base de données de votre Fondation ou passer par une API de plateforme de développement. Par exemple, comme décrit dans Plan et hiérarchisation, un endroit où vous souhaiterez peut-être qu’un tableau de bord personnalisé mesure le succès de votre plateforme de développement interne.

Soyez sélectif avec chaque expérience supplémentaire que vous créez

Bien qu’il puisse être attrayant de recréer des fonctionnalités existantes dans un portail commun, gardez à l’esprit que vous devez également la gérer. Il s’agit du domaine où le suivi d’un état d’esprit produit est important. Les interfaces de style de tableau de bord sont faciles à concevoir et à comprendre, mais vos développeurs peuvent trouver plus de valeur ailleurs.

Cela dit, le modèle ici vous permet d’utiliser des données agrégées dans le graphique de la plateforme de développement pour créer des expériences utilisateur personnalisées. Les entités doivent disposer d’une prise en charge intégrée afin qu’elles puissent être liées à un utilisateur ou à une équipe. Cela permet à votre API de plateforme de développement d’étendre la sortie (ainsi qu’à l’aide de l’indexation et de la mise en cache).

Toutefois, même si vous devez créer une expérience utilisateur personnalisée plutôt qu’un lien profond, l’extraction de toutes les données dans votre graphe de plateforme de développement n’est généralement pas la meilleure approche. Par exemple, considérez une situation dans laquelle vous souhaiterez peut-être afficher les journaux dans votre expérience utilisateur qui dispose déjà d’une maison bien définie et gérée. Utilisez des informations dans les entités associées pour aider votre expérience utilisateur à collecter des informations directement à partir de systèmes en aval.

Pour commencer, vous devrez peut-être utiliser une intégration système à système pour vous connecter, mais une fois que vous avez implémenté l’un des modèles décrits dans les utilisateurs et les équipes, vous pouvez utiliser les ID d’utilisateur/d’équipe stockés ou les jetons d’authentification utilisateur si nécessaire.

Voici quelques exemples d’expériences courantes à prendre en compte :

Expériences utilisateur

Différents rôles de votre organisation ont des outils ou des services qui représentent un centre de gravité pour leur travail quotidien. L’extraction de ces systèmes peut rendre difficile pour de nouvelles expériences utilisateur en dehors de ces centres de gravité pour gagner de la traction. Dans un monde parfait, les développeurs, les opérations et d’autres rôles peuvent continuer à travailler dans un environnement qui leur est logique , souvent ceux qu’ils utilisent déjà.

À l’esprit, la planification de plusieurs interfaces utilisateur à mesure que vous progressez dans votre parcours d’ingénierie de plateforme est une bonne idée. Cela peut également permettre de démarrer des interfaces simples, de prouver de la valeur et de croître vers des interfaces plus complexes au fur et à mesure que le besoin se produit.

Intégrer ce que vous avez

Si vous avez lu les articles Appliquer des systèmes d’ingénierie logicielle et affiner la plateforme d’applications, vous avez probablement identifié les systèmes que vous souhaitez continuer à utiliser. Dans les deux cas, évaluez si vous pouvez améliorer et étendre ce que vous avez avant de commencer à créer de nouvelles expériences à partir de zéro. (Demandez-vous que les utilisateurs réagissent mieux à une autre nouvelle expérience utilisateur ou à une version améliorée de quelque chose qu’ils ont maintenant ?)

Certains des outils, utilitaires ou applications web que vous souhaitez continuer à utiliser seront personnalisés, et ce sont de bons candidats à une amélioration. Mais n’oubliez pas de faire attention si vos outils et services favoris ont un modèle d’extensibilité que vous pouvez utiliser. Vous aurez beaucoup d’avantages à partir de là. Cela peut éliminer les maux de tête de maintenance et de sécurité et vous permettre de vous concentrer sur le problème que vous essayez de résoudre

Par exemple, vous pouvez étendre les surfaces suivantes que vous utilisez déjà :

• Éditeurs et IDE.
• Votre suite DevOps.
• Les CLI sont de plus en plus extensibles.
• Environnements faibles/sans code comme Power Pages.

Chacun peut fournir un meilleur point de départ pour un rôle donné que quelque chose que vous avez configuré à partir de zéro, car ils sont des centres de gravité existants. L’utilisation d’une API de plateforme de développement commune en tant que base de référence vous permet d’échanger des éléments, d’expérimenter et de changer au fil du temps.

Envisagez d’utiliser des extensions d’éditeur web pour créer un portail de développement

Si vous recherchez une expérience web pour les développeurs, gardez à l’esprit qu’une tendance récente est les versions web des éditeurs et des IDE. Beaucoup, comme ceux qui utilisent VS Code, ont une prise en charge d’extension. Avec VS Code, tout ce que vous créez pour ces expériences web se traduit localement pour bénéficier d’un double avantage.

Au-delà des services tels que GitHub Codespaces, vscode.dev est une version web gratuite de l’éditeur VS Code sans calcul, mais inclut la prise en charge de certains types d’extensions , y compris ceux qui utilisent des vues web pour l’interface utilisateur personnalisée.

Même si vos développeurs n’utilisent pas VS Code lui-même, les modèles d’expérience utilisateur sont bien connus et se trouvent dans d’autres outils de développement. L’utilisation de vscode.dev peut fournir une base web pratique et familière pour les expériences des développeurs en plus de l’outil lui-même.

Ceux-ci peuvent agir en tant que portail axé sur les développeurs dans un formulaire familier qui peut également se traduire par une utilisation locale.

ChatOps

Une autre opportunité qui est souvent ignorée consiste à implémenter une interface ChatOps. Étant donné l’augmentation des interfaces basées sur les conversations en raison de l’augmentation des produits IA tels que ChatGPT et GitHub Copilot, les commandes d’action ou les commandes obliques peuvent fournir un moyen utile de déclencher des flux de travail d’automatisation, vérifier l’état, etc. Étant donné que la plupart des plateformes CI/CD d’application prennent en charge les systèmes tels que Microsoft Teams, Slack ou Discord, il peut s’agir d’un moyen naturel d’intégrer à un autre développeur d’interface utilisateur et aux rôles d’opérations connexes utilisés chaque jour. En outre, tous ces produits ont un modèle d’extensibilité.

Investir dans un nouveau portail des développeurs

En supposant que vous n’avez pas de portail ou d’interface existant que vous souhaitez utiliser comme base, vous pouvez décider de créer un nouveau portail de développement. Considérez cela comme une destination plutôt qu’un point de départ. Si vous n’avez pas encore d’équipe de développement qui travaille avec vous, le démarrage de cet effort est le temps de le faire. Chaque organisation est différente, donc il n’y a pas de réponse unique pour ce qui doit être dans ce genre d’expérience. Par conséquent, il n’existe aucune réponse defacto pour un produit prépackagené que vous pouvez faire tourner et utiliser tel quel pour quelque chose comme ceci aujourd’hui.

Pour les options auto-hébergées personnalisées, les infrastructures du portail web général ne sont pas nouvelles, et vos équipes de développement peuvent déjà utiliser celle dans laquelle vous pouvez tirer parti. Si vous essayez de sortir quelque chose devant vos utilisateurs pour obtenir des commentaires précoces, vous pouvez même commencer par quelque chose aussi simple que les pages Power Pages à faible code pour se connecter à l’API de plateforme de développement commune.

Les efforts plus récents du portail des développeurs sont plus opinionés. Par exemple, Backstage.io est un kit de ressources du portail des développeurs personnalisé initialement conçu pour répondre aux besoins de Spotify. Il inclut une interface CLI pour aider à démarrer votre arborescence source, comme create-react-app pour React.js.

En tant que kit de ressources du portail, il nécessite un travail de mise à jour et de personnalisation nécessitant une connaissance de TypeScript, de Node.js et de React. Cependant, la grande chose à ce sujet est que, en tant que kit de ressources, vous pouvez changer presque tout. Il dispose également de son propre catalogue logiciel et mécanisme de création de modèles, mais son utilisation n’est pas nécessaire, et il a un moyen bien défini d’apporter un nouveau code tiers 1^st et 3^rd party appelé plug-ins.

Contenu connexe

• Power Pages
• Backstage.io
• Appliquer des systèmes d’ingénierie logicielle