Ciclo di sviluppo delle API

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Ogni organizzazione ha un ciclo di vita di sviluppo software (SDLC) unico. Spesso è necessario sincronizzare e allineare il deployment dei proxy API con gli stessi processi che utilizzi oggi per 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 e la gestione dei proxy API nell'SDLC della tua organizzazione. Un utilizzo comune dell'API RESTful prevede la scrittura di script o codice che esegua il deployment dei proxy API in modo programmatico o che migrano i proxy API da un ambiente all'altro, come parte di un processo automatizzato più ampio che esegue anche il deployment o la migrazione di altre applicazioni. I servizi API non formulano ipotesi sul tuo SDLC (o su quello di chiunque altro). Piuttosto, espone funzioni atomiche che possono essere coordinate dal tuo team di sviluppo per automatizzare e ottimizzare il ciclo di vita dello sviluppo delle API.

Le API dei servizi API sono descritte nel documento di riferimento API. Consulta la guida introduttiva ai riferimenti API.

Ambienti

Ogni organizzazione su Apigee Edge ha almeno due ambienti di deployment disponibili per i proxy API: "test" e "prod". La distinzione tra i due ambienti è arbitraria: ogni ambiente è semplicemente identificato da un insieme diverso di indirizzi di rete (URL). L'obiettivo è fornirti un dominio in cui creare e verificare i proxy API prima che l'API venga esposta agli sviluppatori esterni.

Puoi utilizzare questi ambienti per sincronizzare lo sviluppo del proxy API elaborato con il tuo SDLC. Ogni ambiente è definito da un indirizzo di rete, consentendoti di 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 nel set di VirtualHost disponibili in quell'ambiente.

Il protocollo TLS/SSL del server in entrata è abilitato automaticamente per ogni ambiente. Sono predefiniti due VirtualHost in ciascun ambiente: default e secure. L'impostazione predefinita definisce un indirizzo HTTP, mentre "Secure" definisce un indirizzo HTTP/S con TLS/SSL lato server preconfigurato. In una configurazione del proxy API, devi indicare su quali VirtualHosting il ProxyEndpoint deve rimanere in ascolto. Durante la promozione alla produzione, in genere disattivi HTTP rimuovendo VirtualHost default 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 VirtualHost default dalla configurazione ProxyEndpoint, crei 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 VirtualHost sono disponibili in un ambiente selezionando Ambienti nel menu principale dell'interfaccia utente di gestione.

Gli ambienti forniscono inoltre segregazione tra dati e risorse. Ad esempio, puoi configurare cache diverse nei test e in produzione, a cui sono accessibili solo i proxy API in esecuzione in quell'ambiente. Inoltre, le chiavi API emesse nell'ambiente di test non sono valide nell'ambiente di produzione e viceversa.

Deployment dei proxy API negli ambienti

Quando crei un proxy API, devi decidere in quale ambiente lavorerai. Puoi scegliere di creare un nuovo proxy API in produzione, ma ciò è sconsigliato perché potresti esporre un'API agli sviluppatori prima che sia pronta. In generale, inizia creando un proxy API in test che, dopo il test, devi promuovere a prod.

Per maggiori informazioni, consulta Informazioni sul deployment.

Sviluppo iterativo nel test

Quando utilizzi un proxy API, i servizi API salvano le iterazioni della configurazione come revisioni. Quando esegui il deployment di un proxy API, scegli una revisione specifica di cui eseguire il deployment. In genere, esegui il deployment della revisione più recente e, se necessario, ripristini il numero di revisione precedente. Puoi scegliere dove eseguire il deployment di queste revisioni. Ad esempio, puoi promuovere una revisione a livello di produzione per consentire agli sviluppatori di iniziare a lavorare con la tua API. Allo stesso tempo, potresti eseguire l'iterazione di più revisioni di test, per l'aggiunta di funzionalità o l'ottimizzazione dei criteri. Quindi, quando è tutto pronto, puoi eseguire il deployment della nuova revisione in produzione, sovrascrivendo la revisione esistente nell'ambiente. Con questo metodo, puoi sempre mettere a disposizione degli sviluppatori una revisione in tempo reale dell'API durante la fase di sviluppo.

Da promozione a produzione

Una volta 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 forniscono 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 degli script

L'interfaccia utente di gestione di Apigee Edge ti consente di eseguire il deployment dei proxy API per la produzione direttamente dall'API proxy Builder. Tuttavia, in molte situazioni i requisiti di sicurezza, affidabilità e coerenza obbligano i team di sviluppo a 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, ti consigliamo di eseguire l'iterazione solo sui proxy API nel test e di apportare il minor numero di modifiche necessarie ai proxy API di cui è stato eseguito il deployment in produzione.

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

• URL di destinazione: spesso i proxy API chiamano URL di backend diversi durante i test e la produzione. Puoi utilizzare le configurazioni di TargetServer per creare configurazioni TargetEndpoint indipendenti dall'ambiente. Vedi Bilanciamento del carico tra server di backend.
• Cache e mappe chiave/valore: entrambe le risorse di persistenza hanno come ambito l'ambiente. Assicurati che vengano utilizzate le convenzioni di denominazione per consentire ai proxy API di archiviare i dati senza richiedere modifiche alla configurazione durante la promozione. Consulta la sezione Creazione e modifica di una cache dell'ambiente.
• Target di callout di servizio: i callout di servizio possono utilizzare target diversi a seconda dell'ambiente se, ad esempio, un callout di servizio nell'ambiente di test utilizza un servizio demo. Consulta le norme sui callout di servizio.

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

Per ulteriori informazioni, consulta la sezione Informazioni sul deployment.