Ĝi neniam okazis, kaj jen ĝi denove!
En la sekva projekto, ni decidis uzi Liquibase de la komenco por eviti problemojn en la estonteco. Kiel rezultis, ne ĉiuj junaj teamanoj scias kiel uzi ĝin ĝuste. Mi faris internan laborrenkontiĝon, kiun mi tiam decidis igi artikolon.
Ĉi tiu artikolo inkluzivas helpajn konsiletojn kaj priskribojn de tri el la plej evidentaj malfacilaĵoj, kiujn vi povas trafi kiam vi laboras kun interrilataj datumbazaj migradaj iloj, precipe Liquibase. Desegnita por Java-programistoj de Juniora kaj Meza nivelo, por pli spertaj programistoj ĝi povas esti interese por strukturi kaj ripeti tion, kio plej verŝajne jam estas konata.
Liquibase kaj Flyway estas la ĉefaj konkurantaj teknologioj por solvi la problemojn de versiokontrolo de interrilataj strukturoj en la Java mondo. La unua estas tute senpaga, praktike ĝi estas pli ofte elektita por uzo, tial Liquibase estis elektita kiel la heroo de la publikigo. Tamen, kelkaj el la priskribitaj praktikoj povas esti ĝeneralaj, depende de la arkitekturo de via aplikaĵo.
Relaciaj migradoj estas devigita maniero trakti la malfortan flekseblecon de interrilataj datumbutikoj. En la epoko de modo por OOP, la stilo labori kun la datumbazo signifis ke ni priskribos la skemon unufoje kaj ne tuŝus ĝin denove. Sed la realo ĉiam estas, ke aferoj ŝanĝiĝas, kaj ŝanĝoj al la strukturo de tabeloj estas postulataj sufiĉe ofte. Nature, la procezo mem estas dolora kaj malagrabla.
Mi ne enprofundiĝos en la priskribon de la teknologio kaj instrukcioj por aldoni la bibliotekon al via projekto, sufiĉe da artikoloj estis skribitaj pri ĉi tiu temo:
Krome, jam estis bonega artikolo pri la temo de utilaj konsiloj:
Konsiletoj
Mi volas dividi miajn konsilojn kaj komentojn, kiuj naskiĝis per la ŝvito, sango kaj doloro de solvado de problemoj kun migrado.
1. Antaŭ ol komenci, vi devus legi la sekcion pri bonaj praktikoj Liquibase
simplaj sed tre gravaj aferoj estas priskribitaj, sen kiuj la uzado de la biblioteko povas kompliki vian vivon. Ekzemple, ne-struktura aliro al ŝanĝa administrado pli aŭ malpli frue kondukos al konfuzo kaj rompitaj migradoj. Se vi ne realigas reciproke dependajn ŝanĝojn en la strukturo de la datumbazo kaj la logiko de servoj samtempe, tiam estas alta probablo, ke tio kondukos al ruĝaj provoj aŭ rompita medio. Krome, la rekomendoj pri uzado de Liquibase en la oficiala retejo enhavas alineon pri la disvolviĝo kaj kontrolo de skriptoj de restarigo kune kun la ĉefaj migraj skriptoj. Nu, en la artikolo ekzistas ekzemploj de kodo rilate al migradoj kaj la reakira mekanismo.
2. Se vi komencis uzi migradajn ilojn, ne permesu manajn korektojn en la datumbaza strukturo
Kiel diras la diro: "Iam Persil, ĉiam Persil." Se la bazo de via aplikaĵo komencis esti administrita per Liquibase-iloj, ĉiuj manaj ŝanĝoj tuj kondukas al malkonsekvenca stato, kaj la nivelo de fido en ŝanĝaroj fariĝas nulo. Eblaj riskoj - pluraj horoj pasigitaj por restarigi la datumbazon, en la plej malbona kazo - mortinta servilo. Se via teamo havas "malnovan lernejon" DBA-Arkitekto, pacience kaj penseme klarigu al li kiom malbonaj aferoj estos se li nur redaktos la datumbazon laŭ sia maniero de la kondiĉa SQL-Programisto.
3. Se la ŝanĝaro jam estis pelita al la deponejo, evitu redaktadon
Se alia programisto tiris kaj aplikis ŝanĝaron, kiu estos redaktita poste, li certe memoros vin per afabla vorto kiam li ricevos eraron kiam la aplikaĵo komenciĝos. Se redaktado de la ŝanĝaro iel likas en evoluon, vi devos malsupreniri la glitigan deklivon de korektoj. La esenco de la problemo baziĝas sur la validigo de ŝanĝoj per hashsumo - la ĉefa mekanismo de Liquibase. Dum redaktado de la ŝanĝkodo, la hashsumo ŝanĝiĝas. Redakti ŝanĝojn eblas nur kiam eblas disfaldi la tutan datumbazon de nulo sen perdi datumojn. En ĉi tiu kazo, refactoring SQL aŭ XML-kodo povas, male, faciligi la vivon, fari migradojn pli legeblaj. Ekzemplo estus situacio kiam, ĉe la komenco de la aplikaĵo, la skemo de la fonta datumbazo estis kunordigita ene de la teamo.
4. Havu kontrolitajn datumbazajn sekurkopiojn se eble
Ĉi tie, mi pensas, ĉio estas klara. Se subite la migrado estis malsukcesa, ĉio povas esti resendita. Liquibase havas revalidan ilon, sed la skriptoj ankaŭ estas skribitaj de la programisto mem, kaj ili povas havi problemojn kun la sama probablo kiel en la ĉefaj skriptoj de ŝanĝoj. Ĉi tio signifas, ke ludi ĝin sekure kun sekurkopioj estas utila ĉiukaze.
5. Uzu kontrolitajn datumbazajn sekurkopiojn en disvolviĝo se eble
Se ĉi tio ne kontraŭdiras kontraktojn kaj privatecon, ne estas personaj datumoj en la datumbazo, kaj ĝi ne pezas kiel du sunoj - antaŭ ol apliki ĝin sur vivaj migraj serviloj, vi povas kontroli kiel ĝi funkcias sur la maŝino de la programisto kaj kalkuli preskaŭ 100% de eblaj problemoj dum migrado.
6. Babilu kun aliaj programistoj en la teamo
En bone organizita evoluprocezo, ĉiuj en la teamo scias kiu faras kion. Fakte, tio ofte ne okazas, do, se vi preparas ŝanĝojn en la datumbaza strukturo kiel parto de via tasko, estas konsilinde aldone informi la tutan teamon pri tio. Se iu faras ŝanĝojn paralele, vi devas organizi sin zorge. Indas komuniki kun kolegoj eĉ ĉe la fino de laboro, ne nur ĉe la komenco. Multaj eblaj problemoj kun ŝanĝaroj povas esti solvitaj ĉe la koda reviziostadio.
7. Pensu, kion vi faras!
Ŝajne memkomprenebla konsilo aplikebla al ajna situacio. Tamen, multaj problemoj povus esti evititaj se la programisto denove analizus kion li faras kaj kion ĝi povus influi. Labori kun migradoj ĉiam postulas kroman atenton kaj precizecon.
Kaptiloj
Ni nun rigardu la tipajn kaptilojn, en kiuj vi povas fali, se vi ne sekvas la suprajn konsilojn, kaj kion, fakte, oni devas fari?
Situacio 1. Du programistoj provas aldoni novajn ŝanĝojn samtempe
Vasja kaj Petja volas krei ŝanĝan aron de versio 4 sen scii unu pri la alia. Ili faris ŝanĝojn al la datumbaza strukturo, kaj lanĉis tiran peton, kun malsamaj ŝanĝaj dosieroj. La sekva mekanismo estas proponita malsupre:
Kiel solvi
- Iel, kolegoj devas konsenti pri la ordo en kiu iliaj ŝanĝaroj devus iri, ni diru ke Petin devus esti aplikita unue.
- Unu persono devus enverŝi la alian kaj marki la ŝanĝan aron de Vasya kun versio 5. Ĉi tio povas esti farita per Cherry Pick aŭ bonorda kunfandado.
- Post la ŝanĝoj, nepre kontrolu la validecon de la agoj faritaj.
Fakte, la Liquibase-mekanismoj permesos al vi havi du versiojn 4-ŝanĝarojn en la deponejo, do vi povas lasi ĉion kiel ĝi estas. Tio estas, vi simple havos du reviziojn de versio 4 kun malsamaj nomoj. Kun ĉi tiu aliro, datumbazaj versioj fariĝas tre malfacile navigeblaj poste.
Krome, Liquibase, kiel la hejmoj de hobitoj, konservas multajn sekretojn. Unu el ili estas la validCheckSum-ŝlosilo, kiu aperis ekde la versio 1.7 kaj permesas vin specifi validan hash-valoron por specifa ŝanĝaro, sendepende de tio, kio estas konservita en la datumbazo. Dokumentado diras la jenon:
Aldonu ĉeksumon, kiu estas konsiderata valida por ĉi tiu ŝanĝaro, sendepende de tio, kio estas konservita en la datumbazo. Uzita ĉefe kiam vi bezonas ŝanĝi ŝanĝan aron kaj ne volas ke eraroj estu ĵetitaj en datumbazoj, sur kiuj ĝi jam funkciis (ne rekomendita proceduro)
Jes, ĉi tio ne estas rekomendita. Sed foje forta lummagiisto ankaŭ regas malhelajn teknikojn.
Kazo 2: Daten-movita migrado
Ni diru, ke vi ne povas uzi datumbazajn sekurkopiojn de vivaj serviloj. Petya kreis ŝanĝan aron, testis ĝin loke, kaj kun plena konfido, ke li pravas, faris tiran peton al la programisto. Por la okazo, la projektestro klarigis ĉu Petya kontrolis ĝin, kaj poste enverŝis ĝin. Sed la deplojo sur la evoluservilo falis.
Fakte, ĉi tio eblas, kaj neniu estas imuna kontraŭ ĉi tio. Ĉi tio okazas se modifoj al la tabelstrukturo estas iel ligitaj al specifaj datumoj de la datumbazo. Evidente, se la datumbazo de Petya estas plenigita kun nur testaj datumoj, tiam ĝi eble ne kovras ĉiujn problemajn kazojn. Ekzemple, kiam vi forigas tabelon, rezultas, ke estas registroj en aliaj tabeloj per Fremda Ŝlosilo asociitaj kun registroj en tiu forigita. Aŭ kiam ŝanĝas la kolumnan tipon, rezultas, ke ne 100% de la datumoj povas esti konvertitaj al la nova tipo.
Kiel solvi
- Skribu specialajn skriptojn, kiuj estos aplikitaj unufoje kune kun la migrado kaj alportu la datumojn en la ĝustan formon. Ĉi tio estas ĝenerala maniero solvi la problemon transdoni datumojn al novaj strukturoj post aplikado de migradoj, sed io simila povas esti aplikita antaŭe, en specialaj kazoj. Ĉi tiu vojo, kompreneble, ne ĉiam disponeblas, ĉar redaktado de datumoj sur vivaj serviloj povas esti danĝera kaj eĉ mortiga.
- Alia malfacila maniero estas redakti ekzistantan ŝanĝaron. La malfacilaĵo estas, ke ĉiuj datumbazoj, kie ĝi jam estis aplikata en ĝia ekzistanta formo, devos esti restarigitaj. Estas tute eble, ke la tuta backend-teamo estos devigita loke kunigi la datumbazon de nulo.
- Kaj la plej universala maniero estas transdoni la datuman problemon al la medio de la programisto, rekrei la saman situacion kaj aldoni novan ŝanĝan aron, al rompita, kiu preteriros la problemon.
Ĝenerale, ju pli la datumbazo similas en konsisto al la datumbazo de la produktservila datumbazo, des malpli verŝajne problemoj kun migradoj iros malproksimen. Kaj, kompreneble, antaŭ ol vi sendas la ŝanĝaron al la deponejo, vi devus pensi plurfoje ĉu ĝi rompos ion.
Situacio 3. Liquibase komencas esti uzita post kiam ĝi iras en produktadon
Supozu, ke la teamgvidanto petis Petya inkluzivi Liquibase en la projekto, sed la projekto jam estas en produktado kaj ekzistas jam ekzistanta datumbaza strukturo.
Sekve, la problemo estas, ke en iuj novaj serviloj aŭ programmaŝinoj, la tabelaj datumoj devas esti rekreitaj de nulo, kaj la jam ekzistanta medio devas resti en konsekvenca stato, estante preta akcepti novajn ŝanĝojn.
Kiel solvi
Estas ankaŭ pluraj manieroj:
- La unua kaj plej evidenta estas havi apartan skripton, kiu devas esti aplikata permane dum pravalorigo de nova medio.
- La dua, malpli evidenta, estas havi Liquibase-migradon kiu estas en malsama Liquibase Kunteksto kaj apliki ĝin. Vi povas legi pli pri Liquibase Context ĉi tie: . Ĝenerale, ĉi tio estas interesa mekanismo, kiu povas esti sukcese aplikata, ekzemple, por testado.
- La tria vojo konsistas el pluraj ŝtupoj. Unue, migrado devas esti kreita por ekzistantaj tabeloj. Tiam ĝi devas esti aplikita sur iu medio kaj tiel ĝia hash sumo estos akirita. La sekva paŝo estas pravalorigi malplenajn Liquibase-tablojn sur nia nemalplena servilo, kaj vi povas permane meti rekordon de "kvazaŭ aplikita" ŝanĝaro kun la ŝanĝoj jam en la datumbazo en la tabelon kun la historio de aplikado de ŝanĝaroj. Tiel, sur jam ekzistanta servilo, la historio komenciĝos de versio 2, kaj ĉiuj novaj medioj kondutos idente.
Scenaro 4: Migradoj fariĝas grandegaj kaj ne povas daŭrigi
Komence de servo-disvolviĝo, kiel regulo, Liquibase estas uzata kiel ekstera dependeco, kaj ĉiuj migradoj estas procesitaj kiam la aplikaĵo komenciĝas. Tamen, kun la tempo, vi povas renkonti la sekvajn kazojn:
- Migradoj fariĝas grandegaj kaj bezonas longan tempon por plenumi.
- Estas bezono migri en distribuitaj medioj, ekzemple, sur pluraj okazoj de datumbazaj serviloj samtempe.
En ĉi tiu kazo, aplikado de migradoj tro longaj rezultos en tempodaŭro kiam la aplikaĵo komenciĝas. Ankaŭ, aplikante migradojn laŭ aplikaĵa kazo povas rezultigi malsamajn servilojn esti en ekstersinkroniga stato.
Kiel solvi
En tiaj kazoj, via projekto jam estas granda, eble eĉ plenkreskulo, kaj Liquibase komencas funkcii kiel aparta ekstera ilo. La fakto estas, ke Liquibase, kiel biblioteko, estas kunvenita en jardosieron, kaj povas funkcii kiel dependeco ene de la projekto, same kiel memstara.
Senrete, vi povas lasi la aplikon de migradoj al via CI/KD-medio aŭ al la fortaj ŝultroj de viaj administrantoj/deplojantoj. Por fari tion, vi bezonas la komandlinion de Liquibase . En ĉi tiu reĝimo, fariĝas eble lanĉi la aplikaĵon post kiam ĉiuj necesaj migradoj finiĝis.
konkludo
Fakte, estas multaj pli da malfacilaĵoj kiam oni laboras kun datumbazaj migradoj, kaj multaj el ili postulas kreivan aliron. Gravas kompreni, ke se vi uzas la ilon ĝuste, tiam la plej multaj el ĉi tiuj kaptiloj povas esti evititaj. Specife, mi devis alfronti ĉiujn problemojn listigitajn en malsamaj formoj, kaj kelkaj el ili estis la rezulto de miaj jamboj. Esence, tio okazas, kompreneble, pro neatentemo, sed foje - pro la krima nekapablo uzi la ilon.
fonto: www.habr.com