Synchronizování databázového modelu v .net rubrika: Programování: .Net

8 Martin Sura
položil/-a 30.5.2013

Ahoj,

Už delší dobu se snažíme najít ideální workflow pro verzování a spravování databázového schématu.

Vycházíme z toho, že u každého commitu by se měla nacházet akutální verze db. Často se nám stane, že vývojáři mají u sebe jinou verzi db, na stage serveru běží jiná verze a v releasu je jiná.

Ve vývoji jsme již vyžkoušeli :

  • Manuální synchronizační scripty
  • Migrace
  • Synchronizační scripty vygenerované z Visual Studa

Nakonec jsme skončili u migrací (FluentMigrator) ale i tady narážíme občas na problémy.

Jak řešíte synchornizace datových modelů vy?

Díky

odkaz
9 Augi
odpověděl/-a 30.5.2013

Když jsem tohle přes lety řešil, tak jsem nic uspokojivého nenašel, takže jsem si to udělal sám. Je to pár tříd a principem je to velmi podobné FluentMigratoru, a funguje nám to bezvadně. Základní interface vypadá takto:

public interface IMigration
{
int FromVersion { get; }
int ToVersion { get; }
string Name { get; }
void Up();
void Down();
}
Kontejner na migrace je assembly nebo namespace, přičemž kontejner říká, jaká je aktuální verze (tzn. v kontejneru mohou být i budoucí verze).

V praxi to vypadá tak, že třídy migrací jsou ve stejném sub-namespace jako kód, který pracuje s DB schématem, které je obráběno těmi migracemi. Takže máme kód pracující nad schématem a definici schémat (~migrace) velmi blízko sebe.

Při nasazení do prostředí (Stage/Production) se automagicky zajistí, že se databáze uvede do požadované verze. To samé se automagicky stane před spuštěním integračních testů proti databázi.

Protože píšeš, že používáte FluentMigrator (tedy něco velmi podobného jako my), tak by mě zajímalo, co jsou ty občasné problémy.

Komentáře

  • Martin Sura : To opravdu vypadá jako popis FluentMigratoru. Drobné problémy vidíme v situacích kdy dva vývojáři commitnou migraci se stejnou verzí a druhý, že je migrací hodně a v projektu vzniká celkem bordel a s tím souvisí i správné pojmenování migrací (teď máme většinou jen M1_CreateUserTable), ale pokud upravujeme existujicí tabulku tak už to tak lehce pojmenovat nejde. 30.5.2013
  • Augi : Že by dva vývojáři commitnuli migrace se stejnou verzí se nám stalo za ty roky myslím dvakrát a odhalily to testy. Možná je toto způsobené tím, že máme hodně malých (disjunktních) schémat, takže díky tomu nám k tomuto souběhu nedochází. Soubor s migracemi máme pojmenovaný Migration001-CreateUserTable a třída se pak jmenuje už jen CreateUserTable. Problém s tím nemáme, ale opět je to možná jen způsobené tím, že máme hodně malých schémat, resp. že aplikaci máme dobře rozbitou na nezávislé submoduly. 30.5.2013
  • Martin Sura : Jo jo nám se to stalo cca rok vývoje stalo 2x, ale dovedu si představit, že při intenzivnějším vývoji se situace bude opakovat. Ale jinak se s migracema v pohodě dá žít.:) 30.5.2013
  • tomas.fejfar : Tak stačí pojmenovávat timestampem, ne? ;) 31.5.2013

Pro zobrazení všech 5 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.