Condividi tramite

Ciclo di vita dello sviluppo

  • Articolo

La strategia del ciclo di vita dello sviluppo fornisce considerazioni chiave sulla progettazione e raccomandazioni per repository, ramo, compilazioni automatizzate, distribuzione e strategia di rollback durante la creazione automatica della zona di destinazione.

Strategia del repository

Considerazioni relative alla progettazione

  • Prendere in considerazione l'adozione di un sistema di controllo della versione come Git per offrire al team flessibilità nella condivisione e nella gestione del codice.

    • Git è il sistema di controllo della versione standard del settore. Si tratta di un sistema di controllo della versione distribuito, in cui la copia locale del codice è una versione completa del repository.

  • Comprendere la struttura del repository mono e multirepo.

    • Nelle strutture mono-repository tutto il codice sorgente si trova in un unico repository.
    • Nelle strutture multirepo tutti i progetti sono organizzati in repository separati.

  • Scegliere un'impostazione di visibilità adatta al contenuto del repository.

    • È possibile accedere ai repository pubblici in modo anonimo.
    • I repository privati richiedono che agli utenti venga concesso l'accesso al repository e all'accesso ai servizi.
    • È possibile impostare visibilità pubblica e privata per Azure DevOps Projects e repository GitHub.

  • Valutare la possibilità di impostare le autorizzazioni del repository che consentono di controllare chi può contribuire al codice sorgente e gestire altre funzionalità.

  • Prendere in considerazione l'uso della distribuzione di risorse IaC (Infrastructure as Code) in Azure. IaC consente di gestire l'infrastruttura in un modello dichiarativo, contribuendo a ridurre le attività di configurazione, garantire la coerenza tra le distribuzioni ed evitare la configurazione manuale dell'ambiente.

  • Azure offre supporto per IaC per le zone di destinazione tramite:

Suggerimenti per la progettazione

  • Usare Git come sistema di controllo della versione.

  • Usare repository privati durante la compilazione di zone di destinazione di Azure

  • Usare repository pubblici quando si condividono informazioni non riservate, ad esempio esempi di automazione, documentazione pubblica e materiale di collaborazione open source.

  • Adottare un approccio IaC per la distribuzione, la gestione, la governance e il supporto delle risorse cloud.

Strategia del ramo

Considerazioni relative alla progettazione

  • Prendere in considerazione l'uso di una strategia di ramo che consente ai team di collaborare in modo migliore ed efficiente di gestire il controllo della versione.

  • Prendere in considerazione l'uso di convenzioni di denominazione specifiche per i rami.

  • Prendere in considerazione l'uso delle autorizzazioni di ramo per controllare le funzionalità utente.

  • Prendere in considerazione l'uso dei criteri di ramo per aiutare i team a proteggere rami importanti di sviluppo. Criteri che consentono di applicare la qualità del codice e gli standard di gestione delle modifiche. Esempi di criteri di ramo includono:

  • L'adozione di una strategia di richiesta pull consente di mantenere il controllo delle modifiche al codice unite in rami.

    • Definire una strategia di unione.
    • Le richieste pull devono essere semplici, con il numero minimo di file per consentire ai revisori di convalidare i commit e le modifiche in modo più efficiente.
    • Le richieste pull devono avere titoli e descrizioni chiare in modo che i revisori sappiano cosa aspettarsi durante la revisione del codice.
    • È possibile usare modelli di richiesta pull.
    • È possibile eliminare i rami di origine dopo il completamento delle richieste pull, che offre un maggiore controllo e una migliore gestione dei rami.

Suggerimenti per la progettazione

  • Adottare un modello di sviluppo basato su trunk, in cui gli sviluppatori eseguono il commit in un singolo ramo. Questo modello facilita l'integrazione continua. Tutte le operazioni di funzionalità vengono eseguite nel trunk e tutti i conflitti di unione vengono risolti quando si verifica il commit.

  • Chiedere ai team di definire e usare convenzioni di denominazione coerenti per i rami per identificare il lavoro svolto.

  • Impostare le autorizzazioni per controllare chi può leggere e aggiornare il codice in un ramo del repository Git. È possibile impostare le autorizzazioni per singoli utenti e per i gruppi.

  • Impostare i criteri dei rami:

    • Richiedere l'uso delle richieste pull per i merge di rami nel ramo main.
    • Richiedere un numero minimo di revisori per le richieste pull.
    • Reimpostare tutti i voti di approvazione per rimuovere tutti i voti di approvazione, ma mantenere i voti da rifiutare o attendere ogni volta che viene modificato un ramo di origine.
    • Includere automaticamente i revisori del codice.
    • Verifica risoluzione commenti.

  • Impostare squash come strategia di merge, che consente di condensare la cronologia Git dei rami di argomento al termine delle richieste pull. Invece di aggiungere ogni commit in un ramo di argomento alla cronologia del ramo predefinito, un merge squash aggiunge tutte le modifiche ai file a un singolo nuovo commit nel ramo predefinito.

Compilazioni automatizzate

Considerazioni relative alla progettazione

  • Prendere in considerazione l'implementazione dell'integrazione continua (CI). L'integrazione continua comporta l'unione di tutto il codice dello sviluppatore in una codebase centrale in base a una pianificazione regolare e l'esecuzione automatica di compilazioni e processi di test standard.

  • Prendere in considerazione l'uso dei trigger CI:

    • Azure Repos Git. È possibile configurare rami, percorsi e tag come trigger per eseguire una compilazione CI.
    • GitHub. È possibile configurare rami, percorsi e trigger di tag per eseguire una compilazione CI.

  • Prendere in considerazione l'inclusione di unit test IaC nel processo di compilazione per convalidare la sintassi.

    • Il toolkit di test dei modelli di Resource Manager verifica se un modello segue le procedure consigliate.
    • Bicep linter controlla i file Bicep per individuare errori di sintassi e violazioni delle procedure consigliate.

  • Prendere in considerazione l'inclusione di unit test nel processo di compilazione dell'applicazione. Esaminare le attività disponibili per la pipeline di Azure DevOps.

  • Usare le connessioni al servizio Azure DevOps o i segreti di GitHub per gestire le connessioni ad Azure. Ogni connessione deve avere l'accesso con privilegi corretti alle risorse di Azure.

  • Prendere in considerazione l'uso dei segreti di Azure Key Vault per archiviare e gestire informazioni riservate, ad esempio password, chiavi API, certificati.

  • Gli agenti Di Azure DevOps possono essere ospitati in modalità self-hosted o microsoft.

    • La manutenzione e gli aggiornamenti vengono presi in considerazione quando si usano agenti ospitati da Microsoft. Ogni volta che viene eseguito un processo di compilazione, viene creata una nuova macchina virtuale.
    • È possibile configurare e gestire agenti self-hosted autonomamente per eseguire processi di compilazione.

Suggerimenti per la progettazione

  • Usare l'integrazione continua per automatizzare le compilazioni e il test del codice ogni volta che un membro del team esegue il commit delle modifiche al controllo della versione.

  • Includere unit test per IaC e il codice dell'applicazione come parte del processo di compilazione.

  • Se possibile, usare un pool ospitato da Microsoft anziché pool self-hosted, poiché offrono isolamento e una macchina virtuale pulita per ogni esecuzione della pipeline.

  • Quando si connette Azure DevOps o GitHub ad Azure tramite connessioni al servizio o segreti GitHub, assicurarsi di definire sempre l'ambito in modo che possano accedere solo alle risorse necessarie.

  • Usare i segreti di Key Vault per evitare informazioni riservate hardcoded, ad esempio credenziali (password utente della macchina virtuale), certificati o chiavi. Usare quindi i segreti come variabili nei processi di compilazione e rilascio.

Strategia di distribuzione

Considerazioni relative alla progettazione

  • Prendere in considerazione l'uso del recapito continuo (CD). La distribuzione continua prevede la compilazione, il test, la configurazione e la distribuzione da una compilazione a un ambiente.

  • Prendere in considerazione l'uso degli ambienti. Gli ambienti consentono di specificare come destinazione una raccolta di risorse da un processo di recapito. Esempi di nomi di ambiente comuni includono:

    • Sviluppo
    •   Test
    • Domande e risposte
    • Staging
    • Produzione

  • Prendere in considerazione l'uso di IaC come parte della strategia per convalidare e confermare le modifiche prima della distribuzione.

Suggerimenti per la progettazione

  • Usare cd per assicurarsi che il codice sia sempre pronto per la distribuzione creando, testando e distribuendo automaticamente il codice in ambienti simili all'ambiente di produzione. Aggiungere il recapito continuo per creare un'integrazione CI/CD completa che consente di rilevare i difetti del codice il prima possibile e garantisce che sia possibile rilasciare rapidamente aggiornamenti testati correttamente.

  • Usare gli ambienti come parte della strategia di distribuzione. Gli ambienti offrono vantaggi come:

    • Cronologia di distribuzione
    • Tracciabilità dei commit e degli elementi di lavoro
    • Integrità risorse di diagnostica
    • Sicurezza

  • Includi controlli di pre-distribuzione IaC in modo da poter visualizzare in anteprima le modifiche e visualizzare i dettagli sul fatto che una risorsa sia stata creata, modificata o eliminata.

Strategia di rollback

Considerazioni relative alla progettazione

  • Prendere in considerazione la creazione di un piano di rollback. Il rollback di una distribuzione comporta il ripristino della distribuzione a uno stato valido noto e offre una possibilità fondamentale per il ripristino da una distribuzione non riuscita.

  • Prendere in considerazione l'uso di modifiche di annullamento in Git se è necessario ripristinare le modifiche in un commit, annullare le modifiche o reimpostare un ramo a uno stato precedente.

Suggerimenti per la progettazione

  • Adottare l'uso di modifiche di annullamento in Git quando è necessario ripristinare le modifiche apportate ai file di cui è stato eseguito il commit, rimuovere le modifiche di cui non è stato eseguito il commit o reimpostare uno stato precedente di un ramo.