Distribuire ambienti temporanei per le revisioni
Il linting del codice Bicep indica se la distribuzione di Azure avrà esito positivo. Sarà utile anche per distribuire effettivamente il codice Bicep, per vedere come apparirà l'ambiente dopo l'unione della richiesta pull e il completamento della distribuzione.
In questa unità viene illustrato come distribuire il codice in un ambiente temporaneo da una richiesta pull.
Perché distribuire il codice da una richiesta pull?
Quando si esamina una richiesta pull che include il codice Bicep, è consigliabile distribuire il codice Bicep in un ambiente di Azure reale. In questo modo, si può essere abbastanza certi del fatto che le modifiche funzioneranno dopo aver raggiunto l'ambiente di produzione. Se c'è un problema, è necessario individuarlo rapidamente. Le richieste pull offrono un'ottima opportunità per individuare ed evidenziare i problemi, perché si riceve un feedback immediato dai revisori.
Si è ormai abituati all'idea di distribuire le modifiche in uno o più ambienti che non sono di produzione, ad esempio in un ambiente di test, controllo di qualità e gestione temporanea, prima di distribuirle in produzione. In molte organizzazioni questi ambienti sono di lunga durata, il che significa che vengono aggiornati quando vengono implementate le modifiche e in genere non vengono eliminati.
Al contrario, un ambiente temporaneo è un ambiente che viene creato in modo dinamico e che è possibile eliminare quando non è più utile. Gli ambienti temporanei sono destinati a durare solo per un breve periodo di tempo, ad esempio abbastanza a lungo per la verifica delle modifiche.
Gli ambienti temporanei sono una scelta ottimale quando si distribuiscono ambienti per le richieste pull, perché più richieste pull diverse, che rappresentano i diversi tipi di modifiche, potrebbero essere aperte contemporaneamente. Se ci sono più richieste pull aperte, condividere gli ambienti che non sono di produzione di lunga durata vuol dire che è possibile visualizzare in anteprima una sola modifica alla volta.
Creare ambienti temporanei
Poiché l'utente sa come creare l'infrastruttura di Azure come codice e ha investito nella creazione dei file Bicep per distribuire le risorse, è possibile riutilizzare gli stessi asset per distribuire un ambiente temporaneo. Se necessario, è anche possibile distribuire più ambienti temporanei alla volta. Basta assicurarsi che le distribuzioni siano sufficientemente parametrizzate e generalizzate, in modo da poter creare facilmente ambienti indipendenti. Ad esempio, è necessario assicurarsi che ad alcune risorse di Azure vengano assegnati nomi univoci a livello globale, che non possono essere uguali ai nomi delle risorse in altri ambiente temporanei o di lunga durata.
Gli ambienti temporanei offrono molti vantaggi:
- È possibile testare in modo sicuro nuove funzionalità e capacità in un ambiente isolato che non influisce sugli altri carichi di lavoro di produzione o meno.
- È possibile visualizzare le modifiche nel proprio ramo, consentendo di presentare facilmente il lavoro ai colleghi o consentire l'accesso ai revisori.
- È possibile fare in modo che, contemporaneamente, più membri del team testino modifiche diverse, anche se le modifiche non sono compatibili.
- Poiché comportano la regolare esecuzione dei file Bicep, gli ambienti temporanei consentono di testare continuamente l'accuratezza e la completezza del codice Bicep e di altri script. Di conseguenza, è possibile accertarsi che il codice verrà eseguito correttamente nell'ambiente di produzione.
In questo modulo si creeranno ambienti temporanei che consentono di verificare le modifiche all'interno delle richieste pull. Chiunque esamini la richiesta pull può accedere all'ambiente temporaneo, che include nuove aggiunte e aggiornamenti, prima di approvare e unire la richiesta pull.
Distribuzione
Quando si lavora con gli ambienti temporanei, è consigliabile creare un gruppo di risorse di Azure separato per ogni richiesta pull creata dal team. Se un autore ha due richieste pull separate aperte, ognuna avrà il proprio ambiente temporaneo. Ciò consente di mantenere ogni modifica separata dalle altre e permette di evitare confusione o di sovrascrivere accidentalmente le risorse.
Affinché questo approccio funzioni, il flusso di lavoro di convalida della richiesta pull deve creare gruppi di risorse in modo dinamico. I gruppi di risorse richiedono nomi univoci e devono essere anche in grado di trovare facilmente il gruppo di risorse per testare le risorse ed eliminarle quando la richiesta pull viene chiusa. Per gestire in modo efficace i nomi del gruppo di risorse, è possibile usare il numero di richiesta pull all'interno del nome del gruppo di risorse. Si vedrà come eseguire questa operazione nell'esercizio successivo.
Al momento di eliminare l'ambiente temporaneo, il flusso di lavoro riesce a trovare ed eliminare facilmente l'intero gruppo di risorse. Tutte le risorse usate nell'ambiente temporaneo verranno eliminate contemporaneamente.
Autorizzazioni
Per la creazione di gruppi di risorse sono necessarie autorizzazioni a livello di sottoscrizione e in genere il ruolo Collaboratore deve essere assegnato all'identità del carico di lavoro del flusso di lavoro.
È consigliabile usare una sottoscrizione di Azure dedicata per ambienti temporanei. Seguendo questo approccio, è possibile concedere l'accesso all'identità del carico di lavoro del flusso di lavoro e ai membri del team senza concedere accidentalmente l'accesso agli altri ambienti.
Importante
I collaboratori con ambito sottoscrizione sono potenti, quindi è necessario assicurarsi che la governance per l'identità del carico di lavoro del flusso di lavoro e le modifiche che è possibile distribuire sia adeguata. Usando una sottoscrizione dedicata per ambienti temporanei, è possibile ridurre il rischio per gli altri ambienti.
Identità del flusso di lavoro
Il flusso di lavoro di distribuzione usa un'identità del carico di lavoro e credenziali federate per l'autenticazione in Azure. Quando si usano flussi di lavoro di convalida delle richieste pull, è necessario configurare le credenziali federate per le richieste pull.
In un'unità di esercizi precedente in questo modulo è stato eseguito un comando per creare credenziali federate. La stringa dei criteri è simile alla seguente:
repo:my-github-user/my-repo:pull_request
L'oggetto pull_request vicino alla fine della stringa specifica che le credenziali federate funzionano con i flussi di lavoro di convalida delle richieste pull.
Gestione costi
Quando si creano ambienti temporanei in modo dinamico, il rischio è quello di aumentare i costi di Azure. Se il team ha un numero elevato di richieste pull aperte, è possibile distribuire un numero elevato di risorse costose in Azure.
Suggerimento
Se il team chiude rapidamente le richieste pull, il rischio di aumento dei costi si riduce perché un ambiente temporaneo verrà eliminato quando la richiesta pull corrispondente viene chiusa.
Usando una sottoscrizione di Azure dedicata, è anche possibile monitorare facilmente i costi degli ambienti temporanei. È anche possibile applicare criteri a livello di sottoscrizione che limitano gli SKU delle risorse temporanee, consentendo di evitare l'aumento dei costi.
In aggiunta, Azure consente di controllare i costi degli ambienti temporanei in molti modi, tra cui:
- Gestione costi di Microsoft consente di impostare i budget per una sottoscrizione. I budget attivano le notifiche, in modo che il team sappia che il costo si sta avvicinando alla soglia specificata.
- Molti tipi di risorse di Azure offrono livelli più economici o persino gratuiti per carichi di lavoro che non sono di produzione. Valutare il possibile uso di tali piani tariffari e SKU.
- Per alcuni clienti sono disponibili prezzi di Sviluppo/test di Azure che è possibile usare per le sottoscrizioni non di produzione.
- I tag delle risorse consentono di identificare le risorse associate a ciascun ambiente temporaneo e di calcolare il costo di ciascuno di essi.
- È possibile creare script di automazione per eliminare le risorse temporanee dopo un periodo definito di tempo o persino ogni notte, ad esempio, dopo l'orario lavorativo.
È anche possibile considerare la condivisione di determinate risorse tra ambienti temporanei. Ad esempio, il codice Bicep potrebbe definire molte risorse, alcune delle quali sono costose o richiedono molto tempo per eseguire il provisioning. È possibile creare un gruppo di risorse condiviso e di lunga durata per tutte le richieste pull per condividere le risorse costose e creare gruppi di risorse temporanei separati per le altre risorse. Con questo approccio, tuttavia, la gestione degli ambienti temporanei e la loro separazione, in modo che siano utili durante il processo di revisione, si complica ed è soggetta a errori. È consigliabile evitarlo a meno che il costo degli ambienti temporanei non diventi troppo elevato.