Automazione della piattaforma e DevOps per l'acceleratore di zona di destinazione Gestione API
Questo articolo fornisce considerazioni sulla progettazione e raccomandazioni per l'automazione della piattaforma e DevOps quando si usa l'acceleratore di zona di destinazione Gestione API. L'automazione della piattaforma e DevOps offre opportunità di 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 relative alla progettazione
- Ogni team API può eseguire il push degli aggiornamenti dal proprio repository sviluppatore all'istanza di sviluppo Gestione API.
- Che cosa significa da un punto di vista di pianificazione della rete?
- Informazioni su altri ambienti non di produzione (ad esempio QA o staging)?
- Valutare il modo in cui i prodotti e altre entità devono essere gestiti o con versioni, soprattutto se più team usano gli stessi prodotti.
- Prendere in considerazione la strategia di test per le API e i criteri.
Suggerimenti per la progettazione
- Un team centrale (ad esempio, un team di amministrazione di Gestione API) gestisce l'ambiente di produzione Gestione API.
- Gestione API configurazioni sono rappresentate come modelli Resource Manager o modelli Bicep o Terraform equivalenti e deve essere accolto un approccio all'infrastruttura come codice.
- Il team di amministrazione Gestione API pubblica le modifiche di configurazione all'ambiente di produzione Gestione API da un repository Git (repository del server di pubblicazione) di proprietà del team di amministrazione Gestione API.
- Ogni singolo team API può eseguire il fork del repository di pubblicazione per avere il proprio repository sviluppatore da cui lavorare.
- Ogni team può usare l'API Gestione API Ops o l'estensione Gestione API per Visual Studio Code per estrarre gli artefatti pertinenti dall'istanza di sviluppo Gestione API. Questi artefatti si basano su Azure Resource Manager e devono essere sottoposti a commit al repository Git del team api.
Nota
Non usare l'integrazione git Gestione API.
- I modelli di servizio e i modelli condivisi devono trovarsi in repos separati.
- Le modifiche agli artefatti devono essere eseguite agli artefatti estratti e quindi eseguire il commit in Git. Questi devono essere distribuiti in un ambiente di sviluppo.
- Per promuovere gli ambienti centralizzati (gestione temporanea, produzione e così via), i team API possono inviare una richiesta pull (PR) per unire le modifiche apportate al repository di pubblicazione.
- Il team di amministrazione Gestione API convalida la richiesta di richiesta.
- Idealmente, la maggior parte delle convalida è automatizzata come parte dell'invio di una richiesta di richiesta di invio.
- 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 delle applicazioni. L'infrastruttura principale cambia meno di frequente rispetto alle applicazioni. Considerare ogni tipo di distribuzione come un flusso e una pipeline separati.
- Dopo aver approvato e unito correttamente le modifiche, il team di amministrazione Gestione API può distribuire le modifiche all'ambiente gestito centralmente (gestione temporanea, produzione) in coordinamento con 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 Gestione API:
- Uso dei file Bicep dell'infrastruttura come codice per distribuire Gestione API infrastruttura e back-end.
- Distribuzione di modelli di infrastruttura tramite pipeline.