DB scriptek, tároltak verziózása
2019-11-29T12:24:46+01:00
2019-11-30T18:20:54+01:00
2022-07-20T18:07:20+02:00
  • Nézd meg a LiquiBase-t. Az pont erre van kitalálva. Tud rollbacket is, ami elég hasznos lehet. 

    Már nem emlékszem részletesen miért (6 éve volt), de mi végül saját DB verziózó tool fejlesztése mellett döntöttünk, ami erősen hajazott a LiquiBase-re. Amikre emlékszem a miértek közül:
    - Az adott projecten kérdéses volt mennyire tudunk átverekedni egy éles adatbázisban kotorászó, általunk nem minden mélységében ismert, külső fejlesztésű toolt.
    - Java kellett volna a LiquiBase miatt a DB matatásához. Ami amúgy nem volt gond, mert az egész rendszer Java volt :) De akkor is.
    - A tároltak escape-elésénél küzdöttünk valamivel.
    - Én nem éreztem eléggé szigorúnak a rollback oldalát. 

    Teljesen üres, és meglévő adatbázisra is alkalmazható a verziózás. Mi is menet közben vezettük be egy másik megoldás helyett, amivel kínlódtunk. Így fogtunk  egy adott verziót, amit kineveztünk kezdőállapotnak, és legyártottuk a nullából az abba az állapotba juttató scripteket, majd a meglévő adatbázisokat megjelöltük, hogy már a kezdőállapotban vannak. Onnan már használható volt a tool. Amit még hozzátettünk a toolhoz és a fejlesztési processhez:
    - CI tesztelte az upgrade, valamint az upgrade-rollback sikerességét.
    - Minden app git branchnek volt egy DB git branch (és verzió) párja, bár nálunk ez csak feature brancheket jelentett, az appunknak csak egy éles telepítése létezett.
    - Szigorú code review volt minden DB változtatásra.
    - Az automatikus deploy folyamatunk része volt a DB upgrade is, aminek a sikertelensége eltörte a deploy jobot.
    - Minden release-nek része volt a rollback tesztelés, ahol leteszteltük a rendszert automata és manuális tesztekkel is upgrade-elt, majd onnan rollbackelt állapotokra is.
    - Minden release deployálása előtt készült mentés az éles DB-ről. Ha az upgrade hibás volt, ebből álltunk vissza (bár ilyen sose volt).
    - Minden release notesnak része volt a rollback is. 

    Az upgrade része a dolognak viszonylag egyszerű, csak meg kell futtatni a megfelelő scripteket a DB-re, meghatározott sorrendben. Az igazán izgalmas része a rollback (bár erről nem kérdeztél, de hátha hasznos). Mi a rollback kapcsán az alább szabályok mentén dolgoztunk: 
    - A rollback egy már upgrade-elt és módosításokat tartalmazó adatbázisról visszaállásra szolgál, ha a prod rendszert üzemelés közben kell visszaállítani a korábbi verzióra. Általában egy patch release ennél jobb opció :) Az upgrade sikertelensége esetén mentésből állunk vissza.
    - A rollback mindig csak 1 verziót megy visszafelé.
    - A rollbackek csak nagyon indokolt esetben járhatnak adatvesztéssel.
    - Ha adatvesztéssel is járnak, a visszavonással érintett táblákról és adatokról kötelező másolatot készíteni.
    - Minden rollback egy nem ismert állapotba visz, amit manuálisan kell ellenőrizni, és az abból előrehaladáshoz komoly analízis (beleértve a mentett adatok vizsgálatát is) szükséges. Tehát rollback esetén az A --(uAB)--> B --(rBA)--> A' állapotváltozások után (ahol uAB az A-ból B-be vivő upgrade scriptek, rBA a B-ből A'-be vivő rollback scriptek) uAB nem futtatható újra.
    Mutasd a teljes hozzászólást!
  • Flyway vagy ahhoz hasonlo megoldast preferalok altalaban(most lattam, hogy az undo feature fizetos de az elmult 3 evben miota hasznalom meg nem volt ra szuksegem)
    Az rails-es migration is erdekesnek tunik de nem rubyzok.
    Mutasd a teljes hozzászólást!
  • Szia,

    Oracle version control and change control? 
    itt találsz egy pár említést.
    Ha saját megoldás mellett döntenél, akkor általában ügy szokták megoldani, hogy
    pl. egy tábla módosítása esetén 2 állapotot tárolsz el ,ahogy te is írtad, amit nem szeretnétek :D: eltárolod azt az utasítást, ami ahhoz kell, hogy az új módosítás megtörténjen, és letárolod azt, ami ahhoz kell, hogy adott esetben vissza tudd állítani.
    Ugye tárolt eljárásoknál - a jogosultságot levéve - ez nem okoz gondot, csak a hard objektumoknál: táblával kapcsolatos objektumok, db strukturális  változások pl. table space módosítás- nem tudom, hogy ilyet csinálnak e - materializált nézetek és társai.
    Annó mi próbálkoztunk a gitora-val, de nem akart úgy működni, ahogy kellene.
    Én egy ideje tervezem saját készítését, de nem sok időm van foglalkozni vele.
    Érdemes utánaézni a system event triggereknek: Oracle system-level triggers, startup, logon, logoff, servererror, DDL
    Mutasd a teljes hozzászólást!
  • Sziasztok,

    Eddig a lineáris sql verziózás elég volt az egyes projektjeink esetében, de most lett egy olyan ügyfelünk, akik rapid - kisebb - javításokat akarnak korábbi éles verzióikban. Ez forráskód szinten nem okoz problémát, a git-ből kihúzzuk a megfelelő branch-et és kész, majd a javításokat - tesztelés után - vissza merge-ljük egy fejlesztői fősodorba, vagy abba, amibe éppen szükséges. Aztán a dev-ből build. Azonban az adatbázissal és annak script-jeivel már gondban vagyunk.
    A fejlesztésekre fenntartott db azóta már változott, struktúrálisan, a korábbi - minden egyes kis modósítás utáni - verziókról nem tartunk róla dump-ot.  (Csak release melletti állapotokról vannak dump-ok.) Viszont most az ügyfélnek hála, előállt az a helyzet, hogy náluk még olyan - korábbi db verzió van, amiben az új fejlesztések változásai (még) nincsenek benne, viszont a régi verzió meg nem működik a mostani - modósított - db verzióval. Oké, persze tudunk kézzel olyan db- előllítani, ami kell, de ez hosszabb, manuális folyamat (visszamenőlegesen megfuttatunk minden olyan script-et, amivel elérhető az a verzió, ami az adott ügyfélnél is megtalálható), amit jó lenne hoszú távon - amennyire lehet - automatizálni. A kérdés az lenne, hogy ti milyen megoldással verziózzátok a db script-eket, tároltakat, és minden olyat, ami közvetlenül a db-hez tartozik. Az nem jó megoldás (illetve nem tudjuk megoldani), hogy a script-ek úgy legyenek megírva, hogy azokat egy teljesen üres adatbázisra megfuttatva felépítik a szükséges verzióig a db-t. Eddig az új fejlesztésekhez, az új script-eket mellékeltük, megfelelő sorrendben, ami így kvázi felépült az új szintre. (Tehát csak a változásokat futtatuk meg.)
    Tehát, milyen megoldások léteznek úgymond egy adatbázis állapotainak a verzió kezelésére? Itt most konkrétan Oracle-ről van szó, de ezt inkább általánosan kérdezem, hogy később, más db-kre is alkalmazható legyen a megoldás.
    Köszi a válaszokat. :)
    Mutasd a teljes hozzászólást!
abcd