Ciclo di sviluppo delle API

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Ogni organizzazione ha un ciclo di vita di sviluppo del software (SDLC) univoco. Spesso è necessario sincronizzare e allineare il deployment dei proxy API con gli stessi processi che usi attualmente lo sviluppo, il test e il deployment di altre applicazioni.

I servizi API forniscono strumenti e API RESTful che ti consentono di integrare il deployment di proxy API e la gestione dei progetti SDLC della tua organizzazione. Un uso comune dell'API RESTful è scrivere script o codice che eseguono il deployment di proxy API a livello di programmazione o che eseguono la migrazione dei proxy API da un da un ambiente all'altro, come parte di un processo automatizzato più ampio che esegue anche il deployment o la migrazione di altri diverse applicazioni. I servizi API non fanno ipotesi sul tuo SDLC (o su chiunque altro, a tal fine pratica). Piuttosto, espone funzioni atomiche che possono essere coordinate dal tuo team di sviluppo automatizzare e ottimizzare il ciclo di vita dello sviluppo delle API.

Le API dei servizi API sono documentate nella documentazione di riferimento delle API. Consulta Recupero dei riferimenti alle API il deployment.

Ambienti

Ogni organizzazione su Apigee Edge dispone di almeno due ambienti di deployment per i proxy API: "test" e "prod". La distinzione tra i due ambienti è arbitraria ciascun ambiente viene semplicemente identificato da un diverso set di indirizzi di rete (URL). La è quello di fornirti un dominio in cui creare e verificare i proxy API prima che è esposto agli sviluppatori esterni.

Puoi sfruttare questi ambienti per sincronizzare lo sviluppo del proxy API elaborato con SDLC. Ogni ambiente è definito da un indirizzo di rete, in modo da poter isolare il traffico tra i proxy API su cui stai lavorando e quelli a cui le app accedono in fase di runtime. Gli indirizzi di rete disponibili per ogni ambiente sono definiti nell'insieme di VirtualHost disponibili in quell'ambiente.

Il protocollo TLS/SSL del server in entrata viene attivato automaticamente per ciascun ambiente. Due VirtualHost predefinite in ogni ambiente: default e secure. Per impostazione predefinita, L'indirizzo HTTP, mentre è sicuro, definisce un indirizzo HTTP/S, con TLS/SSL lato server preconfigurato. Nella una configurazione proxy API, devi indicare su quali VirtualHost il ProxyEndpoint deve rimanere in ascolto. Quando fai una promozione per la produzione, di solito disattivi HTTP rimuovendo l'elemento default VirtualHost dalla configurazione del proxy API.

Ad esempio, il seguente ProxyEndpoint rimane in ascolto su HTTP e HTTPS.

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

Se elimini il VirtualHost default dalla configurazione ProxyEndpoint, creare un proxy API che rimane in ascolto solo su HTTPS e non su HTTP.

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

Puoi vedere quali host virtuali sono disponibili in un ambiente selezionando Ambienti nel menu principale dell'interfaccia utente di gestione.

Inoltre, gli ambienti assicurano la segregazione di dati e risorse. Puoi, ad esempio, impostare diverse cache in fase di test e di produzione, a cui è possibile accedere solo tramite proxy API eseguiti in quel completamente gestito di Google Cloud. Inoltre, le chiavi API emesse nell'ambiente di test non sono valide dell'ambiente di produzione e viceversa.

Deployment di proxy API negli ambienti

Quando crei un proxy API, devi decidere in quale ambiente lavorerai. Tu puoi scegliere di creare un nuovo proxy API in produzione, ma questa operazione non è consigliata perché potresti esporre un'API agli sviluppatori prima che sia pronta. In generale, inizia creando un proxy API in test che, dopo il test, promuovere l'attività prod.

Per ulteriori informazioni, vedi Informazioni sul deployment.

Sviluppo iterativo nel test

Mentre lavori su un proxy API, i servizi API salvano iterazioni della configurazione come revisioni. Quando esegui il deployment di un proxy API, devi scegliere una revisione specifica. In genere si esegue il deployment della revisione più recente e, se necessario, si ripristina quella precedente il numero di revisione. Puoi scegliere dove eseguire il deployment di queste revisioni. Ad esempio, puoi promuovere una revisione in produzione per consentire agli sviluppatori di iniziare a lavorare con l'API. Allo stesso tempo, è possibile l'iterazione di più revisioni durante i test, in cui aggiungere funzionalità o perfezionare i criteri. Poi, Quando è tutto pronto, puoi eseguire il deployment della nuova revisione in produzione, sovrascrivendo quella esistente dell'ambiente. Utilizzando questo metodo, puoi sempre avere a disposizione una revisione in tempo reale dell'API sviluppatori durante lo sviluppo.

Promozione in produzione

Dopo che un proxy API è stato completamente implementato e testato, è pronto per essere promosso a "prod". La revisione del proxy API in fase di test verrà utilizzata per sovrascrivere la revisione del proxy API di cui è stato eseguito il deployment in produzione.

I servizi API offrono funzionalità per garantire il deployment senza interruzioni dei proxy API, riducendo al minimo l'impatto sulle app e sugli utenti finali durante la procedura di deployment.

Deployment di script

L'interfaccia utente di gestione di Apigee Edge ti consente di eseguire il deployment dei proxy API per la produzione direttamente dall'API dello strumento per la creazione di proxy. Tuttavia, in molte situazioni i requisiti di sicurezza, affidabilità la coerenza richiederà ai team di sviluppo di scrivere le procedure di deployment. Per farlo, puoi scrivere codice e script che richiamano l'API RESTful esposta dai servizi API.

Risorse dell'ambiente

Per un maggiore controllo durante la promozione, consigliamo di eseguire l'iterazione solo sull'API nei test e apporta le modifiche necessarie ai proxy API di cui è stato eseguito il deployment in produzione.

Per farlo, devi assicurarti che determinate risorse associate a ogni ambiente siano configurate in modo da poter rimanere statici in una configurazione proxy API.

• URL di destinazione: capita spesso che i proxy API chiamino URL di backend diversi durante i test e e produzione. Puoi utilizzare le configurazioni TargetServer per creare Configurazioni di endpoint di destinazione. Consulta Bilanciamento del carico tra server di backend.
• Cache e mappe chiave/valore: entrambe le risorse di persistenza sono basate sull'ambiente. Dovresti Assicurati che vengano utilizzate convenzioni di denominazione per consentire ai proxy API di archiviare i dati senza richiedere modifiche alla configurazione durante la promozione. Consulta Creazione e modifica di una cache di ambiente.
• Target callout di servizio: i callout di servizio possono utilizzare target diversi a seconda del se, ad esempio, un ServiceCallout nell'ambiente di test utilizza un servizio demo. Consulta le norme relative ai callout di servizio.

Per rendere indipendenti dall'ambiente le configurazioni proxy API, puoi anche usare istruzioni. L'istruzione condizionale creata con la variabile environment.name può essere utilizzato per valutare l'ambiente attuale prima di applicare un criterio o prima di eseguire il routing a un URL su e il backend.

Per ulteriori informazioni, consulta la sezione Informazioni sul deployment.