Automazione della piattaforma e DevOps per l'acceleratore di zona di destinazione di Gestione API

Questo articolo fornisce considerazioni progettuali e consigli per l'automazione della piattaforma e DevOps quando si utilizza l'acceleratore di zona di atterraggio di Gestione API. L'automazione della piattaforma e DevOps offrono opportunità per modernizzare l'approccio alla distribuzione ambientale con opzioni di infrastruttura come codice.

Altre informazioni sull'automazione della piattaforma e sull'area di progettazione DevOps.

Considerazioni sulla progettazione

• Ogni team api può eseguire il push degli aggiornamenti dal proprio repository per sviluppatori alla propria istanza di Gestione API di sviluppo.
  • Cosa significa questo dal punto di vista della pianificazione della rete?
  • Che ne dici di altri ambienti non di produzione (ad esempio qa o staging)?
• Considerare come gestire o fare il versioning di prodotti e altre entità, soprattutto se più team utilizzano gli stessi prodotti.
• Prendere in considerazione la strategia di test per API e criteri.

Consigli per la progettazione

• Un team centrale (ad esempio, un team di amministrazione di Gestione API) gestisce l'ambiente di gestione API di produzione.
• Le configurazioni di Gestione API sono rappresentate come modelli di Resource Manager o modelli equivalenti Bicep o Terraform e deve essere usata una mentalità basata su infrastruttura come codice.
• Il team di amministrazione di Gestione API pubblicherà le modifiche di configurazione nell'ambiente di Gestione API di produzione da un repository Git (repository di pubblicazione) di proprietà del team di amministrazione di Gestione API.
• Ogni singolo team API può creare un fork del repository dell'editore per avere il proprio repository di sviluppo da cui lavorare.
• Ogni team può usare Gestione API APIOps o l'estensione API Management per Visual Studio Code per estrarre gli elementi pertinenti dall'istanza di Gestione API di sviluppo. Questi artefatti sono basati su Azure Resource Manager e devono essere sottoposti a commit nel repository Git del team API.
• I modelli di servizio e i modelli condivisi devono trovarsi in repository separati.
• Le modifiche agli artefatti devono essere applicate agli artefatti estratti e quindi committate in Git. Devono essere distribuiti in un ambiente di sviluppo.
• Per alzare di livello gli ambienti centralizzati (gestione temporanea, produzione e così via), i team API possono inviare una richiesta pull per unire le modifiche al repository del server di pubblicazione.
• Il team di amministrazione dell'API Management convalida il pull request.
  • Idealmente, come parte dell'invio di una pull request, la maggior parte delle convalide è automatizzata.
• I modelli di infrastruttura come codice devono trovarsi in un repository diverso e distribuiti in una pipeline di distribuzione.
  • Separare la distribuzione dell'infrastruttura dalla distribuzione dell'applicazione. Le modifiche principali dell'infrastruttura cambiano meno frequentemente rispetto alle applicazioni. Considerare ogni tipo di distribuzione come un flusso e una pipeline separati.
• Dopo l'approvazione e l'unione delle modifiche, il team di amministrazione di Gestione API può distribuire le modifiche nell'ambiente gestito centralmente (gestione temporanea, produzione) in coordinamento con le pianificazioni del team API concordate.

Presupposti su scala aziendale

Di seguito sono riportati i presupposti che sono stati inseriti nello sviluppo dell'acceleratore di zona di destinazione di Gestione API:

• Uso dei file di infrastruttura come codice Bicep per distribuire l'infrastruttura e i back-end di Gestione API.
• Distribuzione di modelli di infrastruttura tramite pipeline.

Passaggi successivi

• Automatizzare le distribuzioni api con APIOps