WordPress ja data migration -skriptit
WordPress-projekteissa data ei ole koskaan täysin paikallaan. Sivustoja siirretään palvelimelta toiselle, rakenteita muutetaan, custom post typeja uudistetaan ja metadatamalleja refaktoroidaan. Tässä kohtaa data migration -skriptit nousevat kriittiseen rooliin. Ne eivät ole vain kertaluonteisia apuvälineitä, vaan osa kestävää WordPress-arkkitehtuuria.
Hyvin tehty migraatio on näkymätön. Huonosti tehty migraatio kummittelee tuotannossa vuosia.
Mitä data migration tarkoittaa WordPressissä
WordPressin kontekstissa data migration voi tarkoittaa esimerkiksi:
-
sisällön siirtämistä vanhasta rakenteesta uuteen
-
custom field -mallin muuttamista
-
taulurakenteiden päivittämistä
-
multisite-siirtoja
-
ympäristöjen välistä synkronointia
-
kolmannen osapuolen järjestelmästä tuontia
Migraatio ei ole pelkkä export–import, vaan hallittu muutos tietomalliin.
Miksi manuaalinen migraatio ei skaalaudu
Manuaalinen lähestymistapa:
-
phpMyAdmin
-
SQL-pätkät lennosta
-
copy-paste
-
ad hoc -skriptit
Toimii pienessä mittakaavassa, mutta epäonnistuu kun:
-
dataa on paljon
-
migraatio pitää toistaa
-
virhe pitää perua
-
ympäristöjä on useita
Migraatio ilman skriptiä ei ole toistettavissa, eikä siis luotettava.
Migraatiot osana koodia
Kestävä malli on käsitellä migraatioita kuten koodia:
-
versionhallinnassa
-
dokumentoituna
-
toistettavana
-
testattavana
WordPressissä tämä tarkoittaa yleensä:
-
PHP-skriptejä
-
WP-CLI-komentoja
-
ajettavia migraatioluokkia
Migraatio ei ole tapahtuma, vaan prosessi.
WP-CLI migraatioiden perustana
WP-CLI on luonnollinen alusta migraatioille.
Hyödyt:
-
pääsy WordPressin APIin
-
ei aikarajoja kuten HTTP-pyynnöissä
-
voidaan ajaa hallitusti
-
helppo automatisoida
WP-CLI-migraatio:
-
lukee vanhan datan
-
muuntaa sen uuteen muotoon
-
validoi tuloksen
-
kirjaa tehdyt muutokset
Tyypilliset migraatiotilanteet
Custom field -rakenteen muutos
Esimerkki:
-
vanha meta_key poistuu
-
uusi rakenne käyttää JSONia
-
data täytyy muuntaa kaikille postauksille
Tämä on klassinen migraatio, jota ei voi hoitaa käsin turvallisesti.
Custom tables ja niiden päivitykset
Kun käytössä on custom-tauluja:
-
sarakkeita lisätään
-
indeksit muuttuvat
-
datan muoto vaihtuu
Migraatio vastaa siitä, että vanha data säilyy ehjänä.
Multisite-siirrot
Multisite tuo lisäkerroksen:
-
blog_id:t
-
käyttäjien site-kohtaiset oikeudet
-
domain mapping
Migraatio ilman skriptiä on käytännössä mahdoton.
Idempotenssi on kaiken ydin
Hyvä migraatio on idempotentti:
-
sen voi ajaa useamman kerran
-
lopputulos on sama
-
se ei riko dataa
Käytännössä tämä tarkoittaa:
-
tarkistuksia ennen muutoksia
-
versionumeroita
-
migraatiolokia
Migraatio, jota ei voi ajaa uudelleen, on riski.
Migraatioiden versiointi
Yleinen malli:
-
yksi migraatio = yksi muutos
-
migraatiolla on ID tai versio
-
järjestelmä tietää, mitkä on ajettu
Tämä estää:
-
tuplamuunnokset
-
osittaiset ajot
-
epäselvän tilan
WordPress ei tarjoa tätä valmiina, mutta malli on helppo toteuttaa.
Suorituskyky migraatioissa
Migraatiot voivat olla raskaita:
-
tuhansia postauksia
-
miljoonia rivejä
-
paljon metadataa
Hyviä käytäntöjä:
-
batch-prosessointi
-
memory usage -seuranta
-
sleep tai throttle
-
objektivälimuistin hyödyntäminen
Migraatio ei saa kaataa tuotantoympäristöä.
Migraatiot eri ympäristöissä
Migraatiot käyttäytyvät eri tavoin:
-
lokaalissa
-
stagingissa
-
tuotannossa
Siksi:
-
ympäristö tunnistetaan
-
destruktiiviset operaatiot rajataan
-
dry-run on mahdollinen
Tuotantomigraatio ilman varmistusta on uhkapeliä.
Rollback ja virheenkäsittely
Kaikkia migraatioita ei voi perua, mutta:
-
virheet pitää tunnistaa
-
osittaiset ajot kirjata
-
tila palauttaa hallitusti
Hyvä migraatio:
-
pysähtyy virheeseen
-
ei jatka sokkona
-
jättää järjestelmän eheään tilaan
Migraatiot ja tietoturva
Migraatiot koskevat usein:
-
käyttäjätietoja
-
sähköposteja
-
API-avaimia
Siksi:
-
dataa ei logiteta liikaa
-
arkaluonteiset kentät suojataan
-
skriptit eivät jää avoimeksi tuotantoon
Migraatiot ovat hyökkäyspinta, jos niitä ei hallita.
Dokumentointi on osa migraatiota
Ilman dokumentaatiota:
-
kukaan ei tiedä mitä ajettiin
-
virheitä ei osata jäljittää
-
seuraava kehittäjä kärsii
Dokumentoi:
-
miksi migraatio tehtiin
-
mitä se muuttaa
-
miten se ajetaan
-
voiko sen ajaa uudelleen
Lopuksi
WordPress ja data migration -skriptit kuuluvat yhteen kaikissa vakavissa projekteissa. Migraatio ei ole tekninen sivuseikka, vaan keskeinen osa elinkaaren hallintaa. Kun data muuttuu hallitusti, WordPress pysyy vakaana, skaalautuvana ja ylläpidettävänä.
Hyvin tehty migraatio unohtuu. Huonosti tehty muistetaan.
