Database deployment

Adatbázis: SQL, XML DB

Sziasztok,

A kerdesem, hogy milyen megoldasokat tudtok nekem ajanlani database deploymentre?
Szoval adott dev, staging, prod szerverek, a kod source controlban, es TFS build & release. No most ha valami valtozik a kodban es az adatbazisban egyszerre, akkor egyutt kene tortenjen a valtoztatas a kodban es az adatbzisban.

Ezekre a lehetosegekre gondoltam, de pontosan meg nem korvonalazodott:
- a valtoztatassal egyutt a source controlba tenni a valtoztatasokat, elter table-tol kezdve mete data insertig. Ez kicsit kenyelmetlennek tunik, es abban sem vagyok biztos, hogy hogyan kovetnem, hogy mi az a script, ami az elozo deploy ota lefutott mar, es mi uj. Nyilvan ami az utolso commitban van az az uj, de amikor a cource controlbol letoltodik a kod, akkor jon minden.

- sqlpackage schema compare, es Visual Studio database project. ha valaki hasznalja esetleg kerhetnek egy peldaparameterezest?

- roundrablE: Itt meg probalom megerteni ,hogy mi es hogy. Pl a create table az UP mappaban van, ami ugye nem minden deploy utan hajtodik vegre ha jol tudom, akkor meg nem igazan ertem a lenyeget. A doksija szerintem nem tul jo.

- Red gate: nem igazan neztem, mert fizetos.

esetleg valami mas otlet?

koszi

  • 1266 megtekintés

( dotnetlinux | 2017. 12. 14., cs – 18:38 )

Ha sokkal több a DB bővülése és kevés a konverzió, akkor én a DB schema-t raknám el és bármely verziójú DB-re ráengedve aktuális állapotba hozza. Akár WordPress DB-ből is csinál ügyviteli rendszert, egy tábla sem marad :)

A konverziós scripteket (ha 1-1 kapcsolatból 1-N lesz és nem akarod az adatokat eldobni) pedig azonosítóval látnám el (yyyy-mm-dd-#mirejo), amelyet a DB-ben tárolhatsz, hogy már lefutott-e és ha igen, akkor mikor. Ezt helyettesítheted valamivel, ami pl. egy BEFOREDROP_CUSTOMER_ZIP esemény, ami akkor fut le, mielőtt a vevő tábla irányítószámát áteszed a customer táblából a customeraddress-be. Ez egyértelmű, hogy mikor fut le, akkor amikor még van customer.zip és még nincs customeraddress tábla.

Az már egy másik kérdés, ha _bármely_ forráskódváltozathoz szeretnéd csomagba adni az "akkori" DB sémát...

( _Petya_ v | 2017. 12. 14., cs – 19:04 )

"- sqlpackage schema compare, es Visual Studio database project. ha valaki hasznalja esetleg kerhetnek egy peldaparameterezest?"

Korábban ezt használtuk, jól működött, bár kissé kényelmetlen. Ha mindenképp ennél maradnál, tudok segíteni, a Schema Compare nagyszerű tool.

Ha jól látom .NET a környezet, Entity Framework Code First Migrations esetleg? Nekünk bevált, mostanában már nem is szenvedünk DB projekttel és schema comapare-el, a Code First jobban bevált. Annyi hogy itt direktben nem az adatbázist módosítod, hanem a model class-okat, és azok alapján generálja le a DB scripteket, a meta adatokra meg ott a seed. (már amennyiben ugyanazt értjük meta adat alatt :) )

( karsany | 2017. 12. 14., cs – 22:49 )

A migrációs scriptek verziókezelőben tárolása módszerhez esetleg érdemes megnézni a Flyway-t: https://flywaydb.org/

Kezeli a már települt kódokat, újrafuttatást, lehet integrálni alkalmazásba, stb.

( asch v | 2017. 12. 15., p – 01:18 )

Ha csak az a kérdés, hogy hogyan követed, hogy mit alkalmaztál már és mit nem, az egyszerű:

* Verziózd meg a valid adatbázis állapotokat
* Két verzió közöt írd meg a szkriptet - ezt a fejlesztők csinálják meg mindig amikor új funkciót fejlesztenek
* A verziót tárold az adatbázisban, és a program indulásakor ez alapján egyértelműen el tudod dönteni, hogy melyik upgrade szkripteket kell futtatni. A szkriptek tranzakcióban futnak és egyből beállítják az új verziószámot is.

Ha nem tudod a verziókat egyetlen irányított útba rendezni, akkor egy kicsit nehezebb a dolgod, azt elismerem.

Az automatikus megoldásokkal az szokott lenni a baj, hogy a bonyolult esetekben rosszul működnek, vagy nagyon nehéz megérteni őket. Ezért a kézi karbantartás akár egyszerűbb is lehet.

Igy van. Nálunk van egy config tábla, amiben benne van az adatbázis verziója (pl. 45).

Ha változik, akkor irunk egy update scriptet

Az update scriptek a verziókövető rendszerben vannak tárolva

A normál SQL-ekből bármikor lehet latest (pl. 84)-es verziójú adatbázist építeni

Új feature mindig külön branch-be megy, majd visszamergeljük a trunk kódbázisba

Amikor adatbázis is változott, akkor esetleg érdemes lehet egy ilyen után taggelni, hogy tetszőleges korábbi verzióra vissza lehessen állni

Éles rendszernél mindig először backup-ot csinálunk, arra futtatjuk az update scripteket, tesztelünk, és ha jó, akkor megy élesben

Még egy kiegészités: az update scriptek egy log táblába beírják, ha lefutottak.

( gejzir | 2017. 12. 15., p – 09:18 )

Nem írtál semmit a fejlesztői környezetről.

Erre való a liquibase vagy a korábban már írt flyway
http://www.liquibase.org/
http://flywaydb.org/

Kicsit más az elvük, de ugyanaz az eredmény.
Az adatbázisod verzionált lesz, ha jól használod, akkor elvileg bármelyik verzióról bármelyik verzióra tudsz upgradelni/downgradelni.

A flyway-t ilyen szinten nem ismerem, de a liquibase külön foglalkozik ezzel a témakörrel, rollback-nek hívja.
http://www.liquibase.org/documentation/rollback.html

Change setenként megadhatod, hogy hogyan lehet visszavonni az adott módosítást.

Ennek akkor van értelme, ha külön release, feature brancheid vannak, és mondjuk az egyik branchről átállsz a másikra, mert supportálni kell egy régi verziót. Vagy először teszteled az egyik feature-t, aztán a másikat és ezek két eltérő adatbázis verziót használnak. Ilyenkor az adatbázis le tudja követni az adott branchez tartozó változásokat.