Implementare CI/CD per database SQL di Azure
Ora si sa come distribuire, configurare e usare database SQL di Azure per creare una base solida per un'applicazione moderna. I requisiti delle applicazioni cambiano e si evolvono continuamente, quindi il passaggio successivo consiste nel comprendere come aggiornare il database quando necessario. DevOps è un insieme di principi e procedure utili.
DevOps unisce persone, processi e tecnologia per offrire un valore continuo ai client. I team che adottano la cultura, le procedure e gli strumenti di DevOps riescono a offrire prestazioni elevate, creando prodotti migliori più velocemente, per una maggiore soddisfazione dei clienti.
Il database è una delle parti principali di una soluzione, quindi la possibilità di farlo funzionare in modo integrato con le procedure DevOps è un elemento chiave dello sviluppo di applicazioni moderne e agili.
Con Azure SQL, esistono diversi approcci per includere il database nel processo DevOps. Una pipeline di integrazione continua (CI) e recapito continuo (CD) è la colonna portante di un ambiente DevOps e Azure SQL può essere completamente integrata con qualsiasi strumento CI/CD scelto. Due degli strumenti più comuni e ampiamente usati in Azure sono GitHub Actions e Azure DevOps.
Implementare CI/CD per i database
La presenza del database come parte di una pipeline CI/CD indica che si vuole eseguire la configurazione e la distribuzione della struttura, e forse anche di alcuni dati, in modo completamente automatizzato, riproducibile e deterministico. Dopo la configurazione, è possibile eseguire il processo di distribuzione o di aggiornamento in qualsiasi momento, ogni volta che si vuole e ottenere risultati coerenti.
In questa unità verranno descritti i tre approcci principali per l'implementazione di una pipeline CI/CD per i database:
- Stato desiderato
- Migrazioni Code First
- Script personalizzati
Usare l'approccio Stato desiderato con SqlPackage.exe
In un approccio Stato desiderato viene creato uno snapshot della struttura di un database di riferimento che rappresenta lo stato desiderato. È quindi possibile usare tale snapshot per sincronizzare un altro database di destinazione, in genere il database di test o di produzione, con lo stato desiderato. È possibile usare uno strumento come SqlPackage.exe per creare lo snapshot in un file .dacpac. Quando .dacpac viene applicato al database di destinazione, rileva automaticamente le differenze, genera lo script corretto e applica lo script per sincronizzare lo schema di destinazione con il riferimento.
Si usa l'approccio relativo allo stato desiderato nello scenario in cui una persona deve prendere un autobus ed è probabilmente il più semplice e il più facile dei tre approcci descritti.
Implementare Migrazioni Code First a seconda del linguaggio
Esiste un'altra opzione quando non si vogliono scrivere gli script T-SQL, ma si vuole consentire a C#, Python o Node e alle entità definite nella soluzione (ad esempio, bus, route o posizione) di generare automaticamente il database e lo schema. In genere è disponibile uno strumento specifico che viene fornito con o che si applica a una piattaforma o un framework. Questi strumenti assicurano che ogni volta che si modifica o si aggiunge un campo o un’entità, la nuova struttura si rifletterà nel database. È possibile trovare i riferimenti agli strumenti per piattaforme e framework specifici alla fine di questo modulo.
Usare script manuali per le distribuzioni passo passo
Con l'approccio di scripting manuale, lo sviluppatore scrive e gestisce con attenzione gli script necessari per creare e modificare il database nel tempo. Dopo la sua distribuzione nell'ambiente di produzione, uno script non viene mai modificato ma ne viene creato uno nuovo. Ogni script contiene il codice necessario per trasformare il database nel nuovo schema. Nei casi in cui un database deve essere distribuito da zero, tutti gli script devono essere eseguiti nella sequenza corretta per assicurarsi che il database venga creato e trasformato correttamente. Dopo aver distribuito uno script, è possibile usare strumenti quali l'utilità confronto schemi in SQL Server Data Tools (SSDT) per confrontare le definizioni di database. In questo modo, si garantisce che lo script distribuito non venga nuovamente applicato allo stesso database nelle esecuzioni successive.
Selezionare uno strumento di pipeline per implementare CI/CD con facilità
Dopo aver identificato l'approccio migliore rispetto al metodo usato per l'aggiornamento del database, è possibile scegliere tra due soluzioni comuni per implementarlo: Azure DevOps o GitHub Actions.
Implementare integrazione continua e recapito continuo (CI/CD) con Azure DevOps
Azure DevOps è una suite di prodotti che offre supporto completo per tutti gli aspetti di DevOps, inclusa la pipeline CI/CD. Una pipeline è costituita da attività che definiscono i passaggi della pipeline. Un'attività può essere qualsiasi cosa, dall'esecuzione di un eseguibile alla compilazione di una soluzione .NET. È possibile usare un'attività specifica denominata Attività di distribuzione di database SQL di Azure per distribuire un file .dacpac o eseguire uno script .sql.
Implementare CI/CD con GitHub Actions
GitHub Actions consente la definizione di una pipeline CI/CD. Si usano le Azioni per creare i passaggi della pipeline. Si può usare un'azione per eseguire un processo di qualsiasi tipo. L'azione Azure SQL Deploy (Distribuzione di Azure SQL) consente di distribuire un file .dacpac.
Nell'esercizio successivo le azioni di Azure SQL verranno usate per distribuire e aggiornare lo schema del database, consentendo all'utente di vederle in azione.