Appliquer des systèmes de génie logiciel

Améliorer le libre-service du développeur doit être l’un des premiers problèmes que vous abordez dans votre parcours d’ingénierie de plateforme.

L’une des méthodes les plus simples pour commencer à activer des expériences en libre-service automatisées consiste à réutiliser vos systèmes d’ingénierie existants. Non seulement ces systèmes sont familiers avec vous et vos clients internes, mais ils peuvent activer un large éventail de scénarios d’automatisation même si l’expérience utilisateur initiale n’est pas jolie.

Cet article fournit des conseils pour appliquer vos systèmes d’ingénierie afin d’aborder un plus large éventail de scénarios en libre-service, ainsi que des détails sur la façon d’encapsuler les meilleures pratiques dans des modèles qui vous aident à commencer correctement et à rester correct.

Évaluer vos pratiques DevOps et DevSecOps de base

Les systèmes d’ingénierie sont un aspect essentiel de votre plateforme de développement interne. Les plateformes de développement internes s’accumulent à partir des principaux locataires de DevOps et DevSecOps afin de réduire la charge cognitive pour tous les participants.

DevOps combine le développement et les opérations pour unir les personnes, les processus et la technologie dans la planification des applications, le développement, la livraison et les opérations. Elle vise à améliorer la collaboration entre des rôles historiquement enloqués comme le développement, les opérations informatiques, l’ingénierie de qualité et la sécurité. Vous établissez une boucle continue entre le développement, le déploiement, la surveillance, l’observation et les commentaires. Couches DevSecOps dans cette boucle avec des pratiques de sécurité continues tout au long du processus de développement d’applications.

Les sections suivantes se concentrent sur les améliorations plus directement attribuées au mouvement d’ingénierie de plateforme : chemins pavés, approvisionnement automatique d’infrastructure (en plus du déploiement d’applications), configuration de l’environnement de codage, ainsi que l’approvisionnement en libre-service et la configuration d’outils, de ressources d’équipe et de services qui ne font pas directement partie de la boucle de développement d’application.

Établir vos chemins pavés souhaités

Si vous avez déjà plusieurs ensembles d’outils qui composent vos systèmes d’ingénierie, une décision anticipée consiste à déterminer si vous souhaitez les consolider dans le cadre de vos efforts initiaux d’ingénierie de plateforme ou si vous prendrez en charge une constellation de différents outils dès le départ. La définition d’un ensemble de chemins pavés dans cette constellation d’outils est plus efficace et offre un niveau de flexibilité accru.

Lorsque vous commencez à passer à un état d’esprit produit, pensez aux systèmes d’ingénierie au sein de ces chemins pavés comme composés d’outils gérés de manière centralisée en tant que service aux équipes de développement. Les équipes ou divisions individuelles au sein de votre organisation peuvent ensuite s’écarter, mais elles seront censées gérer, maintenir et payer séparément leurs outils tout en respectant les exigences de conformité. Cela permet de nourrir de nouveaux outils dans l’écosystème sans interruption, car vous pouvez évaluer tout ce qui s’écarte pour l’inclusion possible dans un chemin pavé au fil du temps. Comme un responsable de l’ingénierie de plateforme l’a placé :

Vous pouvez toujours faire votre propre chose, mais le faire dans une direction que nous allons... vous pouvez changer ce que vous voulez, mais cela devient votre responsabilité. Vous êtes propriétaire des changements - vous possédez les couteaux tranchants. - Mark, responsable de l’ingénierie de plateforme, Grande Entreprise multinationale européenne de vente au détail

Étant donné qu’un objectif clé pour l’ingénierie de plateforme est de passer à un état d’esprit de produit où vous fournissez de la valeur à vos clients internes, cette approche de constellation fonctionne généralement mieux qu’un mandat top-down. Lorsque vous établissez et affinez vos chemins pavés, laissant une certaine flexibilité permet aux équipes de fournir des entrées et de répondre à toutes les exigences vraiment uniques pour une application donnée sans affecter d’autres membres de l’organisation. Cela conduit à un ensemble de chemins entièrement pavés, dorés, tandis que d’autres ne sont que partiellement pavés. Dans les cas où il n’existe aucune exigence unique, les équipes de développement de travail supplémentaires prennent naturellement la décision de vouloir passer à un parcours pris en charge au fil du temps.

Si vous préférez une stratégie de consolidation, la migration d’applications existantes peut être plus efficace que prévu. Par conséquent, vous souhaiterez probablement vous concentrer sur l’aspect de départ approprié de cet espace et vous concentrer sur les nouveaux projets. Cela vous donne votre premier chemin pavé, tandis que tout ce qui existe est intrinsèquement non préparé. Les équipes de développement sur le chemin non préparé envisageront ensuite de passer une fois que votre nouveau chemin pavé affiche sa valeur à l’organisation. À ce stade, vous pouvez exécuter une campagne appropriée pour obtenir tout le monde sur votre état souhaité via une communication bidirectionnelle, car les équipes de développement considèrent cela comme un avantage plutôt qu’une taxe. Pendant la campagne, les équipes d’ingénierie de plateforme peuvent se concentrer sur l’aide aux équipes de migration, tandis que les équipes de développement fournissent des commentaires sur la façon de améliorer les chemins pavés.

Quoi qu’il en soit, évitez d’imposer l’utilisation de vos chemins pavés. La façon la plus efficace de déployer des chemins pavés est de souligner ce que les équipes sortent d’eux plutôt que par l’adoption forcée. Étant donné que votre plateforme de développement interne se concentre sur la réalisation de ces mêmes équipes, la pression budgétaire et le temps à valeur sur les dirigeants individuels prend soin du reste. Obtenez les bonnes campagnes, puis fournissez une avenue pour les conversations bidirectionnel sur la meilleure voie pour ceux sur un chemin nonpaved pour basculer.

Utiliser les outils d’automatisation des développeurs pour améliorer le libre-service pour vos chemins pavés

Une partie de la création de votre premier chemin pavé doit être d’établir vos principaux produits d’automatisation des développeurs. Il est important de commencer à réfléchir à l’activation des fonctionnalités en libre-service des développeurs.

Activer le provisionnement automatique de l’infrastructure d’application pendant la livraison continue

S’il n’est pas déjà implémenté, les problèmes que vous avez identifiés pendant votre planification pointent probablement vers des problèmes que l’intégration continue (CI) et la livraison continue (CD) peuvent aider à résoudre. Des produits tels que GitHub Actions, Azure DevOps, Jenkins, ainsi que des solutions GitOps basées sur extraction telles que Flux ou Argo CD existent dans cet espace. Vous pouvez commencer à utiliser ces rubriques dans le centre de ressources Microsoft DevOps.

Même si vous avez déjà implémenté un moyen de déployer en continu votre application dans une infrastructure existante, vous devez envisager d’utiliser l’infrastructure en tant que code (IaC) pour créer ou mettre à jour l’infrastructure d’application nécessaire dans le cadre de votre pipeline CD.

Par exemple, tenez compte de ces illustrations qui montrent deux approches qui utilisent GitHub Actions pour mettre à jour l’infrastructure et déployer dans Azure Kubernetes Service : une à l’aide de déploiements basés sur push et d’un déploiement par extraction (GitOps).

Ce que vous choisissez est piloté par votre ensemble de compétences IaC existant et les détails de votre plateforme d’application cible. L’approche GitOps est plus récente et est populaire parmi les organisations qui utilisent Kubernetes comme base pour leurs applications, tandis que le modèle basé sur extraction vous offre actuellement la plus grande flexibilité en fonction du nombre d’options disponibles pour celui-ci. Nous nous attendons à ce que la plupart des organisations utilisent un mélange des deux. Quelle que soit la connaissance des pratiques iaC, vous allez apprendre des modèles qui s’appliquent à d’autres scénarios d’automatisation.

Centraliser l’iaC dans un catalogue ou un registre pour mettre à l’échelle et améliorer la sécurité

Pour gérer et mettre à l’échelle IaC entre les applications, vous devez publier vos artefacts IaC de manière centralisée pour la réutilisation. Par exemple, vous pouvez utiliser des modules Terraform dans un registre, des modules Bicep, des recettes Radius ou des graphiques Helm stockés dans un registre d’artefacts OCI natifs cloud, comme Azure Container Registry (ACR), DockerHub ou le catalogue dans les environnements de déploiement Azure (ADE). Pour GitOps et Kubernetes, l’API de cluster (et les implémentations telles que CAPZ) peut vous permettre de gérer des clusters de charge de travail Kubernetes, tandis que les définitions de ressources personnalisées telles qu’Azure Service Operator peuvent fournir une prise en charge supplémentaire pour d’autres types de ressources Azure, d’autres outils tels que la prise en charge de plusieurs clouds. Celles-ci vous permettent d’utiliser des graphiques Helm centralisés ou courants dans un ensemble plus large de scénarios, comme ACR.

La centralisation d’IaC améliore la sécurité en vous donnant un meilleur contrôle sur les personnes pouvant effectuer des mises à jour, car elles ne sont plus stockées avec du code d’application. Il y a moins de risques de rupture accidentelle causée par une modification accidentelle lors d’une mise à jour du code lorsque des experts, des opérations ou des ingénieurs de plateforme apportent des modifications nécessaires. Les développeurs bénéficient également de ces blocs de construction, car ils n’ont pas besoin de créer eux-mêmes des modèles IaC complets et bénéficient automatiquement des meilleures pratiques encodées.

Le format IaC que vous choisissez dépend de votre jeu de compétences existant, du niveau de contrôle dont vous avez besoin et du modèle d’application que vous utilisez. Par exemple, Azure Container Apps (ACA) et le projet d’incubation Radius OSS récent sont plus avisés que l’utilisation directe de Kubernetes, mais simplifient également l’expérience des développeurs. Le module de formation Décrire les types de services cloud peut vous aider à comprendre les avantages et inconvénients des différents modèles. Quel que soit le fait de référencer l’IaC centralisée et gérée plutôt que d’avoir des définitions complètes dans votre arborescence source présente des avantages significatifs.

Conserver les identités d’approvisionnement ou les secrets nécessaires de manière à ce que les développeurs ne puissent pas y accéder directement dans les blocs de construction de base de la gouvernance. Par exemple, considérez cette illustration sur la séparation des rôles que vous pouvez obtenir à l’aide d’Environnements de déploiement Azure (ADE).

Ici, les ingénieurs de plateforme et d’autres spécialistes développent iaC et d’autres modèles et les placent dans un catalogue. Les opérations peuvent ensuite ajouter des identités managées et des abonnements par « type d’environnement » et affecter des développeurs et d’autres utilisateurs autorisés à les utiliser pour l’approvisionnement.

Les développeurs ou votre pipeline CI/CD peuvent ensuite utiliser Azure CLI ou Azure Developer CLI pour provisionner une infrastructure préconfigurée et contrôlée sans même avoir accès à l’abonnement ou aux identités sous-jacents requis pour le faire. Que vous utilisiez quelque chose comme ADE ou non, votre système de livraison continu de votre choix peut vous aider à mettre à jour l’infrastructure de manière sécurisée et sécurisée en séparant les secrets et l’approvisionnement de contenu IaC à partir des emplacements que les développeurs ne peuvent pas accéder ou modifier eux-mêmes.

Activer le libre-service dans les scénarios au-delà de la livraison continue de l’application

Bien que les concepts CI et CD soient liés au développement d’applications, la plupart des éléments que vos clients internes souhaitent approvisionner ne sont pas directement liés à une application particulière. Il peut s’agir d’une infrastructure partagée, de la création d’un référentiel, d’outils d’approvisionnement, etc.

Pour comprendre où cela peut vous aider, réfléchissez à l’emplacement où vous disposez actuellement de processus manuels ou de support technique. Pour chacun d’eux, réfléchissez à ces questions :

• À quelle fréquence ce processus se produit-il ?
• Le processus est-il lent, sujet aux erreurs ou nécessite-t-il un travail important à réaliser ?
• Ces processus sont-ils manuels en raison d’une étape d’approbation requise ou simplement d’un manque d’automatisation ?
• Les approbateurs sont-ils familiarisés avec les systèmes de contrôle de code source et les processus de demande de tirage ?
• Quelles sont les exigences d’audit pour les processus ? Ces conditions diffèrent-elles des exigences d’audit de votre système de contrôle de code source ?
• Existe-t-il des processus que vous pouvez commencer par ce qui est moins risqué avant de passer à des processus plus complexes ?

Identifiez les processus fréquents, élevés ou sujets aux erreurs en tant que cibles potentielles à automatiser en premier.

Utiliser tout comme modèle de code

L’une des bonnes choses sur git en plus de son omniprésence est qu’il est destiné à être une source d’informations sécurisée et auditable. Au-delà de l’historique des validations et des contrôles d’accès, les concepts tels que les demandes de tirage et la protection des branches permettent d’établir des réviseurs spécifiques, un historique des conversations et des vérifications automatisées qui doivent passer avant de fusionner dans la branche principale. Lorsqu’ils sont combinés avec des moteurs de tâches flexibles comme ceux trouvés dans les systèmes CI/CD, vous disposez d’une infrastructure d’automatisation sécurisée.

L’idée derrière tout en tant que code est que vous pouvez transformer presque n’importe quoi en fichier dans un dépôt Git sécurisé. Différents outils ou agents connectés au référentiel peuvent ensuite lire le contenu. Le traitement de tout comme le code facilite la répétabilité grâce à la création de modèles et simplifie le libre-service du développeur. Passons en revue plusieurs exemples de fonctionnement.

Appliquer des modèles IaC à n’importe quelle infrastructure

Bien que l’IaC ait gagné en popularité pour automatiser la livraison des applications, le modèle s’étend à toute infrastructure, outils ou services que vous souhaiterez peut-être approvisionner et configurer, et non seulement ceux liés à une application spécifique. Par exemple, les K8 partagés avec des clusters avec Flux installé, l’approvisionnement d’un élément tel que DataDog utilisé par plusieurs équipes et applications, ou même la configuration de vos outils de collaboration préférés.

La façon dont cela fonctionne est que vous disposez d’un référentiel centralisé distinct et sécurisé qui héberge une série de fichiers qui représentent ce qui doit être provisionné et configuré (dans ce cas, quoi que ce soit de Bicep, Terraform, aux graphiques Helm et d’autres formats natifs Kubernetes). Une équipe d’exploitation ou un autre ensemble d’administrateurs possèdent le référentiel, et les développeurs (ou systèmes) peuvent envoyer des demandes de tirage. Une fois ces demandes fusionnées dans la branche principale par ces administrateurs, les mêmes outils CI/CD utilisés pendant le développement d’applications peuvent lancer le traitement des modifications. Considérez cette illustration qui utilise GitHub Actions et iaC et les identités de déploiement hébergées dans les environnements de déploiement Azure :

Si vous utilisez déjà une approche GitOps pour le déploiement d’applications, vous pouvez également réutiliser ces outils. La combinaison d’outils comme Flux et Azure Service Operator vous permet de développer en dehors de Kubernetes :

Dans les deux cas, vous disposez d’une source d’informations entièrement managée, reproductible et auditable, même si ce qui est produit n’est pas destiné à une application. Comme pour le développement d’applications, tous les secrets ou identités managées dont vous avez besoin sont stockés dans le moteur de pipeline/workflow ou dans les fonctionnalités natives d’un service d’approvisionnement.

Étant donné que les personnes qui effectuent les demandes de tirage n’ont pas d’accès direct à ces secrets, elles permettent aux développeurs de lancer en toute sécurité des actions qu’ils n’ont pas l’autorisation directe de faire eux-mêmes. Cela vous permet d’adhérer au principe du privilège minimum tout en offrant aux développeurs une option en libre-service.

Suivre l’infrastructure provisionnée

Lorsque vous commencez à mettre à l’échelle cette approche, réfléchissez à la façon dont vous souhaitez suivre l’infrastructure provisionnée. Votre dépôt Git est une source de vérité pour la configuration, mais ne vous indique pas les URI et informations d’état spécifiques sur ce que vous avez créé. Toutefois, le suivi d’une approche de code vous donne une source d’informations permettant de synthétiser un inventaire de l’infrastructure approvisionnée. Votre provisionneur peut également être une bonne source de ces informations que vous pouvez tirer parti. Par exemple, les environnements de déploiement Azure incluent des fonctionnalités de suivi d’environnement auxquelles les développeurs ont une visibilité.

Pour en savoir plus sur le suivi sur différentes sources de données, consultez Concevoir une fondation en libre-service pour les développeurs.

Appliquer la sécurité en tant que code et stratégie en tant que modèles de code

Bien que l’infrastructure d’approvisionnement soit utile, assurez-vous que ces environnements sont sécurisés et suivent généralement les stratégies de votre organisation est tout aussi important. Cela a conduit à la montée du concept de « stratégie en tant que code ». Ici, les fichiers de configuration d’un référentiel de contrôle de code source peuvent être utilisés pour effectuer des opérations telles que l’analyse de sécurité ou appliquer des stratégies d’infrastructure.

De nombreux produits et projets code source ouvert ont adopté cette approche, notamment Azure Policy, Open Policy Agent, GitHub Advanced Security et GitHub CODEOWNERS, entre autres. Lorsque vous sélectionnez votre infrastructure d’application, vos services ou outils, veillez à évaluer la façon dont ils prennent en charge ces modèles. Pour plus d’informations sur l’affinement de votre application et de votre gouvernance, consultez Affiner votre plateforme d’application.

Utiliser tout en tant que code pour vos propres scénarios

Tout comme le code étend ces modèles à une grande variété de tâches d’automatisation et de configuration au-delà de l’IaC. Il peut prendre en charge non seulement la création ou la configuration de n’importe quel type d’infrastructure, mais également la mise à jour des données ou le déclenchement de flux de travail dans n’importe quel système en aval.

La demande de tirage devient une bonne expérience utilisateur libre-service de base pour différents processus, en particulier lorsque vous démarrez. Les processus obtiennent naturellement les avantages de sécurité, d’audit et de restauration git lui-même, et les systèmes impliqués peuvent également changer au fil du temps sans avoir d’impact sur l’expérience utilisateur.

Teams en tant que code

L’un des exemples d’application de tout en tant que code à vos propres scénarios est celui des équipes en tant que modèle de code. Les organisations appliquent ce modèle pour normaliser l’appartenance à l’équipe et, dans certains cas, les droits d’utilisation des outils/services pour les développeurs sur un large éventail de systèmes. Ce modèle élimine les processus manuels d’intégration et de bureau de service qui sont pilotés par la nécessité pour les développeurs et les opérateurs de systèmes d’accéder à leurs propres concepts de regroupement, d’utilisateur et d’accès. Les processus manuels de service desks constituent un risque de sécurité potentiel, car il est possible de surprovisionner l’accès. Lorsque vous utilisez les équipes comme modèle de code, la combinaison de requêtes git et pull peut activer le libre-service à partir d’une source de données auditable.

Pour obtenir un exemple de variation mature et étendue de ce modèle, consultez le billet de blog de GitHub sur la façon dont ils gèrent les droits d’utilisation. GitHub a également open sourcer leur implémentation sophistiquée des droits d’utilisation pour vous permettre d’essayer ou d’adopter. Bien que le billet de blog décrit tous les droits des employés, vous pouvez appliquer les équipes en tant que concept de code aux scénarios d’équipe de développement plus limités. Ces équipes de développement peuvent ne pas être représentées dans un organigramme d’employé du tout et impliquer des outils ou services propriétaires qui peuvent compliquer l’intégration ou le désintérissement des membres de l’équipe.

Voici un résumé d’une variante simplifiée de cette idée qui utilise un système CI/CD et des groupes de fournisseurs d’identité pour coordonner les mises à jour :

Dans cet exemple :

• Chaque système impliqué a été configuré pour utiliser votre fournisseur d’identité (par exemple, Microsoft Entra ID) pour l’authentification unique (SSO).
• Vous allez utiliser des groupes de fournisseurs d’identité (par exemple, des groupes Entra) entre les systèmes pour gérer l’appartenance par rôle afin de réduire la complexité et de gérer l’audit centralisé.

À un niveau élevé, voici comment fonctionne ce modèle :

• Un référentiel Git centralisé verrouillé a un ensemble de fichiers (généralement YAML) qui représentent chaque équipe abstraite, l’appartenance des utilisateurs et les rôles d’utilisateur associés. Les propriétaires ou les approbateurs pour les modifications d’équipe peuvent également être stockés dans ce même emplacement (par exemple, via CODEOWNERS). La référence à un utilisateur dans ces fichiers est le fournisseur d’identité, mais ce référentiel agit comme source de vérité pour ces équipes (mais pas pour les utilisateurs).
• Toutes les mises à jour de ces fichiers sont effectuées via des demandes de tirage. Cela lie les conversations et les participants associés à la demande de validation Git pour l’audit.
• Les prospects et les utilisateurs individuels peuvent rendre les demandes de tirage (PR) à ajouter/supprimer des personnes, et les prospects de développement et d’autres rôles peuvent créer de nouvelles équipes à l’aide d’un fichier d’équipe avec un nouveau fichier d’équipe à partir d’un modèle.
• Chaque fois qu’une demande de tirage est fusionnée en principal, un système CI/CD lié au référentiel met ensuite à jour le système du fournisseur d’identité et tous les systèmes en aval selon les besoins.

Plus précisément, le système CI/CD :

• Utilise l’API système de fournisseur d’identité appropriée pour créer ou mettre à jour un groupe de fournisseurs d’identité par rôle avec exactement les individus du fichier (pas plus, pas moins).
• Utilise des API pour chaque système en aval pour lier ces systèmes à un concept de regroupement de systèmes à un groupe de fournisseurs d’identification pour chaque rôle (exemple : GitHub et Azure DevOps). Cela peut entraîner une relation un-à-plusieurs entre votre équipe et le système en aval pour représenter un rôle.
• (Facultatif) Utilise des API pour chaque système en aval pour implémenter la logique d’autorisations liée au mécanisme de regroupement du système.
• Utilise une API pour mettre à jour un magasin de données verrouillé avec les résultats (y compris l’association des ID d’équipe système en aval) qui peuvent ensuite être consommés pour l’un de vos systèmes intégrés en interne. Vous pouvez également stocker des associations pour différentes représentations système des ID d’utilisateur pour le même compte/utilisateur du fournisseur d’identité ici si nécessaire.

Si votre organisation utilise déjà quelque chose comme Entra Entitlement Management, vous pouvez omettre la gestion de l’appartenance au groupe à partir de ce modèle.

Vos besoins et stratégies peuvent modifier les spécificités, mais le modèle général peut être adapté à n’importe quel nombre de variantes. Tous les secrets nécessaires à l’intégration à tous les systèmes en aval sont conservés dans le système CI/CD (par exemple, dans GitHub Actions, Azure Pipelines) ou dans quelque chose comme Azure Key Vault.

Utiliser des flux de travail manuels ou déclenchés en externe, paramétrés

Certains des problèmes liés au libre-service que vous identifiez peuvent ne pas être propices à l’utilisation de fichiers dans Git. Vous pouvez également avoir une interface utilisateur que vous souhaitez utiliser pour piloter l’expérience en libre-service.

Heureusement, la plupart des systèmes CI, y compris GitHub Actions et Azure Pipelines, ont la possibilité de configurer un flux de travail avec des entrées que vous pouvez ensuite déclencher manuellement par le biais de leurs INTERFACES utilisateur ou CLIs. Étant donné que les développeurs et les rôles d’opérations connexes sont probablement déjà familiarisés avec ces expériences utilisateur, les déclencheurs manuels peuvent augmenter tout en tant que modèle de code pour activer l’automatisation des activités (ou des travaux) qui n’ont pas de représentation de fichier naturelle ou doivent être entièrement automatisés sans nécessiter de processus de demande de tirage.

Votre système CI peut vous permettre de choisir de déclencher ces flux de travail ou pipelines à partir de vos propres expériences utilisateur via une API. Pour GitHub Actions, la clé de ce travail est l’API REST Actions pour déclencher un événement de répartition de flux de travail pour déclencher une exécution de 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. Qu’il soit déclenché manuellement ou via une API, 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. Par exemple, il s’agit de la façon dont les boîtes à outils du portail comme Backstage.io interagissent avec GitHub Actions.

Le flux de travail ou le système de travail de votre système CI/CD effectue sans aucun doute le suivi des activités, signale l’état et contient des journaux détaillés que les développeurs et les équipes d’exploitation peuvent utiliser pour voir ce qui s’est passé. De cette façon, il présente certaines des mêmes avantages en matière de sécurité, d’audit et de visibilité que le modèle de code. Toutefois, une chose à garder à l’esprit est que toutes les actions effectuées par ces workflows ou pipelines ressemblent à une identité système (par exemple, un principal de service ou une identité managée dans Microsoft Entra ID) sur des systèmes en aval.

Vous aurez une visibilité sur les personnes qui initient des demandes dans votre système CI/CD, mais vous devez évaluer s’il s’agit d’informations suffisantes et vous assurer que vos paramètres de rétention CI/CD sont conformes à vos exigences d’audit pour les cas où ces informations sont critiques.

Dans d’autres cas, les outils que vous intégrez peuvent avoir leurs propres mécanismes de suivi sur lesquels vous pouvez vous appuyer. Par exemple, ces outils CI/CD disposent presque toujours de plusieurs mécanismes de notification tels que l’utilisation d’un canal Microsoft Teams ou Slack , ce qui vous permet de conserver toute personne envoyant une demande d’obtention de mises à jour d’état et le canal fournit un enregistrement informel de ce qui s’est passé. Ces mêmes moteurs de flux de travail sont souvent déjà conçus pour s’intégrer à des outils d’exploitation afin d’étendre davantage l’utilité de ces modèles.

En résumé, vous pouvez implémenter une automatisation à l’aide de fichiers stockés dans un référentiel de contrôle de code source grâce à la flexibilité des outils CI/CD et à leurs expériences utilisateur prêtes à l’emploi. Pour voir comment les plateformes de développement internes peuvent utiliser cette approche comme point de départ sans compromettre les fonctionnalités plus sophistiquées au fil du temps, consultez Conception d’une fondation en libre-service pour les développeurs.

Automatiser la configuration des environnements de codage de développeur

Un autre problème courant dans les systèmes d’ingénierie est l’amorçage et la normalisation de l’environnement de codage pour les développeurs. Voici quelques-uns des problèmes courants que vous pouvez entendre dans ce domaine :

• Dans certains cas, il peut prendre des semaines pour qu’un développeur puisse accéder à sa première demande de tirage. Il s’agit d’un domaine problématique lorsque vous transférez des développeurs entre des équipes de fonctionnalités et des projets assez fréquemment (par exemple, dans les organisations matricielles), besoin de monter en puissance les sous-traitants ou d’être en équipe qui est en phase d’embauche.
• L’incohérence entre les développeurs et vos systèmes CI peut entraîner des problèmes fréquents de « fonctionnement sur mon ordinateur », même pour les membres expérimentés de l’équipe.
• L’expérimentation et la mise à niveau des infrastructures, des temps d’exécution et d’autres logiciels peuvent également briser les environnements de développement existants et entraîner une perte de temps pour déterminer exactement ce qui s’est passé.
• Pour les prospects de développement, les révisions de code peuvent ralentir le développement, étant donné qu’elles peuvent nécessiter une modification de configuration pour les tester et les annuler une fois la révision terminée.
• Les membres de l’équipe et les opérateurs doivent également passer du temps à accélérer les rôles connexes au-delà du développement (opérateurs, qa, entreprise, sponsors) pour aider à tester, voir la progression, former des rôles d’entreprise et évangéliser le travail que l’équipe fait.

Partie de vos chemins pavés

Pour vous aider à résoudre ces problèmes, réfléchissez à la configuration d’outils et d’utilitaires spécifiques dans le cadre de vos chemins pavés bien définis. La configuration de l’ordinateur développeur de scripts peut vous aider et vous pouvez réutiliser ces mêmes scripts dans votre environnement CI. Toutefois, envisagez de prendre en charge les environnements de développement conteneurisés ou virtualisés en raison des avantages qu’ils peuvent fournir. Ces environnements de codage peuvent être configurés à l’avance sur les spécifications de votre organisation ou du projet.

Remplacement de station de travail et ciblage de Windows

Si vous ciblez Windows ou que vous souhaitez effectuer une virtualisation complète des stations de travail (outils clients et paramètres du système d’exploitation hôte en plus des paramètres spécifiques au projet), les machines virtuelles fournissent généralement les meilleures fonctionnalités. Ces environnements peuvent être utiles pour tout ce qui se trouve entre le développement client Windows et le service Windows ou la gestion et la gestion et la gestion des applications web .NET full framework.

Virtualisation de l’espace de travail et ciblage de Linux

Si vous ciblez Linux, envisagez une option de virtualisation d’espace de travail. Ces options se concentrent moins sur le remplacement de votre bureau de développeur et plus sur les espaces de travail spécifiques au projet ou à l’application.

Créer des modèles d’application appropriés qui incluent une configuration appropriée

La grande chose à propos de tout ce que le modèle de code est qu’il peut garder les développeurs sur les chemins pavés que vous avez établis depuis le début. S’il s’agit d’un défi pour votre organisation, les modèles d’application peuvent rapidement devenir un moyen essentiel de réutiliser les blocs de construction pour favoriser la cohérence, promouvoir la normalisation et codifier les meilleures pratiques de votre organisation.

Pour commencer, vous pouvez utiliser quelque chose de aussi simple qu’un référentiel de modèles GitHub, mais si votre organisation suit un modèle monorepo , cela peut être moins efficace. Vous pouvez également créer des modèles qui aident à configurer quelque chose qui n’est pas directement lié à une arborescence source d’application. Au lieu de cela, vous pouvez utiliser un moteur de création de modèles comme cookiecutter, Yeoman ou quelque chose comme Azure Developer CLI (azd) qui, en plus de la création de modèles et de la configuration ci/CD simplifiée, fournit également un ensemble pratique de commandes de développeur. Étant donné que l’interface CLI développeur Azure peut être utilisée pour piloter la configuration de l’environnement dans tous les scénarios, elle s’intègre aux environnements de déploiement Azure pour fournir une sécurité améliorée, un iaC intégré, le suivi de l’environnement, la séparation des préoccupations et la configuration simplifiée du CD.

Une fois que vous avez un ensemble de modèles, les prospects de développement peuvent utiliser ces outils en ligne de commande ou d’autres expériences utilisateur intégrées pour générer leur contenu pour leurs applications. Toutefois, étant donné que les développeurs n’ont peut-être pas l’autorisation de créer des référentiels ou d’autres contenus à partir de vos modèles, il s’agit également d’une autre occasion d’utiliser des flux de travail/pipelines paramétrés manuellement. Vous pouvez configurer des entrées que votre système CI/CD crée tout ce qui se passe d’un référentiel à une infrastructure en son nom.

Rester à droite et se faire droit

Toutefois, pour faciliter la mise à l’échelle, ces modèles d’application doivent référencer les blocs de construction centralisés le cas échéant (par exemple, les modèles IaC ou même les flux de travail/pipelines CI/CD). En fait, le traitement de ces blocs de construction centralisés comme leur propre forme de modèles de démarrage pourrait être une stratégie efficace pour résoudre certains des problèmes que vous avez identifiés.

Chacun de ces modèles individuels peut être appliqué non seulement aux nouvelles applications, mais également aux modèles existants que vous envisagez de mettre à jour dans le cadre d’une campagne appropriée pour déployer des recommandations mises à jour ou améliorées. Mieux encore, cette centralisation vous aide à conserver les applications nouvelles et existantes pour vous permettre d’évoluer ou d’étendre vos meilleures pratiques au fil du temps.

Contenu du modèle

Nous vous recommandons de prendre en compte les domaines suivants lors de la création de modèles.

Contenu connexe

• Centre de ressources DevOps de Microsoft
• Sécurité de la chaîne d’approvisionnement de conteneurs
• CI/CD pour les applications AKS avec GitHub Actions et Gitflow