Nello stesso periodo Git è diventato popolare, anche la tendenza per la scrittura di applicazioni basate sul Web utilizzando le librerie ORM (object-Relational Mapping) è diventata ben nota. L’idea chiave era questa: poiché gli sviluppatori possono apportare modifiche al codice che sono facili da ripristinare utilizzando Git, perché gli sviluppatori non possono fare la stessa cosa quando si tratta di modifiche allo schema? Dopotutto, qualsiasi nuova funzionalità ragionevole comporta modifiche al codice e allo schema. Così i framework popolari come Rails e Django hanno aggiunto ORM e migrazione del database (nota anche come migrazione dello schema) come parte delle loro offerte. Ma la migrazione del database come concetto non è limitata ai framework Web più diffusi. Esistono anche librerie software di migrazione di database standalone come Flyway e Liquibase. Riesci a immaginare di essere in grado di ripristinare le modifiche granulari allo schema mentre scrivi il tuo codice? Troppo spesso, trovo che gli articoli sulla migrazione del database non discutano cosa significa farne attivamente uno, come sviluppatore. Voglio correggerlo qui. Con questo in mente, oggi ti darò la visione d’insieme di ciò che comporta la migrazione del database e come farlo in un ambiente di sviluppo attivo. Ill suddividere questo in tre sezioni, che coprono ciò che accade durante il processo di migrazione, gli strumenti comuni utilizzati, e le insidie che possono emergere durante la migrazione del database. Questo dovrebbe dare uno sviluppatore principiante gli strumenti per imparare rapidamente le idee chiave dietro la migrazione dei dati e anche imparare potenziali insidie da evitare quando si utilizza la migrazione del database come parte della sua casella degli strumenti di sviluppo.
Cosa succede durante la migrazione del database?
Ora che sai come sono avvenute le migrazioni del database, lascia che ti spieghi cosa comportano effettivamente.
Le modifiche granulari vengono generate come singoli file con script
Ho menzionato come le migrazioni del database tracciano fondamentalmente le modifiche granulari allo schema del database (e talvolta anche ai dati). Queste modifiche granulari sono in genere riflesse come file script separati. In questo modo, le modifiche allo schema granulare vengono riflesse come codice che può essere acquisito con qualsiasi software di controllo della versione. Questo è un esempio di file di migrazione in Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
Non solo è possibile avere migrazioni come file standalone, è anche possibile avere lo schema del database corrente come proprio file. In genere, questo è noto come un file di schema.
Gli script di migrazione del database sono dipendenti dallo strumento
Richiama lo script di migrazione del database in Ruby dal nostro esempio precedente. Ecco un altro file di migrazione del database dal controllo sorgente indipendente per il software di database Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
Questa volta, il file è in formato XML. In realtà, Liquibase può produrre modifiche di migrazione (o changeset, come amano chiamarli) in più formati come XML e JSON. Quindi, a meno che tu non voglia scrivere a mano la migrazione del database in formato SQL, non ci sono standard reali su come vengono creati i file di migrazione. Naturalmente, è possibile scrivere i propri script di migrazione del database personalizzati nei file SQL. Ma perché scrivere a mano e introdurre accidentalmente bug quando è possibile utilizzare strumenti per generare automaticamente le migrazioni del database?
Come si esegue una migrazione di database?
Ora sai cos’è una migrazione di database. È inoltre necessario sapere (almeno concettualmente) come eseguire una migrazione del database. Sfortunatamente, non ci sono standard per i file di migrazione del database, il che significa che non possiamo entrare in troppi dettagli su come crearli. In altre parole, il modo in cui si esegue una migrazione di database dipende in larga misura dallo strumento specifico utilizzato per l’attività. In questa sezione, tratterò i due modi più comuni per eseguire una migrazione di database.
Opzione 1: utilizzare una libreria Framework/dipendente dalla lingua
Se si utilizza un linguaggio popolare (Ruby, PHP, Python, ecc.) o framework (Rails, Django, ecc.), poi ci sono librerie ben documentate per la migrazione dei dati all’interno dell’universo del framework/linguaggio scelto. I framework web popolari verranno naturalmente forniti in bundle con le funzionalità di migrazione del database. A seconda della configurazione, è anche possibile scambiare la migrazione del database nativo per altre librerie all’interno della lingua scelta. In genere, in questo scenario, si generano i file di migrazione utilizzando la riga di comando. Occasionalmente, potrebbe essere necessario scrivere a mano il codice personalizzato per alcune modifiche, come la migrazione dei dati o anche come invertire la modifica stessa. Oltre a questo, la libreria scelta all’interno del framework/linguaggio si prende praticamente cura di questo per te.
Opzione 2: Usa un software indipendente incentrato sulla migrazione del database
In alcuni casi, ti consigliamo di utilizzare software come Flyway o Liquibase che funge solo da controllo del codice sorgente per il tuo database. In questo modo, eviti di essere bloccato in un particolare framework o linguaggio. Questo non significa che hai zero lock-in. Prendiamo, ad esempio, Flyway, che funziona bene con vari database come Oracle, MySQL e MariaDB. Se non si utilizza la migrazione basata su Java di Flyway (che si blocca in Java e Flyway), si può finire per utilizzare la migrazione basata su SQL (che si blocca alla vostra scelta di database e Flyway). La buona notizia è Flyway e Liquibase sono entrambi relativamente facili da usare. Inoltre, forniscono un modo da riga di comando per generare le migrazioni e consentire la codifica personalizzata per acquisire le migrazioni dello schema del database.
Scegliere l’opzione migliore per te
Ecco la mia opinione sulla scelta tra entrambe le opzioni. Tendo a vedere la maggior parte degli sviluppatori scegliere l’opzione 1. Di solito, questo perché gli sviluppatori hanno già un linguaggio/framework preferito, quindi cognitivamente parlando, non sembra che stiano imparando (ancora) un altro software. E il lock-in (nel caso dell’opzione 1, questo sarebbe per il quadro e la lingua) è del tutto volontario e desiderato. Puoi fare il caso dell’opzione 2 se il tuo team non si è impegnato completamente in una particolare lingua o framework. Qualunque cosa tu vada, evita di cambiare la tua scelta inutilmente a metà dello sviluppo. La migrazione del database non è un’area in cui la modifica degli strumenti offre enormi vantaggi. La maggior parte dei vantaggi deriva dalla semplice configurazione della migrazione del database.
I pericoli della migrazione dei database e come evitarli
Nella sezione precedente, ho trattato i due principali tipi di strumenti per la migrazione dei database: framework/software dipendente dalla lingua e standalone. Entrambi i tipi sono facili da usare. Ora, ti consiglio tre best practice quando si tratta di eseguire effettivamente una migrazione di database. Questi suggerimenti affrontano il pericolo principale della migrazione del database: si desidera evitare di apportare modifiche irreversibili.
Scegli uno strumento di migrazione del database e attenersi ad esso
L’ho menzionato brevemente prima, ma vale la pena sottolineare: voglio mettere in guardia contro le modifiche non necessarie al set di strumenti semplicemente perché è bello. Ricorda che gli script di migrazione del database dipendono dallo strumento utilizzato per generarli. Non ci sono standard adeguati per questi script. Se lo vuoi davvero, puoi persino scrivere il tuo nelle istruzioni SQL. Ciò introduce il proprio insieme di problemi; ad esempio, gli script SQL sono probabilmente in grado di dipendere dal database. Le query MySQL potrebbero non funzionare in PostgreSQL e viceversa. Quindi, o sei bloccato nel tuo strumento di migrazione del database, o sei bloccato nella tua scelta di database—o in alcuni casi, anche entrambi. Non ci sono evidenti vantaggi nel cambiare spesso il tuo set di strumenti, quindi il mio suggerimento è di scegliere uno strumento di migrazione del database e attenersi ad esso. Ci sono cose migliori da fare con il vostro tempo che girare le ruote inutilmente.
Elimina righe o colonne Solo quando sei assolutamente certo di aver bisogno di
Quando si tratta di migrazioni, per la maggior parte, puoi invertirle quando è necessario. I tipici strumenti di migrazione del database possono gestire semplici modifiche reversibili. E anche quando non possono, puoi facilmente aggiungere il tuo codice personalizzato per aiutarti a invertire. Ad esempio, in Rails, aggiungi semplicemente il codice in reversibile.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
Le modifiche più difficili da invertire tendono a comportare l’eliminazione di elementi: in particolare, l’eliminazione di colonne o righe di dati. Se il tuo database contiene molti dati, potresti dover scrivere una quantità significativa di codice personalizzato per provare a invertire le modifiche. Quindi, se stai pensando di eliminare i dati dal tuo database, fai molta attenzione. Questi tipi di modifiche sono difficili da annullare. Altre modifiche difficili da invertire includono la ridenominazione delle colonne e la modifica del tipo di dati di una colonna che contiene già dati. Una regola empirica con cui mi piace andare è questa: non dovresti quasi mai eliminare le colonne fino al prossimo major (conosci semver, giusto?) rilasciare. Questa regola si applica anche se ho colonne che voglio smettere di usare. Invece di eliminare le colonne, annuncerò nelle versioni minori quali colonne saranno deprecate in futuro. Quando arriva il momento per una versione importante, io poi cadere quelle colonne del tutto. In questo modo, riduco le possibilità di eseguire un cambiamento accidentale e indesiderato che sarà un processo terribile da invertire a mano.
Implementa i flag delle funzionalità
Un’altra eccellente strategia per la migrazione del database è l’implementazione dei flag delle funzionalità, specialmente quando si dispone di un team di grandi dimensioni e più persone stanno cercando di implementare funzionalità diverse per la stessa base di codice. Secondo Martin Fowler, i flag delle funzionalità sono “una tecnica potente, che consente ai team di modificare il comportamento del sistema senza modificare il codice.”In effetti, più grande è la tua squadra e più complessa è la tua base di codice, più le bandiere delle funzionalità brillano. I flag delle funzionalità aiutano a mitigare il rischio quando si tratta di migrazioni di database. Cercare di districare le modifiche quando è necessario ripristinare alcune funzionalità può essere un vero incubo. I flag di funzionalità funzionano altrettanto bene se si desidera apportare modifiche allo schema del database piccole o grandi. Quando si utilizzano i flag di funzionalità, vi consiglio di mirare a cambiamenti più frequenti e granulari nel complesso. E puoi davvero vedere come i flag delle funzionalità aiutano il tuo processo di sviluppo quando esegui una massiccia modifica dello schema. Si prega di puntare ancora a rompere questo enorme cambiamento di schema in fette più piccole e sottili. Non è necessario impressionare nessuno con quanto si può spremere in un cambiamento. Meglio aggiungere garanzie alle tue pratiche di sviluppo implementando tutte e tre le raccomandazioni di cui ho parlato in questa sezione.
Conclusione
Gli sviluppatori hanno bisogno di tutti gli strumenti che possono ottenere per rendere la loro vita più facile. La migrazione del database è uno di quegli strumenti indispensabili per la casella degli strumenti dello sviluppatore. Andando avanti, prevedo che l’impiego di migrazioni di database si evolverà da una best practice di sviluppo a una pratica standard di sviluppo. Le persone ti guarderanno in modo divertente per non aver utilizzato affatto la migrazione del database. Tuttavia, è importante tenere a mente come le migrazioni del database possono ritorcersi contro di te, in particolare per le modifiche dello schema difficili da invertire. Essere assolutamente certi di tali cambiamenti prima di farli andare in diretta. Se non stai già utilizzando la migrazione del database nel tuo processo, cosa stai aspettando? È facile da avviare e puoi persino aggiungerlo a metà del ciclo di sviluppo. Sarai grato di averlo fatto. Perché quando arriva il giorno in cui è necessario ripristinare le modifiche e le modifiche coinvolgono il database, ti piacerebbe avere qualcosa per aiutarti a farlo in pochi secondi. La migrazione del database è qualcosa che vorresti avere.