Share via

Ciclo di vita di 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 distribuita, 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 singolo repository.
    • Nelle strutture multirepo tutti i progetti sono organizzati in repository separati.

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

    • I repository pubblici possono essere accessibili in modo anonimo.
    • I repository privati richiedono che gli utenti possano accedere al repository e accedere ai servizi.
    • È possibile impostare visibilità pubblica e privata per i repos di Azure DevOps Projects e GitHub.

  • Prendere in considerazione l'impostazione delle autorizzazioni del repository che consentono di controllare chi può contribuire al codice sorgente e gestire altre funzionalità.

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

  • Azure offre il 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 creazione di zone di destinazione di Azure

  • Usare repository pubblici durante la condivisione di 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 gestione e il supporto delle risorse cloud.

Strategia di 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 per 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 i rami importanti dello sviluppo. Criteri che consentono di applicare standard di qualità del codice e 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 del codice unite in rami.

    • Definire una strategia di unione.
    • Le richieste pull devono essere semplici, con il numero di file mantenuti al minimo 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 i 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 si impegnano 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.

  • 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 di ramo:

    • Richiedere l'uso delle richieste pull per i merge di rami nel ramo principale.
    • 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 per rifiutare o attendere ogni volta che un ramo di origine cambia.
    • Includere automaticamente i revisori del codice.
    • Verificare la risoluzione dei commenti.

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

Compilazioni automatizzate

Considerazioni relative alla progettazione

  • Valutare l'implementazione dell'integrazione continua (CI). Ci prevede l'unione di tutto il codice sviluppatore in una codebase centrale in una pianificazione regolare e l'esecuzione automatica di compilazioni e processi di test standard.

  • Prendere in considerazione l'uso di 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.

  • È consigliabile includere unit test IaC nel processo di compilazione per convalidare la sintassi.

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

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

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

  • Gli agenti DevOps di Azure possono essere self-hosted o Microsoft- hosted.

    • La manutenzione e gli aggiornamenti vengono presi in considerazione per l'utente 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 gli agenti self-hosted autonomamente per eseguire processi di compilazione.

Suggerimenti per la progettazione

  • Usare CI per automatizzare le compilazioni e i 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 codice dell'applicazione nell'ambito del processo di compilazione.

  • Se possibile, usare il pool ospitato da Microsoft anziché i pool self-hosted, in quanto offrono l'isolamento e una macchina virtuale pulita per ogni esecuzione della pipeline.

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

  • Usare Key Vault segreti per evitare informazioni sensibili con codice rigido, 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). IL CD prevede la creazione, il test, la configurazione e la distribuzione da una compilazione a un ambiente.

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

    • Sviluppo
    • Test
    • QA
    • Gestione temporanea
    • Produzione

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

Suggerimenti per la progettazione

  • Usare IL CD per assicurarsi che il codice sia sempre pronto per la distribuzione creando, testando e distribuendo 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à delle risorse di diagnostica
    • Sicurezza

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

Strategia di rollback

Considerazioni relative alla progettazione

  • È consigliabile creare un piano di rollback. Il rollback di una distribuzione comporta il ripristino della distribuzione in uno stato valido noto e offre una possibilità fondamentale di ripristinare da una distribuzione non riuscita.

  • Se è necessario ripristinare le modifiche in un commit, ignorare le modifiche o reimpostare un ramo in uno stato precedente.

Suggerimenti per la progettazione

  • Adottare l'uso delle modifiche annullate in Git quando è necessario ripristinare le modifiche ai file di commit, eliminare le modifiche non inviate o reimpostare un ramo in uno stato precedente.