Appliquer des systèmes d’ingénierie logicielle

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 se construisent à partir des principaux principes de DevOps et DevSecOps afin de réduire la charge cognitive pour tous les utilisateurs.

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. Intègre DevSecOps dans cette boucle avec des pratiques de sécurité en continu 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.

Définissez 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 sont censées gérer, maintenir et payer séparément leurs outils tout en respectant les exigences de conformité. Cela permet d'intégrer de nouveaux outils dans l’écosystème sans causer de perturbations, vous pouvez ainsi évaluer tout ce qui s’écarte pour une inclusion possible dans une voie bien tracée au fil du temps. Comme l'a exprimé un responsable de l’ingénierie de plateforme :

Vous pouvez toujours faire ce que vous voulez, mais dans la direction que nous prenons. 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 affinezz vos chemins pavés, laisser une certaine flexibilité permet aux équipes de fournir des apports et de répondre à toute exigence vraiment unique pour une application donnée sans affecter les autres volets 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, le travail supplémentaire que les équipes assument naturellement les amène à vouloir passer à une voie soutenue avec le temps.

Si vous préférez une stratégie de consolidation, la migration d’applications existantes pourrait nécessiter plus de travail que prévu. Ainsi, vous voudrez probablement vous concentrer sur l'importance de bien commencer dans cet espace et sur les nouveaux projets. Cela fournit votre premier chemin pavé, tandis que tout ce qui est en place est intrinsèquement non pavé. Les équipes de développement sur le chemin non pavé peuvent envisager de changer une fois que votre nouveau chemin pavé montre sa valeur pour 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. Pour déployer des chemins pavés de manière efficace, il faut mettre l'accent sur ce que les équipes en retirent plutôt que sur une adoption forcée. Étant donné que votre plateforme de développement interne se concentre sur la satisfaction de ces mêmes équipes, la pression budgétaire et la rapidité de rentabilisation sur les dirigeants individuels s'occupe du reste. Mettez en place les bonnes campagnes, puis offrez une plateforme pour les conversations bidirectionnelles sur la meilleure façon pour ceux sur un chemin non pavé de 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é devrait consister à établir vos produits principaux d’automatisation pour les développeurs. Ces éléments sont importants lorsque vous commencez à réfléchir à l'activation des capacités d'autoservice pour les développeurs.

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

Si ce n’est pas déjà fait, 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, considérez les illustrations suivantes 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 pouvez apprendre des modèles qui s’appliquent à d’autres scénarios d’automatisation.

Centraliser l’IaC dans un catalogue ou un registre pour accroître l'évolutivité et améliorer la sécurité

Pour gérer et faire évoluer IaC pour plusieurs applications, vous devez publier vos artefacts IaC de manière centralisée afin d’être réutilisés. Par exemple, vous pouvez utiliser des modules Terraform dans un registre, des modules Bicep, des recettes Radius ou des chartes Helm stockées dans un registre natif cloud OCI Artifact, 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 Crossplane prennent en charge les ressources sur 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 et expérimental sont plus structurés que l’utilisation directe de Kubernetes, mais simplifient également l'expérience développeur. Pour en savoir plus sur les avantages et les inconvénients de différents modèles, consultez Décrire les types de services cloud. Quoi qu'il en soit, le fait de référencer une IaC centralisée et gérée plutôt que d'avoir des descriptions complètes dans votre arborescence source présente des avantages significatifs.

Conserver les identités ou secrets nécessaires pour l'approvisionnement de façon à ce que les développeurs ne puissent pas y accéder directement constitue une base essentielle pour 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, le système de livraison continue de votre choix peut vous aider à mettre à jour l'infrastructure de manière sécurisée en séparant les secrets et en obtenant le contenu IaC à partir d'emplacements auxquels les développeurs ne peuvent pas accéder ou qu'ils ne peuvent pas 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 gestion de versions et les processus de pull request ?
• 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, exigeants ou sujets aux erreurs comme cibles potentielles à automatiser en priorité.

Utiliser tout sous forme de code

L’une des bonnes choses sur Git en plus de son omniprésence est qu’elle est destinée à être une source d’informations sécurisée et auditable. Au-delà de l’historique des validations et des contrôles d’accès, des concepts tels que les pull requests et la protection de branches permettent d’établir des réviseurs spécifiques, un historique des conversations et des contrôles automatisés qui doivent être validés avant de procéder à une fusion 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 d’applications, le modèle s’étend à toute infrastructure, outils ou services que vous souhaiterez peut-être approvisionner et configurer, pas seulement ceux liés à une application spécifique. Par exemple, des clusters Kubernetes partagés avec Flux installé, permettant de configurer un service comme DataDog utilisé par plusieurs équipes et applications, ou même de mettre en place 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 ou Terraform, aux graphiques Helm et d’autres formats natifs Kubernetes). Une équipe d’opérations 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 (PRS). Une fois ces PR fusionnées dans la branche principale par ces administrateurs, les mêmes outils CI/CD utilisés pendant le développement d’applications peuvent prendre en charge le traitement des modifications. Considérez l’illustration suivante qui montre les identités GitHub Actions, IaC et 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 faisant des PR n’ont pas d’accès direct à ces secrets, il permet 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, l'adoption d'une approche 'Everything as Code' vous offre une source d'informations pour synthétiser un inventaire de l'infrastructure provisionnée. Votre fournisseur peut également être une bonne source d'informations que vous pouvez exploiter. 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 à l'essor du concept de la politique 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 l’application de stratégies d’infrastructure.

De nombreux produits et projets open source 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 en tant que code étend ces schémas à 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.

Le pull request devient une référence en matière d'expérience utilisateur en libre-service pour divers processus, notamment pour les débuts. Les processus obtiennent naturellement les avantages de sécurité, d’audit et de restauration que Git lui-même fournit 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 désintégration au bureau de support 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 des bureaux de service constituent un risque de sécurité potentiel, car l'accès peut être surprovisionné. Lorsque vous utilisez les équipes comme modèle de code, la combinaison de Git et de RRS 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 source 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 apparaître dans un organigramme et faire appel à des outils ou services propriétaires, ce qui peut compliquer l’intégration ou le départ 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 utilisez 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 requêtes pull. Cela lie les conversations et les participants associés à la demande de validation Git pour l’audit.
• Les chefs d'équipe et les utilisateurs individuels peuvent faire des pull requests pour ajouter ou supprimer des personnes, et les chefs d'équipe de développement ainsi que d'autres rôles peuvent créer de nouvelles équipes en utilisant des pull requests avec un 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 le concept de regroupement de systèmes à un groupe de fournisseurs d’identification pour chaque rôle (par 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 réservoir de données verrouillé avec les résultats (y compris l'association des ID d'équipe système en aval) qui peuvent ensuite être utilisés pour l'un de vos systèmes développé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 la gestion des droits d’utilisation d’Entra, vous pouvez omettre de gérer 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 ou 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 renforcer le modèle tout en tant que code pour activer l'automatisation des activités (ou des travaux) qui n'ont pas de représentation de fichier naturelle ou doivent être automatisés entièrement sans nécessiter de processus de pull request.

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 certains des mêmes avantages en matière de sécurité, d’audit et de visibilité que l'approche de tout en tant que 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 soumette sa première pull request. 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 chefs de développement, les révisions de code peuvent ralentir le développement, car elles peuvent nécessiter une modification de configuration pour les tester puis les inverser une fois la révision effectuée.
• Les membres de l'équipe et les opérateurs doivent également consacrer du temps à développer les rôles connexes au-delà du développement (opérateurs, QA, entreprise, sponsors) pour aider à tester, suivre la progression, former des rôles au sein de l'entreprise et promouvoir le travail accompli par l'équipe.

Une partie de vos sentiers 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 le développement client Windows, le service Windows ou la gestion et la maintenance des applications web basées sur .NET Framework complet.

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 de démarrage qui incluent une configuration correcte

Ce qui est formidable avec le modèle 'everything as code', c'est qu'il peut garder les développeurs sur les chemins pavés que vous avez établis dès 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 peuvent ne pas avoir l’autorisation de créer des référentiels ou d’autres contenus à partir de vos modèles, cela représente aussi une occasion d’utiliser des flux de travail ou des pipelines à déclenchement manuel, paramétrés. Vous pouvez configurer des entrées afin que votre système CI/CD puisse créer diverses choses, allant d'un référentiel à de l'infrastructure, en leur nom.

Rester à droite et se corriger

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 et les 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
• Cadre Sécurisé de Chaîne d'Approvisionnement des Conteneurs
• Architecture de base de référence CI/CD avec Azure Pipelines
• Affiner votre plateforme d’application