Cycle de vie du développement d'API

Vous consultez la documentation Apigee Edge.
Accéder à la documentation sur Apigee X en savoir plus

Chaque entreprise suit un cycle de développement logiciel unique. Il est souvent nécessaire de synchroniser et d'aligner le déploiement des proxys d'API avec les processus que vous utilisez actuellement pour développer, tester et déployer d'autres applications.

API Service fournit des outils et des API RESTful qui vous permettent d'intégrer le déploiement et la gestion de proxy d'API dans le SDLC de votre organisation. Une utilisation courante de l'API RESTful consiste à écrire des scripts ou du code qui déploient par programmation des proxys d'API ou qui migrent les proxys d'API d'un environnement vers un autre, dans le cadre d'un processus automatisé plus important qui déploie ou migre d'autres applications. API Service ne formule aucune hypothèse concernant votre SDLC (ou celui de toute autre personne). Elle expose plutôt des fonctions atomiques pouvant être coordonnées par votre équipe de développement afin d'automatiser et d'optimiser le cycle de vie de développement de vos API.

Les API d'API Service sont documentées dans la documentation de référence sur les API. Consultez le guide de démarrage de documentation de référence sur les API.

Cette vidéo présente les environnements et le cycle de vie de développement des API.

Environnements

Chaque organisation sur Apigee Edge possède au moins deux environnements de déploiement, disponibles pour les proxys d'API: "test" et "prod". La distinction entre les deux environnements est arbitraire. Chaque environnement est simplement identifié par un ensemble différent d'adresses réseau (URL). L'objectif est de vous fournir un domaine dans lequel vous pouvez créer et vérifier les proxys d'API avant que l'API ne soit exposée à des développeurs externes.

Vous pouvez vous servir de ces environnements pour synchroniser le développement des proxys d'API traité avec votre SDLC. Chaque environnement est défini par une adresse réseau, ce qui vous permet de séparer le trafic entre les proxys d'API sur lesquels vous travaillez et ceux auxquels les applications accèdent au moment de l'exécution. Les adresses réseau disponibles pour chaque environnement sont définies dans l'ensemble VirtualHosts disponible dans cet environnement.

En entrée, le protocole TLS/SSL du serveur est automatiquement activé pour chaque environnement. Deux hôtes virtuels sont prédéfinis dans chaque environnement : default et secure. L'hôte virtuel par défaut définit une adresse HTTP, tandis que l'hôte virtuel sécurisé définit une adresse HTTP/S, avec TLS/SSL préconfiguré côté serveur. Dans une configuration de proxy d'API, vous indiquez les hôtes virtuels sur lesquels le ProxyEndpoint doit écouter. Lorsque vous passez en production, vous désactivez généralement HTTP en supprimant l'hôte virtuel default de la configuration de proxy d'API.

Par exemple, l'objet ProxyEndpoint suivant écoute les protocoles HTTP et HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

En supprimant l'hôte virtuel default de la configuration ProxyEndpoint, vous créez un proxy d'API qui n'écoute que le protocole HTTPS et non HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Vous pouvez voir quels hôtes virtuels sont disponibles dans un environnement en sélectionnant Environnements dans le menu principal de l'interface de gestion.

Les environnements fournissent également une séparation des données et des ressources. Par exemple, vous pouvez configurer différents caches en test et en production, qui ne sont accessibles que par les proxys d'API exécutés dans cet environnement. En outre, les clés API générées dans l'environnement de test ne sont pas valides dans l'environnement de production, et inversement.

Déployer des proxy d'API dans des environnements

Lorsque vous créez un proxy d'API, vous devez décider dans quel environnement vous allez travailler. Vous pouvez choisir de créer un proxy d'API en production, mais cette approche n'est pas recommandée, car vous pouvez exposer une API qui n'est pas prête aux développeurs. En général, commencez par créer dans test un proxy d'API que, après test, vous promouvez vers prod.

Pour en savoir plus, consultez la section Comprendre le déploiement.

Développement itératif en test

Lorsque vous travaillez sur un proxy d'API, API Services enregistre les itérations de votre configuration en tant que révisions. Lorsque vous déployez un proxy d'API, vous choisissez une révision spécifique à déployer. En général, vous déployez la dernière révision et, si nécessaire, rétablissez le numéro de révision précédent. Vous pouvez choisir où déployer ces révisions. Par exemple, vous pouvez promouvoir une révision en production pour permettre aux développeurs de commencer à utiliser votre API. Vous pouvez en même temps itérer plusieurs révisions en test, où vous pouvez ajouter des fonctionnalités ou ajuster les règles. Lorsque vous êtes prêt, vous pouvez déployer la nouvelle révision en production, en remplaçant la révision existante dans cet environnement. Grâce à cette méthode, vous pouvez à tout moment mettre à jour votre API pendant la phase de développement.

Promotion en production

Lorsqu'un proxy d'API a été entièrement mis en œuvre et testé, il est prêt à être promu en production ("prod"). La révision du proxy d'API dans l'environnement de test sera utilisée pour remplacer la révision du proxy d'API déployé en production.

API Services offre des fonctionnalités permettant d'assurer un déploiement fluide des proxys d'API, de minimiser l'impact sur les applications et les utilisateurs finaux pendant la procédure de déploiement.

Déploiement de scripts

L'UI de gestion d'Apigee Edge vous permet de déployer directement des proxys d'API en production à partir du compilateur de proxy d'API. Toutefois, dans de nombreuses situations, les exigences en termes de sécurité, de fiabilité et de cohérence imposeront aux équipes de développement de scripter les procédures de déploiement. Pour ce faire, vous pouvez rédiger du code et des scripts qui appellent l'API RESTful exposée par API Services.

Ressources d'environnement

Pour mieux contrôler la promotion, il est recommandé de n'effectuer l'itération que sur les proxys d'API dans l'environnement de test et d'apporter le moins de modifications possible aux proxys d'API déployés en production.

Pour ce faire, vous devez vous assurer que certaines ressources associées à chaque environnement sont configurées de manière à rester statique dans une configuration de proxy d'API.

  • URL cibles: il est courant que les proxys d'API appellent différentes URL de backend pendant les tests et la production. Vous pouvez créer des configurations TargetEndpoint indépendantes de l'environnement à l'aide des configurations TargetServer. Consultez la section Équilibrage de charge sur les serveurs de backend.
  • Caches et mappages de clés/valeurs : les deux ressources de persistance sont définies par environnement. Vous devez vous assurer que les conventions d'attribution de noms permettent d'autoriser les proxys d'API à stocker des données sans nécessiter de modifications de configuration lors de la promotion. Consultez la section Créer et modifier un cache d'environnement.
  • Cibles ServiceCallout : les appels de service peuvent utiliser différentes cibles en fonction de l'environnement si, par exemple, un appel de service dans l'environnement de test utilise un service de démonstration. Consultez la Stratégie d'appel de service.

Pour rendre les configurations de proxy d'API indépendantes de l'environnement, vous pouvez également utiliser des instructions conditionnelles. L'instruction conditionnelle créée à l'aide de la variable environment.name peut être utilisée pour évaluer l'environnement actuel avant d'appliquer une règle ou avant d'acheminer le trafic vers une URL sur le backend.

Pour en savoir plus, consultez la page Comprendre le déploiement.