Partager via


Permettre aux développeurs d’utiliser des garde-fous en libre-service

Le libre-service avec garde-fous est le principe de permettre aux équipes de développement de prendre leurs propres décisions dans un ensemble de paramètres bien définis ou de garde-fous. Les garde-fous sont établis et acceptés par les parties prenantes clés. Les parties prenantes peuvent inclure la sécurité, les opérations, les équipes d’architecture au sein de l’organisation.

Avec des garde-fous en libre-service, les équipes de développement conservent l’autonomie pour prendre des décisions de développement indépendamment. L’automatisation et la stratégie aident les parties prenantes à garantir que la sécurité, la conformité, les opérations, les normes et les coûts sont correctement gérés. L’activation de cette automatisation nécessite une collaboration entre les lignes d’équipe afin que les développeurs, les opérateurs et les spécialistes puissent faire plus, sans sacrifier la gouvernance nécessaire. Les développeurs peuvent ensuite se concentrer sur la fourniture de valeur métier aussi rapidement que possible.

[Nous disons aux développeurs,] ne vous inquiétez pas de la façon dont tout fonctionne, il suffit de les activer ou de les désactiver, de le remplir, de mettre une chaîne dans ce que vous devez faire et c’est essentiellement en libre-service à cet égard où ils ont un fichier readme et ils ont des entrées, des sorties et ils peuvent mettre dans ce qu’ils aiment. - Daniel, Ingénieur cloud, Fortune 500 Media Company

L’objectif de fournir une expérience en libre-service pour vos chemins d’accès pavés est de réduire les risques pour les développeurs tout en offrant une visibilité aux équipes de développement, aux opérations et à la gestion. L’idée est que vous créez une expérience pour une tâche donnée qui a une courbe d’apprentissage minimale, grâce en partie à ses fonctionnalités d’automatisation et d’agrégation de données sous-jacentes. Au-delà des activités telles que l’approvisionnement d’infrastructure, ces expériences peuvent fournir un accès aux fonctionnalités critiques pour l’observabilité, la stratégie, la gestion des incidents, etc. L’idée s’étend à la découverte et au partage d’API internes, de kits sdk, ainsi que d’outils et de services partagés. Ces expériences réduisent la surcharge afin que les équipes de développement puissent se concentrer sur l’exécution des tâches.

Les plateformes de développement internes permettent aux développeurs d’agir comme des clients de vitrine numérique

Les plateformes de développement internes offrent des fonctionnalités similaires aux vitrines numériques métier à entreprise. Les magasins numériques sont intrinsèquement conçus pour aider leurs clients à se servir en libre-service. Ils peuvent gérer plus de débit que les fronts de magasin traditionnels, car ils fournissent des moyens de découvrir et de remplir des éléments intéressants sans avoir à parler à quiconque. À l’aide de cette analogie, les développeurs sont le client et la plateforme de développement interne fournit des expériences en libre-service similaires. Tout comme un détaillant, des opérateurs, des ingénieurs de plateforme et d’autres rôles, configurez ensuite un catalogue d’éléments que les développeurs peuvent demander qui sont conçus pour prendre en charge les garde-fous organisationnels.

Par exemple, vous pouvez considérer un développeur demandant l’accès à un nouvel outil comme s’il faisait une commande numérique de vitrine. À l’instar d’une commande, une fois la demande envoyée, le développeur souhaite être en mesure de suivre la progression et de savoir quand il est terminé. En arrière-plan, la demande doit automatiquement être acheminée vers le fournisseur de traitement approprié pour répondre aux besoins. Vous pouvez considérer l’un de vos systèmes d’intégration et de livraison continus (CI/CD) comme un fournisseur de traitement, un outil GitOps ou une plateforme d’application prescriptive en tant que deuxième, et un outil d’automatisation de flux de travail pour les processus manuels comme troisième. Dans tous les cas, le développeur peut servir en libre-service des éléments à partir d’un catalogue bien défini de la même façon.

Utiliser tout comme modèle de code

L’utilisation de l’infrastructure en tant que code (IaC) par le biais de pipelines de livraison continue (CD) et d’outils GitOps est un élément important de l’activation en libre-service. IaC avec CD vous permet d’utiliser Des graphiques Bicep, Terraform, Helm et d’autres outils pour créer et détruire des ressources cloud à la demande. Étant donné que la configuration de votre infrastructure cloud est gérée comme le code dans un référentiel de code source, vous pouvez appliquer tous les avantages d’un référentiel Git comme la sécurité et l’auditabilité.

L’approvisionnement d’une infrastructure et d’outils courants n’est pas le seul avantage d’une approche IaC. Vous pouvez adapter le modèle de code pour d’autres scénarios, notamment la sécurité en tant que code et stratégie en tant que code (par le biais d’outils tels qu’Azure Policy et Open Policy Agent). À la suite de cette technique, un fichier de configuration, généralement YAML ou JSON, est envoyé (push) dans le référentiel, à quel moment, un flux de travail est déclenché qui traite le fichier. Ces fichiers peuvent être un référentiel d’applications comme dependabot.yml ou CODEOWNERS, ou ils peuvent être conservés dans un référentiel central distinct. Vous pouvez même étendre cela dans vos propres scénarios pour vraiment rendre tout en tant que code (EaC) une réalité.

Les développeurs peuvent référencer chacun de ces modèles EaC avec un catalogue central qui alimente vos expériences en libre-service et encourage les meilleures pratiques par défaut.

Créer des modèles de démarrage appropriés et établir une bonne gouvernance

Dans le développement de logiciels, nous souhaitons l’encapsulation, la modularité et la composabilité lors de la conception d’applications. Vous devez appliquer cette même ligne de réflexion à l’ingénierie de plateforme via la création de modèles. Par exemple, vous pouvez créer et utiliser un ensemble de modèles IaC centralisés sécurisés et réutilisables en tant que blocs de construction pour l’infrastructure.

Nous allons créer des modules pour nos [développeurs]... Donc, au lieu d’avoir à écrire ou à s’inquiéter de l’un des back-end eux-mêmes, tout ce qu’ils doivent faire est de s’inquiéter de leur code d’application. - Daniel, Ingénieur cloud, Fortune 500 Media Company

Combinez des modèles IaC, EaC et d’application dans une solution personnalisée en tant que code (EaC) qui s’étend à d’autres activités telles que la création d’un référentiel de code source, l’amorçage d’un exemple de code ou la configuration et l’exemple de code pour les outils d’observabilité recommandés. Ces modèles IaC, EaC et application peuvent ensuite être stockés ou référencés à partir d’un emplacement central, sécurisé, tel qu’un référentiel, le catalogue dans les environnements de déploiement Azure (ADE) ou Azure Container Registry (ACR) pour le cloud natif.

Lorsque vous démarrez les modèles appropriés sont combinés avec la gouvernance, l’analyse et la configuration de stratégie automatisées, les développeurs restent à droite de la journée 1.

Le graphique de l’ingénierie de la plateforme démarre correctement et conserve la bonne vue d’ensemble du modèle.

Les modèles simplifient le développement avec des pratiques automatisées et sécurisées

Utilisez des modèles d’application pour démarrer vos chemins pavés définis pour plusieurs décisions et actions clés que les développeurs prennent au cours d’un projet. Démarrez les modèles appropriés pour établir des pratiques de développement sécurisées, régies et permettre aux développeurs de commencer rapidement en activant l’automatisation qui fournit l’accès aux outils dont ils ont besoin, configure les pipelines CI/CD, provisionne la pile d’applications et l’infrastructure, et configure un référentiel complet avec le code source de plaque réutilisable qui inclut des KITS SDK ou des références nécessaires aux API.

En faisant référence à ces modèles d’application, d’autres modèles centralisés (par exemple, les modèles IaC), chacun de ces blocs de construction individuels devient des modèles appropriés de leur propre choix. Ces modèles sont centraux pour activer les expériences en libre-service, car ils définissent non seulement les sorties, mais également les options disponibles parmi lesquelles les développeurs choisissent.

Les modèles garantissent la gouvernance, la sécurité et l’optimisation des coûts

Toutefois, les modèles doivent faire plus que simplement démarrer un effort de développement. Ils doivent également établir le contrôle et la gouvernance par le biais d’analyses de stratégie et de sécurité nécessaires pour rester au cours du cycle de vie du projet. Comme autre exemple, les modèles peuvent configurer des règles de protection de branche empêchant les fusions non autorisées en production. Étant donné que les modèles capturent les meilleures pratiques et les configurations courantes, ils constituent l’une des techniques clés pour optimiser les coûts entre les outils, les fournisseurs et les équipes.

Exécuter des campagnes appropriées pour créer une communication bidirectionnelle

Enfin, à mesure que votre confiance dans vos chemins pavés augmente, vous pouvez utiliser les blocs de construction individuels sous-jacents que vous avez assemblés dans vos modèles d’application pour déplacer les applications existantes sur un chemin pavé. Étant donné que vos clients internes verront déjà la valeur de vos chemins pavés pilotés, vous pouvez exécuter une campagne interne pour créer une boîte de dialogue bidirectionnel avec d’autres équipes d’applications. Les développeurs peuvent apprendre à migrer leur application tandis que l’équipe d’ingénierie de plateforme en apprend davantage sur la façon d’améliorer la plateforme pour eux.

Tracer votre propre parcours

Étant donné l’étendue des expériences que vos fonctionnalités en libre-service peuvent couvrir, il est important pour vos efforts d’investissement et planifier et hiérarchiser afin que votre plateforme de développement interne offre une valeur incrémentielle. Le parcours de chaque organisation dans la création de sa plateforme de développement interne est différent et le suivi d’un état d’esprit produit vous aide à cibler les endroits les plus critiques qui nécessitent d’abord des expériences en libre-service.