Haluan tunnustaa jotain.
Kehitän kuukauden aikana useampaa projektia ja teen sen käyttämättä export & import jumppaa, WP Migrate DB Pro -lisäosaa, vastaavia työkaluja tai automaattisia varjoympäristöjä. Silti kehitän projekteja ajantasaisella sisällöllä. Samaan aikaan kollegani työstävät visuaalista puolta tai viilaavat sisältöjä asiakkaan kanssa.
Monelle verkkopalveluprojektien kanssa työskentelevälle tietokantojen manuaalinen export & import tai sitä puoliautomatisoivien työkalujen käyttö tuntuu olevan arkipäivää. Osana normaaleja työvaiheita viikottaisessa ja päivittäisessä tekemisessä.
Asia oli näin meilläkin, kunnes aloimme tekemään verkkopalveluiden kehitystä selkeämmällä back-end / front-end jaolla aiemman mallin sijaan, jossa kehittäjä “omisti” kokonaan jonkin projektin. Samalla kun useampi kehittäjä alkoi työstämään samoja projekteja, meidän piti löytää malli jossa kaikilla on tuorein versio tietokannasta helposti käytettävissä ilman manuaalisia työvaiheita tai konfliktitilanteita sisällön kanssa.
Duden kehitysmalli
Alkuun lienee syytä sanoa muutama sananen mallista, jolla teemme koodia projekteissa. Sen kautta avautuu paremmin, minkä takia kipuilimme ja etsimme ratkaisun tietokantojen export & import suosta ulospääsemiseksi.
Kuten ylempänä todettu, meillä useampi kehittäjä saattaa työstää samanaikaisesti samaa projektia, toinen back-end puolta ja toinen front-endiä. Back-end kehittäjä voi tehdä vaikkapa uuden lohkon valmiiksi ACF:ään sekä lyödä sen sisältöineen paikoilleen oikealle sivulle, lisätä Todoistissa oikeaan projektiin tehtävän lohkon tyylittelystä ja siirtyä heti tekemään seuraavaa lohkoa. Tunti myöhemmin front-end kehittäjä nappaa Todoistista lohkon tyylittelyn työn alle.
Koko tämän työstön aikana kummankaan kehittäjä ei tarvitse välittää tietokannasta, riittää että versionhallinnasta haetaan tuoreimmat muutokset front-end tai back-end työstöhaaraan. Muutama git komentorivikomento ja kehittäjällä on muiden tekemät muutokset suoraan nenänsä edessä.
Mitä tapahtuu näyttöversiossa?
Näyttöversio (eli staging) on se vaihe, missä projektipäällikköinä toimivat graafikot pääsevät rämppäämään verkkopalvelua ja näkemään kuinka leiska on herännyt henkiin. Asiakkaat pääsevät testaamaan toiminnallisuuksia sekä laittamaan sisältöjä paikoilleen ennen palvelun viemistä tuotantoon julkiseksi kaikkien nähtäville.
Sisältöjen syötön kanssa samaan aikaan projektia työstäneet kehittäjät saattavat tehdä vielä viimeisiä hiomisia palvelun taustalogiikkaan tai visuaaliseen puoleen. Koska kukaan ei ole täydellinen, tulee bugejakin vastaan ja niitä kirjataan Todoistiin kehittäjile korjattavaksi. Kun bugikorjausten aika tulee, kehittäjällä on välittömästi näyttöversiossa syötetyt sisällöt käytettävissään.
Kyllä, kehitys- ja näyttötietokanta on jaettu. Samaan aikaan kun palveluun syötetään sisältöjä, kehittäjät voivat omalla koneellaan tutkia niihin liittyviä ongelmia ja korjata ne välittömästi ilman tarvetta export & import rumballe. Bugien korjaamisen lisäksi kehittäjät voivat vaikka luoda uusia lohkoja syöttäen niihin sisällöt valmiiksi tai tehdä kokonaan uuden ominaisuuden. Koodit vaan versionhallintaan, tiedostojen siirto (deploy) näyttöversioon ja uudet valmiit lohkot/ominaisuudet on heti projektipäällikön sekä asiakkaan nähtävillä. Ilman huolta siitä, että tietokantojen siirrossa katoaisi tai ylikirjoittuisi jo syötettyjä sisältöjä.
Miten teemme tämän?
Kuten aiemmin mainittua, kehitys- ja näyttötietokanta on yksi ja sama tietokanta. Käytännössä meillä on täysin erillinen näyttöpalvelin jonka tietokantaan saa yhteyden myös verkon yli tietyin ehdoin. Ei siis mitään erityistä rakettitiedettä, vaan MariaDB:n ja hieman palomuurin konfigurointia. Monen perinteisen ns. jaettua hostingia tarjoavan yrityksen tuotantotietokantapalvelimetkin on täysin avoinna maailmalle (vaikka ei pitäisi). Dudella tuotannon tietokannat ovat täysin erillään kehitysvaiheen tietokannoista ja hyvin rajatun pääsyn takana.
Tuohan on umpihullua!
Kuinka niin? Järjestely mahdollistaa sen, että useampi kehittäjä voi koodata projektia samaan aikaan ilman ylimääräistä veivaamista. Graafikon tai asiakkaan raportoimia bugejakin pääsee tutkimaan ihan suoriltaan, ilman murhetta siitä liittyykö se sisältöihin ja tarvitseeko näyttöversiosta hakea tuore tietokanta sen tutkimista varten.
Asiakkaalle toimitettavan palvelun laadun lisäksi meille on tärkeää työn tekemisen mielekkyys. Tämän tietokantajärjestelyn ansiosta työstä on tullut taas hieman mukavampaa, kun ei tarvitse painia dumppien kanssa. Kysyin kehittäjäkollegoiltani Ronilta ja Henriltä, onko jaetusta tietokannasta ollut harmia työn tekemisessä – yhtään tilannetta ei tullut mieleen.
Ja jos junassa innostuu ravintelivaunun penkin kuluttamisen sijaan koodaamaan, aina voi ottaa tietokannasta kopion omaan paikalliseen kehitysympäristöön junamatkan ajaksi.
Olemmeko pähkähulluja vai neroja? Miten teidän firmassa on ratkaistu tämä ikuinen ongelma tietokantojen veivaamisen kanssa? Haluisitko tulla meille töihin kokeilemaan miltä jaettu kanta tuntuu?
PS. Huijasin vähän, anteeksi. Teen manuaalista export & import jumppaa silloin, kun sivusto julkaistaan näyttöversiosta tuotantoon ensimmäisen kerran tai tuotannosta tarvitsee saada tuore tietokanta kehitystyötä varten. Tätä tehdään kuitenkin ihan vain muutamia kertoja kuukaudessa.
