Ciclo di sviluppo delle API

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Ogni organizzazione ha un ciclo di vita dello sviluppo software (SDLC) unico. Spesso è necessario sincronizzare e allineare il deployment del proxy API con gli stessi processi che utilizzi oggi per sviluppare, testare e implementare altre applicazioni.

API Services fornisce strumenti e API RESTful che ti consentono di integrare la gestione e il deployment dei proxy API nel ciclo di vita dello sviluppo del software (SDLC) della tua organizzazione. Un utilizzo comune dell'API RESTful è scrivere script o codice che esegue il deployment dei proxy API in modo programmatico o che esegue la migrazione dei proxy API da un ambiente a un altro, nell'ambito di un processo automatizzato più ampio che esegue anche il deployment o la migrazione di altre applicazioni. API Services non fa ipotesi sul tuo SDLC (o su quello di chiunque altro). Espone invece 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 documentate nel riferimento API. Consulta la sezione Guida introduttiva al riferimento API.

Ambienti

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

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

TLS/SSL server in entrata viene attivato automaticamente per ogni ambiente. In ogni ambiente sono predefiniti due VirtualHost: default e secure. Il valore predefinito definisce un indirizzo HTTP, mentre il valore sicuro definisce un indirizzo HTTP/S con TLS/SSL lato server preconfigurato. In una configurazione del proxy API, indichi su quali VirtualHost deve essere in ascolto ProxyEndpoint. Quando esegui la promozione in produzione, in genere disabiliti HTTP rimuovendo il default VirtualHost dalla configurazione del proxy API.

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

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

Se elimini default VirtualHost dalla configurazione ProxyEndpoint, crei un proxy API che ascolta 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 della UI di gestione.

Gli ambienti forniscono anche la separazione di dati e risorse. Ad esempio, puoi configurare cache diverse in test e produzione, a cui possono accedere solo i proxy API eseguiti 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 lavorare. Puoi scegliere di creare un nuovo proxy API in produzione, ma non è consigliabile perché potresti esporre un'API agli sviluppatori prima che sia pronta. In generale, inizia creando un proxy API in test che, dopo il test, promuovi in prod.

Per saperne di più, vedi Informazioni sul deployment.

Sviluppo iterativo in fase di test

Mentre lavori a un proxy API, API Services salva le iterazioni della configurazione come revisioni. Quando esegui il deployment di un proxy API, scegli una revisione specifica da eseguire. In genere, viene eseguito il deployment della revisione più recente e, se necessario, viene ripristinato il numero di revisione precedente. 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 la tua API. Allo stesso tempo, potresti iterare più revisioni del test, in cui aggiungi funzionalità o perfezioni le norme. Poi, quando è tutto pronto, puoi eseguire il deployment della nuova revisione in produzione, sovrascrivendo quella esistente in quell'ambiente. Utilizzando questo metodo, puoi sempre avere una revisione live della tua API a disposizione degli sviluppatori durante lo sviluppo.

Promozione in produzione

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

API Services fornisce funzionalità per garantire il deployment senza interruzioni dei proxy API, riducendo al minimo l'impatto su app e utenti finali durante la procedura di deployment.

Deployment degli script

La UI di gestione di Apigee Edge consente di eseguire il deployment dei proxy API in produzione direttamente dal builder di proxy API. Tuttavia, in molte situazioni i requisiti di sicurezza, affidabilità e coerenza impongono ai team di sviluppo di creare script per le procedure di deployment. Per farlo, puoi scrivere codice e script che richiamano l'API RESTful esposta da API Services.

Risorse dell'ambiente

Per un maggiore controllo durante la promozione, ti consigliamo di eseguire l'iterazione solo sui proxy API in test e di apportare il minor numero possibile di modifiche 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 statiche in una configurazione del proxy API.

• URL di destinazione: è comune che i proxy API chiamino URL di backend diversi durante i test e la produzione. Puoi utilizzare le configurazioni TargetServer per creare configurazioni TargetEndpoint indipendenti dall'ambiente. Vedi Bilanciamento del carico tra i server di backend.
• Cache e mappe chiave/valore: entrambe le risorse di persistenza sono limitate all'ambiente. Devi assicurarti che le convenzioni di denominazione vengano utilizzate 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.
• Destinazioni ServiceCallout: i ServiceCallout possono utilizzare destinazioni diverse a seconda dell'ambiente. Ad esempio, un ServiceCallout 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 istruzioni condizionali. L'istruzione condizionale creata con la variabile environment.name può essere utilizzata per valutare l'ambiente attuale prima di applicare una policy o prima di eseguire il routing a un URL sul backend.

Per saperne di più, vedi Informazioni sul deployment.