EF Migrații - cum să gestionați în timpul dezvoltării și implementării?

Ne gândim să folosim migrațiile bazate pe coduri EF 4.3.1, dar nu sunt clare cu privire la modul de integrare a migrațiilor cu metodologia actuală dev/deployment ...

Aplicația în discuție este o aplicație desktop WPF, fiecare desktop având propria instanță SQL Server (fiecare cu 4 baze de date separate). Acesta este implementat într-un mediu "câmp", cu suport IT local. Orice migrare a bazei de date trebuie făcută folosind scripturile SQL executate de instalator (probabil InstallShield). Nu va fi disponibil cineva care să poată rula o comandă la promptul PMC pentru a face upgrade la db atunci când este implementat/actualizat într-o locație de teren. Astfel, "ultima" ieșire din EF Migrations trebuie să fie un set de scripturi SQL, pe care aplicantul de instalare îl va aplica selectiv.

De asemenea, avem mai mulți dezvoltatori care fac schimbări de baze de date concurente .. nu există niciun DBA. Fiecare dezvoltator verifică pur și simplu - modificările codului (modelului) la TFS, iar data viitoare când acestea devin cele mai recente, modificările aduse modelului determină automat crearea unei noi baze de date pe sistemul lor dev. Cum putem acum fiecare dezvoltator să efectueze propriile migrații locale (mai degrabă decât să șterge/recreeze bazele de date locale) și apoi să gestioneze/să consolideze/să combine aceste migrații? Și coliziuni?

În timpul testării dev și a unității, fiecare dezvoltator poate șterge baza de date locală (întreaga) locală de mai multe ori în timpul unei singure iterații de checkout/checkin. Acest lucru funcționează bine cu codul întâi, deoarece baza de date devine automat reconstruită atunci când aplicația este repornit. Dar aceasta înseamnă că tabelul _MigrationHistory din baza de date este, de asemenea, șters. Cum ne descurcăm? Nu avem nevoie de istoricul de migrare al fiecărui sistem dev? Dacă nu, atunci unde/cum detectăm modificările agregate care trebuie aplicate sistemului livrat?

Pot vedea valoarea utilizării migrațiilor pentru a face față mecanismelor de migrare a unei baze de date, dar ceea ce nu este clar este cum să profitați de aceasta fără a introduce o centralizare a bazei de date "schimbare-control" în ciclul dev și, prin urmare, avantajele cheie ale Codului întâi.

Orice înțelegere/consiliere ar fi foarte apreciată!

DadCat

0

1 răspunsuri

I know this is an old question but I thought I'd post some of my experiences with EF Migrations (v6.1).

Fiecare dev va fi bine. Migrațiile sunt introduse în clase cu un marcaj de timp în nume, astfel încât nu se vor întâmpla coliziuni. DB-ul de pe aparatul lui dev va fi actualizat după ce a făcut o achiziție mai recentă și va rula aplicația (sau comanda de actualizare-bază de date).

Ștergerea db locale și recrearea este bine. Asigurați-vă că dev rulează baza de date de actualizare înainte de a adăuga migrări suplimentare sau că lucrurile nu vor mai fi sincronizate. Sunt un pic confuz în ceea ce privește motivul pentru care ar trebui să ștergă banca locală, dar acest lucru nu este în vigoare. S-ar putea să constatați că procesul dvs. trebuie să se schimbe pentru a se potrivi cu migrațiile EF.

Nu vă pot ajuta cu întrebarea instalatorului, deoarece o întrebare similară ma adus aici. Comanda de actualizare-bază de date are o opțiune-script care va genera scriptul de schimbare corect, dar nu știu cum să automatizez acest lucru pe un server de configurare.

0
adăugat