Sitä ei koskaan tapahtunut, ja tässä se on taas!
Seuraavassa projektissa päätimme käyttää Liquibasea heti alusta lähtien välttääksemme ongelmia tulevaisuudessa. Kuten kävi ilmi, kaikki nuoret tiimin jäsenet eivät osaa käyttää sitä oikein. Tein sisäisen työpajan, jonka päätin sitten muuttaa artikkeliksi.
Tämä artikkeli sisältää hyödyllisiä vinkkejä ja kuvauksia kolmesta ilmeisimmästä sudenkuopista, joihin voit törmätä käyttäessäsi relaatiotietokantojen siirtotyökaluja, erityisesti Liquibasea. Suunniteltu junior- ja keskitason Java-kehittäjille, kokeneemmille kehittäjille voi olla mielenkiintoista jäsentää ja toistaa mitä todennäköisimmin jo tiedetään.
Liquibase ja Flyway ovat tärkeimmät kilpailevat teknologiat relaatiorakenteiden versionhallinnan ongelmien ratkaisemiseksi Java-maailmassa. Ensimmäinen on täysin ilmainen, käytännössä se valitaan useammin käytettäväksi, minkä vuoksi Liquibase valittiin julkaisun sankariksi. Jotkut kuvatuista käytännöistä voivat kuitenkin olla yleisiä sovelluksesi arkkitehtuurista riippuen.
Relaatiomigraatiot ovat pakotettu tapa käsitellä relaatiotietovarastojen heikkoa joustavuutta. OOP:n muodin aikakaudella tietokannan kanssa työskentelytyyli tarkoitti sitä, että kuvasimme skeeman kerran emmekä koskettaneet sitä uudelleen. Mutta todellisuus on aina, että asiat muuttuvat ja muutoksia taulukoiden rakenteeseen tarvitaan melko usein. Luonnollisesti itse prosessi on tuskallinen ja epämiellyttävä.
En syvenny tekniikan kuvaukseen ja ohjeisiin kirjaston lisäämiseksi projektiisi, tästä aiheesta on kirjoitettu tarpeeksi artikkeleita:
Lisäksi hyödyllisten vinkkien aiheesta oli jo hieno artikkeli:
Советы
Haluan jakaa neuvoni ja kommenttini, jotka ovat syntyneet muuttoliikeongelmien ratkaisemisen hien, veren ja tuskan kautta.
1. Ennen kuin aloitat, sinun tulee lukea parhaita käytäntöjä käsittelevä osio Liquibase
kuvataan yksinkertaisia mutta erittäin tärkeitä asioita, joita ilman kirjaston käyttö voi vaikeuttaa elämääsi. Esimerkiksi ei-rakenteellinen lähestymistapa muutosjoukkojen hallintaan johtaa ennemmin tai myöhemmin hämmennykseen ja rikkoutuneisiin migraatioihin. Jos tietokannan rakenteessa ja palveluiden logiikassa ei oteta käyttöön toisistaan riippuvaisia muutoksia samanaikaisesti, on suuri todennäköisyys, että tämä johtaa punaisiin testeihin tai rikkinäiseen ympäristöön. Lisäksi virallisella verkkosivustolla olevat Liquibasen käyttöä koskevat suositukset sisältävät kappaleen palautuskomentosarjojen kehittämisestä ja tarkistamisesta sekä tärkeimmistä siirtokomentosarjoista. No artikkelissa siellä on esimerkkejä siirtoihin ja palautusmekanismiin liittyvistä koodeista.
2. Jos aloitit siirtotyökalujen käytön, älä salli manuaalisia korjauksia tietokantarakenteessa
Kuten sanonta kuuluu: "Kerran Persil, aina Persil." Jos sovelluksesi perustaa on alettu hallita Liquibase-työkaluilla, kaikki manuaaliset muutokset johtavat välittömästi epäjohdonmukaiseen tilaan ja muutosjoukkojen luottamustaso on nolla. Mahdolliset riskit - tietokannan palauttamiseen käytetty useita tunteja, pahimmassa tapauksessa - kuollut palvelin. Jos tiimilläsi on "vanhan koulun" DBA-arkkitehti, selitä hänelle kärsivällisesti ja harkiten, kuinka huonosti asiat ovat, jos hän vain muokkaa tietokantaa omalla tavallaan ehdollisesta SQL-kehittäjästä.
3. Jos muutossarja on jo työnnetty arkistoon, vältä muokkaamista
Jos toinen kehittäjä veti ja otti muutossarjan, jota muokataan myöhemmin, hän muistaa sinut varmasti ystävällisellä sanalla, kun hän saa virheilmoituksen sovelluksen käynnistyessä. Jos muutosjoukon muokkaaminen jotenkin vuotaa kehitykseen, sinun on mentävä hotfix-korjausten liukkaalle rinteelle. Ongelman ydin perustuu muutosten validointiin hash-summalla - Liquibasen päämekanismilla. Muutossarjan koodia muokatessa hash-summa muuttuu. Muutosjoukkojen muokkaaminen on mahdollista vain, kun on mahdollista ottaa koko tietokanta käyttöön tyhjästä menettämättä tietoja. Tässä tapauksessa SQL- tai XML-koodin refaktorointi voi päinvastoin helpottaa elämää, tehdä migraatioista luettavampia. Esimerkkinä voisi olla tilanne, jossa sovelluksen käynnistyessä lähdetietokannan skeema koordinoitiin tiimin sisällä.
4. Varmista, että tietokannan varmuuskopiot ovat mahdollisia
Täällä kaikki on mielestäni selvää. Jos siirto yhtäkkiä epäonnistui, kaikki voidaan palauttaa takaisin. Liquibasessa on palautustyökalu, mutta myös palautusskriptit ovat kehittäjän itsensä kirjoittamia, ja niissä voi esiintyä ongelmia samalla todennäköisyydellä kuin päämuutossarjan komentosarjoissa. Tämä tarkoittaa, että varmuuskopioiden kanssa pelaaminen on hyödyllistä joka tapauksessa.
5. Käytä varmennettuja tietokannan varmuuskopioita kehittämisessä, jos mahdollista
Jos tämä ei ole ristiriidassa sopimusten ja yksityisyyden kanssa, tietokannassa ei ole henkilötietoja, eikä se paina kuin kaksi aurinkoa - ennen kuin käytät sitä live-migraatiopalvelimilla, voit tarkistaa, kuinka se toimii kehittäjän koneella ja laskea lähes 100% mahdollisista ongelmista siirron aikana.
6. Keskustele muiden tiimin kehittäjien kanssa
Hyvin organisoidussa kehitysprosessissa kaikki tiimin jäsenet tietävät, kuka tekee mitä. Todellisuudessa näin ei useinkaan ole, joten jos olet valmistelemassa muutoksia tietokantarakenteeseen osana tehtävääsi, on suositeltavaa ilmoittaa tästä lisäksi koko tiimille. Jos joku tekee muutoksia rinnakkain, sinun tulee organisoida huolellisesti. Työtovereiden kanssa kannattaa kommunikoida myös työn lopussa, ei vain alussa. Monet muutosjoukkojen mahdolliset ongelmat voidaan ratkaista koodin tarkistusvaiheessa.
7. Ajattele mitä teet!
Näennäisesti itsestään selvä neuvo, joka soveltuu mihin tahansa tilanteeseen. Monet ongelmat olisivat kuitenkin voitu välttää, jos kehittäjä olisi jälleen kerran analysoinut, mitä hän tekee ja mihin se voi vaikuttaa. Siirtojen parissa työskenteleminen vaatii aina erityistä huomiota ja tarkkuutta.
ansoja
Katsotaanpa nyt tyypillisiä ansoja, joihin voit joutua, jos et noudata yllä olevia neuvoja, ja mitä itse asiassa pitäisi tehdä?
Tilanne 1. Kaksi kehittäjää yrittää lisätä uusia muutosjoukkoja samaan aikaan
Vasya ja Petya haluavat luoda version 4 muutossarjan tietämättä toisistaan. He tekivät muutoksia tietokantarakenteeseen ja ottivat käyttöön vetopyynnön erilaisilla muutostiedostoilla. Alla ehdotetaan seuraavaa mekanismia:
Miten päättää
- Jotenkin kollegoiden täytyy sopia, missä järjestyksessä heidän muutosjoukkojensa tulee mennä, oletetaan, että Petin tulisi ottaa käyttöön ensin.
- Yhden henkilön tulee kaata toinen sisään ja merkitä Vasyan muutossarja versiolla 5. Tämä voidaan tehdä Cherry Pickin tai siistin yhdistämisen kautta.
- Muista tarkistaa tehtyjen toimien oikeellisuus muutosten jälkeen.
Itse asiassa Liquibase-mekanismit mahdollistavat kahden version 4 muutossarjan arkistoon, joten voit jättää kaiken ennalleen. Toisin sanoen sinulla on yksinkertaisesti kaksi versiota 4 eri nimillä. Tällä lähestymistavalla tietokantaversioiden navigointi on myöhemmin erittäin vaikeaa.
Lisäksi Liquibase, kuten hobittien kodit, pitää paljon salaisuuksia. Yksi niistä on validCheckSum-avain, joka on ilmestynyt versiosta 1.7 lähtien ja jonka avulla voit määrittää kelvollisen hajautusarvon tietylle muutosjoukolle riippumatta siitä, mitä tietokantaan on tallennettu. Dokumentointi sanoo seuraavaa:
Lisää tarkistussumma, jonka katsotaan olevan kelvollinen tälle muutosjoukolle riippumatta siitä, mitä tietokantaan on tallennettu. Käytetään ensisijaisesti, kun sinun on muutettava muutosjoukkoa etkä halua, että tietokantoihin heitetään virheitä, joissa se on jo suoritettu (ei suositeltu toimenpide).
Kyllä, tätä ei suositella. Mutta joskus vahva valotaikuri hallitsee myös tummia tekniikoita.
Tapaus 2: Tietoihin perustuva siirto
Oletetaan, että et voi käyttää tietokannan varmuuskopioita live-palvelimista. Petya loi muutosjoukon, testasi sitä paikallisesti ja täysin varmuudella, että hän oli oikeassa, teki vetopyynnön kehittäjälle. Varmuuden vuoksi projektin johtaja selvensi, tarkistiko Petya sen, ja kaatoi sen sitten sisään. Mutta käyttöönotto kehityspalvelimella on laskenut.
Itse asiassa tämä on mahdollista, eikä kukaan ole immuuni tästä. Näin tapahtuu, jos taulukkorakenteen muutokset on jollakin tavalla sidottu tiettyihin tietokannan tietoihin. On selvää, että jos Petyan tietokanta on täynnä vain testidataa, se ei välttämättä kata kaikkia ongelmatapauksia. Esimerkiksi taulukkoa poistettaessa käy ilmi, että muissa taulukoissa on tietueita vieraalla avaimella, jotka liittyvät poistettavan tietueisiin. Tai kun saraketyyppiä muutetaan, käy ilmi, että 100 % tiedoista ei voi muuntaa uuteen tyyppiin.
Miten päättää
- Kirjoita erityisiä komentosarjoja, jotka otetaan käyttöön kerran siirron yhteydessä, ja tuo tiedot oikeaan muotoon. Tämä on yleinen tapa ratkaista ongelma, joka liittyy tietojen siirtämiseen uusiin rakenteisiin migraatioiden jälkeen, mutta jotain vastaavaa voidaan soveltaa ennenkin, erikoistapauksissa. Tämä polku ei tietenkään aina ole käytettävissä, koska tietojen muokkaaminen live-palvelimilla voi olla vaarallista ja jopa kohtalokasta.
- Toinen hankala tapa on muokata olemassa olevaa muutosjoukkoa. Vaikeus on, että kaikki tietokannat, joissa sitä on jo käytetty nykyisessä muodossaan, on palautettava. On täysin mahdollista, että koko taustatiimi joutuu keräämään tietokannan paikallisesti tyhjästä.
- Ja yleisin tapa on siirtää tietoongelma kehittäjän ympäristöön, luoda sama tilanne uudelleen ja lisätä uusi muutossarja, rikkinäiseen, joka ohittaa ongelman.
Yleisesti ottaen mitä enemmän tietokanta on koostumukseltaan samanlainen kuin tuotantopalvelintietokanta, sitä epätodennäköisempää on, että siirtoon liittyvät ongelmat menevät pitkälle. Ja tietysti, ennen kuin lähetät muutosjoukon arkistoon, sinun tulee miettiä useita kertoja, rikkooko se jotain.
Tilanne 3. Liquibasea aletaan käyttää sen jälkeen, kun se on tullut tuotantoon
Oletetaan, että tiiminvetäjä pyysi Petyaa ottamaan Liquibasen mukaan projektiin, mutta projekti on jo tuotannossa ja tietokantarakenne on jo olemassa.
Vastaavasti ongelmana on se, että kaikilla uusilla palvelimilla tai kehittäjäkoneilla taulukkotiedot on luotava alusta alkaen ja jo olemassa olevan ympäristön on pysyttävä johdonmukaisessa tilassa valmiina ottamaan vastaan uusia muutosjoukkoja.
Miten päättää
On myös useita tapoja:
- Ensimmäinen ja ilmeisin on erillinen komentosarja, joka on otettava käyttöön manuaalisesti, kun uusi ympäristö alustetaan.
- Toinen, vähemmän ilmeinen, on käyttää Liquibase-siirtoa, joka on eri Liquibase-kontekstissa, ja käyttää sitä. Voit lukea lisää Liquibase Contextista täältä: . Yleisesti ottaen tämä on mielenkiintoinen mekanismi, jota voidaan menestyksekkäästi soveltaa esimerkiksi testaukseen.
- Kolmas polku koostuu useista vaiheista. Ensin on luotava siirto olemassa oleville taulukoille. Sitten sitä on käytettävä johonkin ympäristöön ja siten sen hash-summa saadaan. Seuraava askel on alustaa tyhjät Liquibase-taulukot ei-tyhjällä palvelimellamme, ja voit manuaalisesti laittaa tietueen "ikään kuin sovelletusta" muutosjoukosta tietokannassa jo tehdyillä muutoksilla taulukkoon, jossa on muutosjoukkojen käyttöhistoria. Siten jo olemassa olevalla palvelimella historia alkaa versiosta 2 ja kaikki uudet ympäristöt toimivat samalla tavalla.
Skenaario 4: Muuttoliikkeet kasvavat valtavasti, eivätkä pysy perässä
Palvelukehityksen alussa Liquibasea käytetään pääsääntöisesti ulkoisena riippuvuutena ja kaikki migraatiot käsitellään sovelluksen käynnistyessä. Ajan myötä saatat kuitenkin törmätä seuraaviin tapauksiin:
- Muuttoliike muuttuu valtavaksi ja kestää kauan.
- On tarpeen siirtyä hajautetuissa ympäristöissä, esimerkiksi useissa tietokantapalvelimissa samanaikaisesti.
Tässä tapauksessa siirtojen käyttäminen liian pitkään johtaa aikakatkaisuun, kun sovellus käynnistyy. Myös siirtojen soveltaminen sovellusesiintymäkohtaisesti voi johtaa siihen, että eri palvelimet eivät ole synkronoituja.
Miten päättää
Tällaisissa tapauksissa projektisi on jo suuri, ehkä jopa aikuinen, ja Liquibase alkaa toimia erillisenä ulkoisena työkaluna. Tosiasia on, että Liquibase kirjastona kootaan jar-tiedostoksi ja voi toimia riippuvaisena projektin sisällä sekä itsenäisenä.
Offline-tilassa voit jättää siirtojen soveltamisen CI-/CD-ympäristöösi tai järjestelmänvalvojien/käyttöönottajien harteille. Tätä varten tarvitset Liquibase-komentorivin . Tässä tilassa on mahdollista käynnistää sovellus, kun kaikki tarvittavat siirrot on suoritettu.
johtopäätös
Itse asiassa tietokantasiirtojen kanssa työskentelyssä on paljon enemmän sudenkuoppia, ja monet niistä vaativat luovaa lähestymistapaa. On tärkeää ymmärtää, että jos käytät työkalua oikein, suurin osa näistä ansoista voidaan välttää. Tarkemmin sanottuna minun piti kohdata kaikki luetellut ongelmat eri muodoissa, ja osa niistä johtui jambeistani. Pohjimmiltaan tämä tapahtuu tietysti huolimattomuuden vuoksi, mutta joskus - rikollisen kyvyttömyyden vuoksi käyttää työkalua.
Lähde: will.com