Automatisation de plateforme et DevOps pour l’accélérateur de zone d’atterrissage Gestion des API
Cet article fournit des considérations et des recommandations relatives à la conception pour l’automatisation de plateforme et DevOps lors de l’utilisation de l’accélérateur de zone d’atterrissage Gestion des API. L’automatisation de plateforme et DevOps offrent des opportunités pour moderniser votre approche du déploiement de l’environnement avec des options d’infrastructure en tant que code.
En savoir plus sur la zone de conception de l’automatisation de plateforme et de DevOps.
Remarques relatives à la conception
- Chaque équipe d’API peut envoyer des mises à jour à partir de son propre référentiel de développeur vers sa propre instance de développement Gestion des API.
- Qu’est-ce que cela signifie du point de vue de la planification réseau ?
- Qu’en est-il des autres environnements de non-production (AQ, mise en lots, etc.) ?
- Réfléchissez à la manière dont les produits et les autres entités doivent être gérés ou versionnés, en particulier si plusieurs équipes utilisent les mêmes produits.
- Envisagez la stratégie de test pour les API et les stratégies.
Recommandations de conception
- Une équipe centrale (par exemple, une équipe d’administration Gestion des API) gère l’environnement de production Gestion des API.
- Les configurations Gestion des API sont représentées comme des modèles Resource Manager ou des modèles Bicep ou Terraform équivalents, et un état d’esprit d’infrastructure en tant que code doit être adopté.
- L’équipe d’administration Gestion des API publiera les modifications de configuration apportées à l’environnement de production Gestion des API à partir d’un référentiel Git (référentiel d’éditeur) appartenant à l’équipe d’administration Gestion des API.
- Chaque équipe d’API individuelle peut dupliquer le référentiel d’éditeur pour disposer de son propre référentiel de développeur à partir duquel elle pourra travailler.
- Chaque équipe peut utiliser l’APIOps Gestion des API ou l’extension Gestion des API pour Visual Studio Code afin d’extraire les artefacts pertinents de leur instance de développement Gestion des API. Ces artefacts sont basés sur Azure Resource Manager et doivent être validés dans le référentiel Git de l’équipe d’API.
Notes
N’utilisez pas l’intégration Git Gestion des API.
- Les modèles de service et les modèles partagés doivent se trouver dans des référentiels distincts.
- Les modifications apportées aux artefacts doivent être effectuées sur les artefacts extraits, puis validées sur Git. Elles seront déployées dans un environnement de développement.
- Pour promouvoir les environnements centralisés (mise en lots, production, etc.), les équipes d’API peuvent soumettre une demande de tirage (PR) pour fusionner leurs modifications apportées au référentiel d’éditeur.
- L’équipe d’administration Gestion des API valide la demande de tirage.
- Dans l’idéal, la plupart des validations sont automatisées dans le cadre de l’envoi d’une demande de tirage.
- Les modèles d’infrastructure en tant que code doivent se trouver dans un autre référentiel et être déployés dans un pipeline de déploiement.
- Séparer le déploiement d’infrastructure du déploiement d’applications. L’infrastructure principale est moins sujette aux modifications que les applications. Traiter chaque type de déploiement comme un flux et un pipeline distincts.
- Une fois les modifications approuvées et fusionnées, l’équipe d’administration Gestion des API peut déployer les modifications apportées à l’environnement géré de manière centralisée (mise en lots, production) en coordination avec les planifications de l’équipe d’API convenues.
Hypothèses à l’échelle de l’entreprise
Voici des hypothèses relatives au développement de l’accélérateur de zone d’atterrissage Gestion des API :
- Utilisation de fichiers Bicep d’infrastructure en tant que code pour déployer une infrastructure Gestion des API et des back-ends.
- Déploiement de modèles d’infrastructure à l’aide de pipelines.