Aina kun tulee puheeksi päivitysten epäonnistuminen, lisäosan yhteensopivuuksien ihmettely tai teeman omituisuudet, niin jossain vaiheessa esille nousee joku, joka käskee käyttämään staging-ympäristöä. Helppoa ja turvallista, ja kaikki onnistuu. Yleensä mouita ehdottava joko tekee dev-hommia tai sivustojen ylläpito keskittyy muutoin tekniikan kanssa näpräämiseen. Staging on jotain, mutta helppoa ja turvallista se ei ole koskaan. Sille on silti määrätty tilaus WordPressin ylläpitomaailmassakin, kunhan ymmärtää rajoitukset – joiden takia Woocommercessa puhutaankin enemmän ajan haaskauksesta kuin toimivasta työkalusta.

Mikä stage ja staging?

Termi tulee englanninkielen näyttämöä ja varsinkin lavastusta tarkoittavasta sanasta – lavastusympäristö olisi ehkä lähinnä osuva ja kertoo mistä on kyse, mutta sitä ei kukaan käytä. Stage-sivusto on kopio aidosta oikeassa palvelinymäristössä, jota käytetään testaamiseen ja kokeiluun. Se ei siis ole varsinainen kehitysympäristö, kuten turhan usein annetaan ymmärtää.

Sivuston, on se sitten WordPress, Jekyll tai mikä tahansa muu, synty ideasta toimivaksi sisällöksi internetissä tehdään ammattimaisella tasolla kolmella portaalla:

• dev-ympäristö
• staging-ympäristö
• tuotanto-ympäristö

Dev-ympäristö on se, missä rakennetaan runkoa. Koodataan javascriptillä, PHP:lle tai millä tahansa muulla työkalulla sivuston rakennetta ja toiminnallisuuksia. Työt tehdään paikallisella serverillä tai missä tahansa, jossa on kehittämiseen ja erillisten palojen testaamiseen sopiva ympäristö. Sillä ympäristöllä on hyvin vähän mitään tekemistä sen kanssa missä sivustot tulevat toimimaan. Tämän osan tekijät suosittelevat aina staging-sivuston perustamista, koska se helpottaa testaamista.

Staging-ympäristön täytyy olla tismalleen samanlainen kuin se, missä sivusto tulee toimimaan. Siksi se käytännössä aina rakennetaan alidomainina samalle serverillä kuin missä varsinainenkin sivusto on tai tulee olemaan. Se on testipenkki. Sinne voidaan tuoda uusia paloja ja laajennoksia, kokeilla mitä teema tekee tai vaikka ihmetellä toimiiko WordPressin päivitys. Mutta se ei ole kehitysympäristö.

Tuotanto-ympäristö on sama kuin live-saitti. Kun ensin on tehty kehitystyöt ja sitten testattu miten kokonaisuus toimii, niin sen jälkeen tyydyttävä (toivottavasti jopa toimiva) kokonaisuus siirretään stagelta tuotantoon ja ihmisten käyttöön.

Marssijärjestys on aina dev > stage > tuotanto. Nyt haluttaisiin kääntää suunta toisinpäin ja tehdä siitä ympyrä: tuotanto > stage (ja dev) > tuotanto > stage (ja dev)…

Ajatus on kaunis ja kaikinpuolin kannatettava. Siinä on vain yksi ongelma. Kun dev siirtyy stageen, niin stage jyrätään. Kun stage siirtyy tuotantoon, niin tuotanto jyrätään. Kun tuotanto siirretään stageen, niin stage jyrätään – mutta tuotanto jää käyntiin. Ongelman nimi on dynaaminen sivusto.

Dynaamisuus on muuttumista

WordPress on dynaaminen järjestelmä. Dynaamisuus tarkoittaa, että sivujen sisältö, aivan koko sisältö, on tietokannassa. Sitten PHP-skriptit käyvät hakemassa erilaisia paloja ja niistä parsitaan se minkä ihmiset näkevät sivustona. CSS- ja muut ulkonäköön vaikuttavat asiat haetaan meikkaukseen aina sen mukaan, mitä haettu sisältö ja sen useat eri pikkuosat sattuvat kaipaamaan.

Tuo kuvaa sivujen periaatteellista rakentamista. Siihen päälle tulevat vaikka katsomiskerrat, kommentit, uudet julkaisut, muutetut tagit, foorumipostaukset, lisäosien API:t, kuvien muuttamiset taustalla eri kokoihin… Tai verkkokaupan tilaukset, laskut, liikenne kaupan ja maksunvälittäjän kanssa, Woocommercen omat säädöt.

Se mikä näkyy WordPressillä tehtynä sivustona on itseasiassa alati muuttuva muurahaispesä.

Jokainen on varmaan katsonut ainakin jonkun aikamatkustukseen liittyvät elokuvan tai sarjan. Niissä esitellään säännönmukaisesti yksi ongelma: aikajanan muuttuminen. Kun Michael J. Fox hurmaa menneiyydessä äitinsä, niin koko tulevaisuudessa syntynyt sisarusparvi alkaa katoamaan – koska on syntynyt uusi aikajana, joka ei ole samanlainen kuin alkuperäinen.

Kun halutaan tehdä testi onnistuuko jiku päivitys tai miten uusi teema vaikuttaa sivustoon, niin tehdään stage-sivusto. Testaillaan aikansa, viritetään ja säädetään, ja kun ollaan tyytyväisiä, niin siirretään stage live-saitin tilalle. Tämähän on se työnkuva, jota dev-taustaiset koodarit aina hehkuttavat.

Annoin yhden koodarin kokeilla tuota. Tiesin mitä tapahtuisi, mutta koska hän oli koodari (hyväpalkkainenkin) ja minä vain webmaster ja sisällöntuottaja, niin hän tiesi paremmin. Hän sääti sivustoani viikon, sai säädettyä haluamansa ja siirsi stagen tuotantoon. Lopputuloksena hän jyräsi jokaisen viikon aikana tekemäni jutun ja jokaikisen verkkokaupan tilauksen. Onneksi olin ennakoinut asian, ja minulla oli backupit kunnossa. Hän ei ollut ottanut huomioon sitä, että hänen stage-haaransa käytti aivan eri tietokantaa ja versiota, kuin mikä oli livenä. Hän oli luonut uuden aikajanan, eikä se liity takaisin vanhaan.

Pahinta ei ollut se, että hän tekee osan elannostaan nimenomaan WordPressiin liittyvillää kehitystöillää. Pahinta oli se, että syy oli minun. Minun olisi pitänyt estää sivuston muuttuminen sillä aikaa, kun hän teki säätöjään. Tervetuloa reaalimaailmaan.

Woocommercen päänsärky

Puhtaalla sisältösivustolla voidaan olla julkaisematta sinä aikana, kun joku säätää ja vääntää. Kommentteja ei tarvitse murehtia, koska ylipäätään kukaan ei koskaan kommentoi mihinkään ja jos joku aihe vetää kommentteja, niin 99 prosentissa tapauksista kommentit ovat täyttä sontaa. Lisäksi kannattaa muutenkin käyttää Disqusia, ei WordPressin aneemisen vanhanaikaista, kömpelöä ja raskasta kommentointisysteemiä.

Verkkokaupat ovat eri asia. Ei niitä voi laittaa telakalle siksi, että joku haluaa säätää checkoutin funnelia.

Woocommercen (ja kaikkien muidenkin verkkokauppaohjelmien) tuotteet ja muunnelmat ovat artikkeita. Kustom-tyyppisiä toki, mutta yhtä lailla ne ovat tekniikalla tismalleen samoja kuin blogipostaukset. Maksuliikenneviestit jne. ovat kommentteja. Joten jos joskus ihmettelet miksi Woocommerce kaikesta huolimatta on kömpelö yllättävissä tilanteissa, niin se johtuu siitä, että Woocommerce on vain lisäosa, joka muuttaa blogin ulkonäön ja näennäisen toiminnallisuuden verkkokaupaksi.

Se, että kaikki julkaistu ja tehty ovat blogipostauksia, aiheuttaa myös sen, että ne löytyvät tietokannasta samasta paikasta. Samasta syystä se, mitä liian monet kuvittelevat laskunumeroksi, on vain artikkelien ID-tunnus ja sen takia se hyppii peräkkäisten tilausten välillä niin paljon.

Kun verkkokauppa siirretään staging-saitille, ja live myy minkä ehtii, niin saa vain yhden kerran arvata kuinka monta konfliktia tulee, kun kehittäjä muuttaa tai lisää yhdenkään artikkelinumeroihin liittyvän asian. Siitä muutoksesta alkaen jokainen ID-numero muuttuu, eikä ole enää mahdollista tuoda syntyneitä tilauksia sisään ennen siirtoa takaisin liveen. Tai tuoda voi, mutta ei toimi.

Ainoa tapa on laittaa verkkokauppa huoltotilaan, tuoda tietokanta stageen, tehdä kaikki muutokset, jyrätä live stagella ja poistaa huoltotila. Kannattaa kokeilla tuota käytännössä ennenkuin alkaa adoptoimaan sitä käytännöksi.

Onko stage turhake ja kategorinen paha?

Staging-sivustoa kannattaa käyttää, mutta tässä on sama kuin aina kaikessa: täytyy ymmärtää mitä työkalu tekee.

Pelkästään päivitysten testaamiseen stage on hieman turha. Rahalla saa kohtuullisen helpon tavan, WP Staging Pro on sellainen, mutta koska sen käyttö ei kuitenkaan poista mitään muita vaadittavia työvaiheita, niin onhan se turhake.

Staging-sivusto on kehitykseen liittyvät testaustyökalu. Jos tee kehitystä, johon toki kuuluu vaikka ikiomien CSS-säätöjen tekeminen, niin stage auttaa. Mutta jokainen muutos ja jokainen työvaihe on dokumentoitava, sillä et pysty painamaan push-nappulaa ja siirtämään muutoksia live-puolella. Tai pystyt, mutta et tuhoamatta alkuperäistä ja kaikkea mitä siellä on tapahtunut kehitystyösi aikana. Push ei yhdistä vanhaa ja uutta jollain tekoälytekniikalla, vaan korvaa kokonaan.

Viimestään tässä vaiheessa esille tulee kaksi vastaväitettä:

• voi siirtää vain muuttuneet tiedostot, ei tietokantaa
• voi muokata tietokantaa ja yhdistää muuttuneet liveen

Jos muutos koskee vain tiedostoja, niin totta ihmeessä noin voi tehdä. Ja kannattaakin. Tosin samalla vaivalla ne siirtäisi suoraan sieltä missä muutokset on rakennettu, koska ei kukaan omaa mielenterveyttään ja karpaalikanaviaan arvostava tee moisia muutoksia stage-sivuston WordPressin omassa editorissa. Siinä on kysymys työkalun käytöstä siihen mihin työkalu on tarkoitettu.

Tietokannan muokkaaminen on enemmän scifiä kuin todellisuutta. Kyllä, se on mahdollista ja joskus joku on jopa onnistunut siinä rikkomatta mitään. Jolu yksinkertainen muutos on helppo, mutta sillä tasolla on vielä helpompaa tehdä hyväksi koettu muutos suoraan live-sivustolle. Sen sijaan verkkokaupan vanhemmat tietokantadumpin ja uuden kehistysversion yhdistäminen jää tekemättä suurimmalta osalta niistä koodareista, jotka totisella naamalla esittävät moista vaihtoehdoksi. Se jää taatusti tekemättä jokaikiseltä webmasterilta.

Ollaan tilanteessa, jossa kehoitetaan käyttämään sellaisia työkaluja, jotka eivät tee mitään siitä mitä niiden väitetään tekevän ja jossa vaaditaan poikkeuksellista teknistä osaamista. Tuo on syy siihen miksi kommentoin aina ilkeästi, kun joku teknokraatti ehdottaa vakavasti stagen toteuttamista, ja aina lisäksi tekijälle paikallisena ratkaisuna – eli omalle tietokoneelle tai ikioman sisäverkon Raspberryyn.

Mikään ei ole niin turhaa kuin neuvo, jota ei voi toteuttaa, mutta silti syyllistää kuulijaa.

Stagen asentamisen perusteet

Jos googlettaa aihetta WordPress+staging+site, niin osumia tulee kelpo määrä. Niistä lähes 100 prosenttia ehdottaa tismalleen samaa tismalleen samassa tekstijärjestyksessä tismalleen samoilla kuvilla. Sitten löytyy pari muuta, jotka ujosti toteavat, että kaunis ajatus, mutta aika toteuttamiskelvoton siinä merkityksessä, kuin mitä yritetään: olisi erillinen suljettu kopio sivustosta, jossa voisi tehdä kaikki muutokset ja jotka sitten saisi nappulan painalluksella siirrettyä tuotantosivustolle.

Jos staging sivustoa käytät, niin kyseessä on sinällään helppo asia.

1. Tee serverille alidomain, kuten testi.example.com ja kerro se myös nimipalvelimelle (cPanelista löytyy kohta sub-domain, käytä sitä)
2. Kopioi kaikki sivuston tiedostot alidomainin hakemistoon
3. Ota kopio sivuston tietokannasta ja tee siitä uusi tietokanta alidomainin käyttöön
4. Muuta tarvittavat kohdat wp-config.php tiedostosta
5. Etsi ja korvaa kaikki originaaliin viittaavat urlit tietokannasta

Tuohon urakkaan voi käyttää backupeja tai sitten lisäosia, kuten Duplicator Pro. Mutta saa sen tehtyä käsinkin ja jos olet virtuaalipalvelimella, niin WP CLI:n ja rsync avulla siirto onnistuu minuuteissa.

MySQL osaa olla kinkkinen. Suurimmalta osalta jää tekemättä yksinkertainen search&replace ja siksi lopputulos, joka vaatisi tietokannan manipulaatiota, on niin syntymässään kuollut temppu.

Mutta jos siirrät tietokannan käsin, niin sinun pitää ajaa nämä kyselyt (muuta tarvittavat kohdat, myös wp_ tunniste)

1. UPDATE wp_options SET option_value = REPLACE(option_value, ‘ALKUPERÄINEN_URL’, ‘UUSI_URL’);
2. UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, ‘ALKUPERÄINEN_URL’, ‘UUSI_URL’);
3. UPDATE wp_posts SET guid = REPLACE(guid, ‘ALKUPERÄINEN_URL’, ‘UUSI_URL’);
4. UPDATE wp_posts SET post_content = REPLACE(post_content, ‘ALKUPERÄINEN_URL’, ‘UUSI_URL’);

Useimmat ohjeet suosittavat lisäksi kahta asiaa:

• estä WordPressin asetuksista hakukoneet
• estä satunnaisten harhailijoiden pääsy

Voi nuo tehdä. Hakukoneiden estäminen tarkoittaa sitten vain ja ainoastaan hyvin käyttäytyviä, kuten Google, MSN, DuckDuckGo jne. ja niissäkin vain silloin, kun sisälle ei johda linkkejä. Joten jos haluat testisivustollesi käyttäjäkokemuksia ja jaat linkin jossain Facebook-ryhmässä tai edes lähetät kutsun mailitse gmail-ihmisille, niin se oli sitten siinä. Sen jälkeen on ihan se ja sama mitä olet asetuksissa kieltänyt hakukoneilta.

Asia on oleellinen siksi, että seuraavaksi Google Search Console on täynnä varoituksia ja uhkailuja tuplasisällöstä. Mutta niin kauan kun et jaa linkkiä julkisesti, niin ei sinne kukaan eksy – paitsi noin 10 000 kiinalaista ja iranilaista script kiddietä, jos erehdyit käyttämään alidomainin nimenä stagea.

Pystyt estämään monellakin tavalla pääsyn stage-sivustolle ilman salasanaa. Useimmat under construction -lisäosat tekevät tuon natiivisti, mutta muitakin tapoja on. Mutta – kannattaako asian eteen nähdä kovinkaan paljon vaivaa? Ensinnäkään ei sinne kukaan vahingossa eksy ja toiseksi – mitä sitten vaikka näkisivätkin ennakkopiipahduksen uudesta sisällöstä tai layoutista?

Aika monilla sivustoille kävijöitä on käytetty tuloksekkaastuí testaajina ja siksi toiseksi ihmiset tykkäävät ajatuksesta, että heitä pidetään hieman parempina kuin muita. Siihen aivan samaan käyttöjärjestelmien beta-testauksetkin perustuvat.

Stagen käyttö

Itse stage-sivuston käyttöhän on helppoa. Teet sille mitä haluat. Helppous loppuu siinä vaiheessa, kun olet saavuttanut sen mitä haluat ja muutokset pitäisi saada julkiseksi.

Mahdollisuuksia on kolme:

• siirrät vain muuttuneet tiedostot ja toistat muut vaiheet ja muutokset live-saitilla
• käytät jotain import/export lisäosaa siirtääksesi haluamasi asiat, yleensä sisältöpuolella
• täydellinen ylikirjoittaminen uudella kokonaisuudella

Olen itse käyttänyt jokaista. Niillä on kaikilla oma käyttöpaikkansa, mutta yksikään ei sovellu joka paikkaan ja kaikkiin tarpeisiin.

Muutosten toistaminen on yleensä fiksuin liike, kun muutat rakennetta tai ulkonäköä. Asennat live-sivustolle saman lisäosan tai teeman ja teet jo kerran kokeilemasi muutokset uudelleen.

Kun muutetaan ja hiotaan sisältöä, niin import/export saattaa olla toimivin tapa. Varsinkin verkkokaupoissa, joissa muutetaan tuotteiden kuvauksia, CSV-tiedoston importtaus on oikeastaan ainoa mahdollisuus.

Täydellinen ylikirjoittaminen tulee vastaan kun suunnilleen kaikki muuttuu. Ulkonäkö, toiminnallisuudet jne. Mutta silloin kannattaa pitää live-versio lepotilassa viimeiset hetket.

Case EksisONE

Minä käytän stage-sivustoja jonkun verrankin. Jopa major-päivitysten toiminnan testaamiseen, vaikka sitä aiemmin arvostelinkin. Mutta minulle on jo kehittynyt työtapa, jossa minun ei tarvitse miettiä ja stage syntyy viidessä minuutissa. Joten tässäkin, niin ehdottomia totuuksia ei ole.

Käytän stagingiä myös sellaiseen, jota voisi etäisesti kutsua devaamiseksi. Aidosti kyse on leikkimisestä ja kokeiluista, ei aidosta kehittämisestä. Jos homma toimii, niin toistan vaiheet uudestaan tuotantosivustolla. Jos ei, niin jossain vaiheessa jyrään stagen tuoreemmalla versiolla live-sivustosta.

Kun teen (yleensä) asiakkaiden Woocommerce-pohjaisiin verkkokauppoihin tekstejä, niin otan eräällä tavalla tynkäversion live-sivustosta käyttöön. Siinä ei ole tarkoitus testailla maksutapoja tai toimitusvaihtoehtoja, vaan ainoastaan varmistaa, että luotu teksi taipuu haluttuun layoutiin ja sivuston henkeen. Olen niin surkean kehnoilla visuaalisilla kyvyillä varustettu, että tarvitsen moista.

git

cp -rf domain.com dev.domain.com

Jakke Lehtonen

Teen B2B-markkinoille sisällöntuottoa sekä UX-testauksia. Samaan liittyy myös koulutukset yrityksille ja webmaailman kanssa muutoin painiville. Serverien sielunelämää on joutunut ohessa opettelmaan. Toinen puoli toiminnasta on koirien ravitsemuksen ja ruokinnan suunnittelua sekä varsinkin omistajien kouluttamista hoitamaan koiriaan oikein ja vielä paremmin.

Profiili: Jakke Lehtonen