Migrazioni in ambienti di gruppo

Quando si lavora con le migrazioni negli ambienti del team, possono verificarsi vari problemi quando le migrazioni vengono aggiunte da più sviluppatori contemporaneamente; Si noti che le migrazioni non sono semplicemente script SQL, ma includono anche uno snapshot del modello al momento della migrazione.

Si supponga, ad esempio, che lo sviluppatore A e B crei contemporaneamente rami di lavoro e generi una migrazione nei relativi rami. Se lo sviluppatore A unisce il ramo e quindi lo sviluppatore B esegue la stessa operazione, la migrazione più recente (sviluppatore B) avrà uno snapshot del contesto che non include le modifiche dalla migrazione dello sviluppatore A. Ciò può causare vari tipi di danneggiamento nelle migrazioni successive.

Di conseguenza, è consigliabile coordinare in anticipo ed evitare di lavorare simultaneamente sulle migrazioni in più rami, quando possibile.

Le migrazioni formano una sequenza ordinata. I metadati della finestra di progettazione di ogni migrazione rappresentano il modello in quel punto della sequenza e vengono usati quando la migrazione viene rimossa. Non risolvere le migrazioni parallele ordinando o rinominando i file: la migrazione successiva conterrà comunque metadati che non includono le modifiche dell'altro ramo.

Identificazione di alberi di migrazione divergenti

A partire da EF 11, lo snapshot del modello registra l'ID della migrazione più recente. Ciò significa che se due sviluppatori creano una migrazione in rami separati, l'unione di tali rami genererà un conflitto di controllo del codice sorgente nel file di snapshot del modello, poiché entrambi i rami modificano l'ID migrazione più recente. Questo conflitto è un segnale importante: indica che gli alberi di migrazione sono divergenti e uno di essi deve essere scartato prima di procedere.

Per risolvere questo problema, seguire la procedura descritta in Risoluzione degli alberi di migrazione divergenti di seguito: interrompere l'unione, rimuovere la migrazione (mantenendo le modifiche del modello), unire le modifiche del compagno di team e quindi aggiungere nuovamente la migrazione.

EF Core 10 e versioni precedenti non registrano l'ID migrazione più recente nello snapshot del modello, quindi un sistema di controllo del codice sorgente può unire lo snapshot senza segnalare questo conflitto. Gli alberi della migrazione sono ancora divergenti e devono essere risolti usando lo stesso flusso di lavoro.

Risoluzione di alberi di migrazione divergenti

Se, durante la fusione di un ramo, viene rilevato un albero di migrazione divergente, risolvilo ricreando la tua migrazione. Segui questi passaggi:

1. Interrompere l'unione e tornare alla directory di lavoro prima dell'unione.
2. Rimuovere la migrazione, ma mantenere le modifiche apportate al modello che lo hanno generato. Il controllo del codice sorgente può essere usato per rimuovere solo i file di migrazione generati e ripristinare lo snapshot di pre-migrazione.
3. Unire le modifiche del compagno di squadra nella directory di lavoro.
4. Aggiungere nuovamente la migrazione in modo che sia basata sullo snapshot del modello unito.

Una volta completata questa operazione, la migrazione si integra senza problemi alle migrazioni aggiunte nell'altro ramo, e il suo snapshot di contesto include tutte le modifiche precedenti. La migrazione può ora essere condivisa in modo sicuro con il resto del team.

Non eseguire dotnet ef migrations remove (o Remove-Migration) dopo che le migrazioni parallele sono già state unite in una sequenza non valida. Il comando ripristina il modello rappresentato dai metadati della finestra di progettazione della migrazione precedente, che potrebbero non contenere le modifiche dell'altro ramo. Usare il controllo del codice sorgente per tornare a uno stato di pre-unione coerente e quindi seguire i passaggi precedenti.

Ripristinare le modifiche alla migrazione nel controllo del codice sorgente

Il ripristino di un commit del controllo del codice sorgente non modifica alcun database. Prima di rimuovere il codice di migrazione, scegliere uno di questi approcci:

• Se la migrazione non è stata applicata a un database condiviso, rimuovere la migrazione e quindi ripristinare le modifiche del modello.
• Se la migrazione è stata applicata, eseguire la migrazione del database a una migrazione precedente mentre il codice di migrazione è ancora disponibile o distribuire una nuova migrazione correttiva. Mantenere compatibile la distribuzione di applicazioni e database durante il rollback.

Non rimuovere l'origine della migrazione ancora registrata in un database condiviso. Se il codice è già stato ripristinato, controllare o ripristinare il commit contenente la migrazione per generare e testare il rollback e quindi eseguire il commit di una sequenza di migrazione coerente.