Les API se sont banalisées. Elles sont devenues la norme de facto pour la connexion d’applications, de données et de services. Dans un contexte plus large, les API sont le moteur de la transformation numérique dans les entreprises.

Compte tenu de la valeur stratégique des API, un pipeline d’intégration continue (CI) et de déploiement continu (CD) est devenu une composante clé du développement des API. Cela permet aux organisations d’automatiser le déploiement des modifications d’API sans avoir à effectuer des étapes manuelles sujettes aux erreurs, de détecter les problèmes plus tôt et, en fin de compte, de fournir plus rapidement de la valeur aux utilisateurs finaux.

Ce blog vous guide par le biais d’une infrastructure conceptuelle d’implémentation d’un pipeline CI/CD pour le déploiement de modifications aux API publiées avec Gestion des API Azure.

Le problème

De nos jours, les entreprises possèdent généralement plusieurs environnements de déploiement (p. ex., Développement, Test et Production) et elle utilisent des instances Gestion des API distinctes pour chaque environnement. Certaines de ces instances sont partagées par plusieurs équipes de développement, qui sont responsables d’API différentes ayant des cadences de publication différentes.

En conséquence, les clients nous contactent avec les défis suivants :

• Comment automatiser le déploiement des API dans Gestion des API ?
• Comment migrer des configurations d’un environnement à un autre ?
• Comment éviter les interférences entre les équipes de développement différentes qui partagent la même instance de Gestion des API ?

Nous pensons que l’approche décrite ci-après permettra de relever tous ces défis.

CI/CD avec Gestion des API

.

L’approche proposée est illustrée dans l’image ci-dessus. Dans cet exemple, il existe deux environnements de déploiement : Développement et Production. Chacun possède sa propre instance Gestion des API. L’instance Production est gérée par une équipe désignée, appelée éditeurs d’API. Les développeurs d’API n’ont accès qu’à l’instance Développement. 

L’approche proposée consiste à conserver toutes les configurations dans les modèles Azure Resource Manager. Ces modèles doivent être conservés dans un système de contrôle de code source. Nous choisissons Git pour cet exemple. Comme le montre l’image, il existe un référentiel Éditeur qui contient toutes les configurations de l’instance Gestion des API de Production dans une collection de modèles :

• Modèle de service : Contient toutes les configurations de niveau de service (p. ex., niveau de tarification et domaines personnalisés).
• Modèles partagés : Contient des ressources partagées dans une instance Gestion des API (p. ex., groupes, produits et fournisseurs d’identité).
• Modèles d’API : Inclut les configurations des API et de leurs sous-ressources (p. ex., opérations et stratégies).
• Modèle maître : Regroupe l’ensemble en liant tous les modèles.

Les développeurs d’API dupliquent et clonent le référentiel Éditeur. Dans la plupart des cas, ils se concentrent sur les modèles d’API pour leurs API et ne doivent pas modifier les modèles partagés ou de service.

Lors de l’utilisation de modèles Resource Manager, nous nous rendons compte que deux défis se posent aux développeurs d’API :

• Tout d’abord, les développeurs d’API travaillent souvent avec les spécifications OpenAPI et peuvent ne pas être familiarisés avec les schémas Resource Manager. Pour simplifier la création de modèles, nous avons créé un utilitaire permettant d’automatiser la création de modèles d’API basés sur les spécifications OpenAPI.
• Par ailleurs, pour les clients qui utilisent déjà Gestion des API, un autre défi consiste à extraire les configurations existantes dans les modèles Resource Manager. Nous avons créé un autre outil pour générer des modèles basés sur des configurations existantes.

Une fois que les développeurs ont fini de développer et de tester une API et qu’ils ont généré le modèle d’API, ils soumettent une demande de tirage au référentiel Éditeur. Les éditeurs d’API peuvent valider la demande de tirage et s’assurer que les modifications sont sûres et conformes. La plupart des validations peuvent être automatisées dans le cadre du pipeline CI/CD. Lorsque les modifications sont approuvées et fusionnées avec succès, les éditeurs d’API les déploient dans l’instance Production. Le déploiement peut aussi être aisément automatisé avec Azure Pipelines.

Cette approche permet d’automatiser le déploiement des modifications d’API dans les instances Gestion des API et de promouvoir facilement les modifications d’un environnement à l’autre. Étant donné que des équipes de développement d’API différentes travailleront sur des ensembles de modèles d’API différentes, les risques d’interférence entre les équipes sont minimisés.

Étapes suivantes

Vous pouvez trouver les conseils, exemples et outils dans ce référentiel GitHub. N’hésitez pas à nous faire part de vos commentaires et de vos questions.

Nous sommes conscients que nos clients sont porteurs d’un large éventail de cultures d’ingénierie et de solutions d’automatisation existantes. L’approche et les outils fournis ici ne constituent pas une solution miracle. C’est pourquoi nous avons tout publié en open source sur GitHub afin que vous puissiez étendre et personnaliser la solution selon les besoins.