Nach ni geschitt, an hei gi mer erëm!
Op eisem nächste Projet hu mir decidéiert Liquibase vun Ufank un ze benotzen fir Problemer an Zukunft ze vermeiden. Wéi et sech erausstellt, wëssen net all jonk Teammemberen wéi se et richteg benotzen. Ech hunn en internen Atelier ofgehalen, deen ech dunn decidéiert hunn an en Artikel ze maachen.
Den Artikel enthält nëtzlech Tipps an eng Beschreiwung vun den dräi offensichtlechste Fallen, op déi Dir kënnt falen wann Dir mat relational Datebank Migratiounsinstrumenter schafft, besonnesch Liquibase. Entworf fir Java Entwéckler op Junior- a Mëttelniveauen; fir méi erfuerene Entwéckler kann et interessant sinn fir ze strukturéieren an ze widderhuelen wat héchstwahrscheinlech scho bekannt ass.
Liquibase a Flyway sinn déi Haaptkonkurrenztechnologien fir Versiounskontrollproblemer vu relational Strukturen an der Java Welt ze léisen. Déi éischt ass komplett gratis, an der Praxis ass et meeschtens fir de Gebrauch gewielt, dofir gouf Liquibase als Held vun der Verëffentlechung gewielt. Wéi och ëmmer, e puer vun de beschriwwenen Praktiken kënnen universell sinn, ofhängeg vun Ärer Applikatiounsarchitektur.
Migratioune vu relationelle Strukturen sinn e gezwongene Wee fir mat der schwaacher Flexibilitéit vu relationalen Dategeschäfter ëmzegoen. An der Ära vun der OOP Moud huet de Stil vun der Aarbecht mat Datenbanken bedeit datt mir de Schema eemol beschreiwen an et net erëm beréieren. Awer d'Realitéit ass ëmmer datt d'Saachen änneren, an d'Ännerunge vun der Tabellstruktur sinn zimlech dacks erfuerderlech. Natierlech kann de Prozess selwer schmerzhaf an désagréabel sinn.
Ech ginn net méi déif an d'Beschreiwung vun der Technologie an d'Instruktioune fir eng Bibliothéik op Äre Projet ze addéieren; zimmlech e puer Artikele goufen iwwer dëst Thema geschriwwen:
Zousätzlech gouf et schonn en exzellenten Artikel zum Thema nëtzlech Tipps:
Tipps
Ech wëll meng Rotschléi a Kommentaren deelen, déi duerch de Schweess gebuer goufen, Blutt a Péng vun léisen Problemer mat Migratioun.
1. Ier Dir mat der Aarbecht ufänkt, sollt Dir Iech mat de beschten Praktiken Sektioun vertraut maachen Liquibase
einfach awer ganz wichteg Saache ginn beschriwwen, ouni déi d'Bibliothéik benotzen kann Äert Liewen komplizéiere. Zum Beispill, eng onstrukturéiert Approche fir Changementsets ze managen wäert fréier oder spéider zu Duercherneen a gebrach Migratiounen féieren. Wann Dir net géigesäiteg ofhängeg Ännerunge vun der Datebankstruktur an der Servicelogik zur selwechter Zäit ausrollt, gëtt et eng grouss Wahrscheinlechkeet datt dëst zu roude Tester oder e futtis Ëmfeld féiert. Zousätzlech enthalen Empfehlungen fir Liquibase op der offizieller Websäit ze benotzen eng Klausel iwwer d'Entwécklung an d'Test vu Rollback Scripten zesumme mat den Haapt Migratioun Scripten. Gutt, am Artikel Et gi Code Beispiller betreffend Migratiounen an de Rollback Mechanismus.
2. Wann Dir ufänkt Migratiounsinstrumenter ze benotzen, erlaabt net manuell Korrekturen an der Datebankstruktur
Wéi de Spréchwuert seet: "Eemol Persil, ëmmer Persil." Wann d'Basis vun Ärer Applikatioun ufänkt vu Liquibase geréiert ze ginn, féieren all manuell Ännerungen direkt zu engem inkonsistente Staat, an den Niveau vum Vertrauen an Changementsets gëtt null. Potenziell Risiken enthalen e puer Stonnen fir d'Datebank ze restauréieren; am schlëmmste Fall Szenario, en dout Server. Wann Dir en "Old School" DBA Architekt an Ärem Team hutt, erklärt him gedëlleg a virsiichteg wéi schlecht Saache wäerte sinn wann hien d'Datebank einfach ännert no sengem eegene Verständnis vun engem bedingte SQL Entwéckler.
3. Wann de Changementset schonn an de Repository gedréckt gouf, vermeit d'Editioun
Wann en aneren Entwéckler e Pull gemaach huet an e Changement ugewannt huet, dee spéider geännert gëtt, erënnert hien Iech definitiv mat engem léif Wuert wann hien e Feeler kritt beim Start vun der Applikatioun. Wann d'Ännere vun der Ännerung iergendwéi an d'Entwécklung leeft, musst Dir de rutschegen Hang vun Hotfixes verfollegen. D'Essenz vum Problem läit op der Validatioun vun Ännerungen duerch Hash Zomm - den Haaptmechanismus vu Liquibase. Wann Dir den Changementset Code ännert, ännert den Hash Betrag. Ännere vun Ännerungssets ass nëmme méiglech wann et méiglech ass déi ganz Datebank vun Null ofzesetzen ouni Daten ze verléieren. An dësem Fall kann d'Refactoring vum SQL oder XML Code am Géigendeel d'Liewe méi einfach maachen an d'Migratiounen méi liesbar maachen. E Beispill wier eng Situatioun wou am Ufank vun der Applikatioun de Schema vun der Quelldatenbank bannent der Equipe ausgemaach gouf.
4. Hutt verifizéiert Datebank Backups wa méiglech
Hei, mengen ech, ass alles kloer. Wann op eemol d'Migratioun net erfollegräich war, kann alles zréck ginn. Liquibase huet e Tool fir Ännerunge zréckzekréien, awer d'Rollback-Skripte ginn och vum Entwéckler selwer geschriwwen, a si kënne Problemer mat der selwechter Wahrscheinlechkeet hunn wéi d'Skripte vum Haaptchangeset. Dëst bedeit datt et op alle Fall nëtzlech ass et sécher mat Backups ze spillen.
5. Benotzt bewisen Datebank Backups an Entwécklung, wa méiglech
Wann dëst net Kontrakter a Privatsphär widdersprécht, et gi keng perséinlech Donnéeën an der Datebank, an et weit net sou vill wéi zwee Sonnen - ier Dir se op Live Migratiounsserver benotzt, kënnt Dir kucken wéi et op der Maschinn vum Entwéckler funktionnéiert a berechent bal 100% vun Potential Problemer während Migratioun.
6. Kommunizéieren mat aneren Entwéckler op der Equipe
An engem gutt organiséierten Entwécklungsprozess weess jiddereen am Team wien wat mécht. A Wierklechkeet ass dat dacks net de Fall, dofir, wann Dir Ännerunge vun der Datebankstruktur als Deel vun Ärer Aufgab virbereet, ass et unzeroden och dat ganzt Team doriwwer z'informéieren. Wann een parallel Ännerungen mécht, sollt Dir suergfälteg organiséieren. Et ass derwäert mat Kollegen ze kommunizéieren no der Aarbecht fäerdeg, net nëmmen am Ufank. Vill potenziell Probleemer mat Changementsets kënnen an der Code review Etapp geléist ginn.
7. Denkt un wat Dir maacht!
Et géif schéngen wéi selbstverständlech Berodung déi fir all Situatioun gëllt. Vill Problemer wieren awer evitéiert gewiescht, wann den Entwéckler nach eng Kéier analyséiert hätt, wat hie mécht a wat et kéint beaflossen. Mat Migratiounen ze schaffen erfuerdert ëmmer zousätzlech Opmierksamkeet a Genauegkeet.
Traps
Loosst eis elo déi typesch Fallen kucken, an déi Dir kënnt falen, wann Dir de Rot hei uewen net befollegt, a wat, genau, sollt Dir maachen?
Situatioun 1: Zwee Entwéckler probéieren nei Changementer zur selwechter Zäit ze addéieren
Vasya a Petya wëllen eng Changementset Versioun 4 erstellen, ouni sech vuneneen ze wëssen. Si hunn Ännerungen un der Datebankstruktur gemaach an hunn eng Pull-Ufro mat verschiddene Changementer-Dateien erausginn. De folgende Mechanismus vun Aktioun ass proposéiert:
Wéi léisen
- Iergendwéi mussen d'Kollege sech eens sinn iwwer d'Uerdnung an där hir Changementer solle goen, zum Beispill soll Petin als éischt applizéiert ginn.
- Eppes soll déi zweet fir sech selwer bäidroen an dem Vasya seng Changementer mat der Versioun 5 markéieren. Dëst kann duerch Cherry Pick oder eng ordentlech Fusioun gemaach ginn.
- No Ännerungen, sollt Dir definitiv d'Gëltegkeet vun den Aktiounen kontrolléieren.
Tatsächlech erlaben d'Liquibase Mechanismen Iech zwee Versioun 4 Changementsets am Repository ze hunn, sou datt Dir alles léisst wéi et ass. Dat ass, Dir wäert einfach zwou Ännerungen un der Versioun 4 mat verschiddenen Nimm hunn. Mat dëser Approche gëtt et spéider ganz schwéier d'Datebankversioune ze navigéieren.
Zousätzlech hält Liquibase, wéi d'Haus vun den Hobbiten, vill Geheimnisser. Ee vun hinnen ass de validCheckSum Schlëssel, deen an der Versioun 1.7 erschéngt an erlaabt Iech e gültege Hash-Wäert fir e spezifesche Changementset ze spezifizéieren, egal wat an der Datebank gespäichert ass. Dokumentatioun seet déi folgend:
Füügt e Checksum un, dee gëlteg ugesi gëtt fir dësen ChangementSet, onofhängeg vun deem wat an der Datebank gespäichert ass. Benotzt haaptsächlech wann Dir e ChangeSet ännere musst an net wëllt datt Feeler op Datenbanken geworf ginn, op deenen et scho lafen ass (net eng recommandéiert Prozedur)
Jo, jo, dës Prozedur ass net recommandéiert. Awer heiansdo beherrscht e staarke Liichtmagier och donkel Techniken
Situatioun 2: Migratioun déi op Daten hänkt
Loosst eis unhuelen datt Dir net d'Fäegkeet hutt Datebank Backupe vu Live Serveren ze benotzen. Petya huet en Changement erstallt, et lokal getest an, mat voller Vertrauen datt hien richteg war, eng Pull-Ufro un den Entwéckler gemaach. Just am Fall, huet de Projet Lead gekläert ob Petya et iwwerpréift huet, an et dunn bäigefüügt. Awer den Ofbau um Entwécklungsserver ass gefall.
Tatsächlech ass dëst méiglech, a keen ass immun vun dësem. Dëst geschitt wann Ännerungen un der Tabellstruktur iergendwéi un spezifesch Daten aus der Datebank gebonne sinn. Natierlech, wann d'Datebank vum Petya nëmme mat Testdaten gefëllt ass, da kann et net all Problemfäll ofdecken. Zum Beispill, wann Dir en Dësch läscht, stellt sech eraus datt et Rekorder an aneren Dëscher vum Foreign Key sinn, déi mat Opzeechnungen an deem geläscht sinn. Oder wann Dir e Kolonntyp ännert, stellt sech eraus datt net 100% vun den Donnéeën an den neien Typ ëmgewandelt kënne ginn.
Wéi léisen
- Schreift speziell Scripten déi eemol zesumme mat der Migratioun benotzt ginn an d'Donnéeën an déi richteg Form bréngen. Dëst ass en allgemenge Wee fir de Problem ze léisen fir Daten op nei Strukturen ze transferéieren nodeems Dir Migratiounen ugewannt hutt, awer eppes ähnleches ka virdru applizéiert ginn, a spezielle Fäll. Dëse Wee ass selbstverständlech net ëmmer verfügbar, well d'Ännerung vun Daten op Live Servere geféierlech a souguer zerstéierend ka sinn.
- En anere schwéiere Wee ass eng existent Changementset z'änneren. D'Schwieregkeet ass datt all Datenbanken, wou et scho a senger existéierender Form applizéiert gouf, musse restauréiert ginn. Et ass ganz méiglech datt d'ganz Backend-Team gezwongen ass d'Datebank lokal vun Null auszerollen.
- An déi universellst Manéier ass de Problem mat den Donnéeën an d'Ëmfeld vum Entwéckler ze transferéieren, déi selwecht Situatioun nei ze kreéieren an en neie Changement ze addéieren, op de gebrach, deen de Problem ëmkreest.
Am Allgemengen, wat méi d'Datebank an der Zesummesetzung ähnlech ass wéi d'Produktiounsserver-Datebank, wat manner Chancen datt Probleemer mat Migratiounen wäit goen. An natierlech, ier Dir e Changementset an de Repository schéckt, sollt Dir e puer Mol iwwerdenken ob et eppes brécht.
Situatioun 3. Liquibase fänkt un ze benotzen nodeems se an d'Produktioun geet
Ugeholl datt d'Teamleader Petya gefrot huet Liquibase am Projet opzehuelen, awer de Projet ass scho a Produktioun an et gëtt eng existent Datebankstruktur.
Deementspriechend ass de Problem datt op all nei Serveren oder Entwéckler Maschinnen dës Dëscher vun Null erstallt musse ginn, an dat existent Ëmfeld muss an engem konsequente Staat bleiwen, prett fir nei Changementsets ze akzeptéieren.
Wéi léisen
Et ginn och verschidde Weeër:
- Déi éischt an offensichtlechst ass en separaten Skript ze hunn deen manuell muss applizéiert ginn wann Dir en neit Ëmfeld initialiséiert.
- Déi zweet ass manner offensichtlech, hutt eng Liquibase Migratioun déi an engem anere Liquibase Kontext ass, a gëlt se. Dir kënnt méi iwwer Liquibase Context liesen hei: . Am Allgemengen ass dëst en interessante Mechanismus deen erfollegräich benotzt ka ginn, zum Beispill fir Tester.
- Den drëtte Wee besteet aus e puer Schrëtt. Als éischt muss eng Migratioun fir existent Dëscher erstallt ginn. Da muss et op e puer Ëmfeld applizéiert ginn an domat gëtt seng Hash Zomm kritt. De nächste Schrëtt ass eidel Liquibase Dëscher op eisem net eidelen Server ze initialiséieren, an an der Tabell mat der Geschicht vun der Notzung vun Changementsets kënnt Dir manuell e Rekord iwwer den "wéi wann ugewannt" Ännerunge mat Ännerungen déi schonn an der Datebank existéieren. . Also, op engem existente Server, fänkt d'Geschicht Countdown vun der Versioun 2 un, an all nei Ëmfeld wäerten sech identesch behuelen.
Situatioun 4. Migratiounen ginn enorm an hunn net Zäit fir komplett
Am Ufank vun der Serviceentwécklung gëtt Liquibase als Regel als extern Ofhängegkeet benotzt, an all Migratioune ginn veraarbecht wann d'Applikatioun ufänkt. Wéi och ëmmer, mat der Zäit kënnt Dir op déi folgend Fäll stousse:
- Migratioune ginn enorm an huelen eng laang Zäit fir ze kompletéieren.
- Et gëtt e Besoin fir Migratioun a verdeelt Ëmfeld, zum Beispill, op verschiddene Datebankserverinstanzen gläichzäiteg.
An dësem Fall wäert d'Uwendung vun Migratiounen ze laang zu engem Timeout féieren wann d'Applikatioun ufänkt. Zousätzlech kann d'Uwendung vun Migratiounen op all Applikatiounsinstanz getrennt dozou féieren datt verschidde Server aus der Synchroniséierung sinn.
Wéi léisen
An esou Fäll ass Äre Projet scho grouss, vläicht souguer en Erwuessene, a Liquibase fänkt un als separat extern Tool ze handelen. D'Tatsaach ass datt Liquibase als Bibliothéik an eng Jar-Datei kompiléiert ass a kann als Ofhängegkeet an engem Projet oder onofhängeg funktionnéieren.
Am Standalone Modus kënnt Dir d'Implementatioun vu Migratiounen op Är CI / CD Ëmfeld oder op déi staark Schëlleren vun Äre Systemadministratoren an Deployment Spezialisten verloossen. Fir dëst ze maachen, braucht Dir d'Liquibase Kommandozeil . An dësem Modus gëtt et méiglech d'Applikatioun ze starten nodeems all déi néideg Migratiounen duerchgefouert goufen.
Konklusioun
Tatsächlech kënnen et vill méi Falen sinn wann Dir mat Datebankmigratiounen schafft, a vill vun hinnen erfuerderen eng kreativ Approche. Et ass wichteg ze verstoen datt wann Dir d'Tool richteg benotzt, déi meescht vun dëse Fallen vermeide kënnen. Speziell, Ech hu mat all vun der opgezielt Problemer a verschiddene Formen ze këmmeren, an e puer vun hinnen waren d'Resultat vu menge Feeler. Meeschtens geschitt dat, natierlech, wéinst Opmierksamkeet, mä heiansdo wéinst kriminellen Onméiglechkeet d'Instrument ze benotzen.
Source: will.com