Verkkopalvelun kehittäminen

Verkkosivustoja ja niiden ympärille kehrättyjä kokonaispalveluita työstetään edelleen vähän miten sattuu. Klassinen tapa kehittää Drupal-verkkopalveluja on kirjautua ko. verkkosivustolle niiden asennuksen jälkeen ja tehdä muutoksia suoraan sinne hallintapaneelin kautta. Drupal tarjoaa tähän monipuoliset mahdollisuudet, mutta lähestymistavassa on potentiaalia tehdä paljon tuhoja ja mahdollisesti jopa rampauttaa koko palvelun toiminta. Näin etenkin silloin, jos taustajärjestelmät eivät ole kunnossa.

Tuotantoympäristö vs. kehitys- ja testausympäristöt

Jotta virhetilanteet kyettäisiin hallitsemaan vaikuttamatta julkaistun sivuston eli tuotantoympäristön toimintaan, kehitys tulisi tapahtua tuotantoympäristöstä eriytetyssä kehitysympäristössä. Kehitysympäristön taas tulisi mukailla tai mahdollisesti olla identtinen tuotantoympäristön kanssa, jotta vältytään yhteensopivuusongelmilta.

Kompleksisissa projekteissa kehitysympäristön ja tuotantoympäristön lisäksi on suositeltavaa olla kolmas välitila, jossa kehitysympäristön muutokset voidaan testata toimiviksi tuotantoympäristöstä kloonatussa esittely- ja testausympäristössä. Tätä kutsutaan usein termillä "staging" ja se on näkyvä sivuston tilaajalle jo kehitysvaiheessa. Jos rakennetaan uutta sivustoa, erillinen "stage" toimii usein mainiosti ideoiden ja ratkaisumallien koetinalustana, jonne voidaan jo etukäteen laittaa lopputuotteessa julkaistavaa materiaalia. Usein lopputuote eli uusi sivusto julkaistaankin suoraan testausympäristöstä, jolloin aineistoa ei tarvitse syöttää kahta kertaa. Sisältöä tuottavalla henkilöstöllä on tässä vaiheessa hyvä mahdollisuus harjoitella alustan käyttöä ilman pelkoa sen kummemmista vahingoista.

Miksi kehittämistä ei pidä tehdä tuotantoympäristössä, vaikka se on nopeaa ja tuloksen näkee heti?

•  Jos tuontantoympäristössä uuden asetuksen suorittaman rutiinin päätteeksi tai aikana tulee virhetila, niin käytännössä ainoa tapa korjata ongelma on tutkia palvelimen logeja. Pahimmassa tapauksessa vika estää kokonaan verkkopalvelun käytön, koska virhetilan debuggaus saattaa olla aikaavievää.
• Koodi- tai sisältömuutokset saattavat vaatia tyylimuutoksia teemaan eli sivuston ulkoasuun. Esimerkkinä uusi sisältötyyppi näyttötapoineen.
• Monesti esim. teeman tyylitiedostot on rakennettu css-preprosessorilla. Onko tähän tarvittavat työkalut tuttuja ja/tai onko työkalut asennettu tuotantoympäristöön? Kaikkia työkaluja ei edes saa asentaa kaikkiin web-hotelleihin.
• Vähääkään isompien muutosten testaaminen tuotantoympäristössä on loppujen lopuksi aika vaikeaa häiritsemättä sivujen normaalia toimintaa.

Työnkulun määrittely (workflow)

Onnistuneiden verkkosivujen kehityksessä olennaista on hyvin määritelty työnkulku, seikka joka kannattaa tunnistaa. Kun verkkosivujen kehittäminen ja muutosten käyttöönotto tuotantoympäristössä liitetään osaksi selvästi määriteltyä työnkulkua vältytään monilta tyypillisiltä projektiongelmilta. Silloin kaikilla on tiedossa mitä tehdään, milloin ja miten.

Koodimuutosten siirtäminen ympäristöjen välillä tapahtuu versionhallinnalla. Huomionarvoista työnkulussa on, että versiohallintaan ei oteta tietokantaa eikä sisältöön liittyviä tiedostoja kuten kuvia ja liitetiedostoja. Tietokantaa ei koskaan siirretä tuotantoketjussa tuotantoympäristön suuntaan, vaan ainoastaan tuotantoympäristöstä kehitysympäristön käyttöön. Poikkeuksen tästä tekee "staging" siinä tapauksessa, jos sivuston julkiversio muodostetaan suoraan testiversiosta. Tavallisesti kuitenkin tuotantoympäristön tietokannan voi kopioida testi- ja kehitysympäristöön, mutta kehitysympäristön tai testiympäristön tietokantaa ei tule kopioida tuotantoon. Tietokannan tuorein versio on tällöin aina tuotannossa, jonne tehdään sisällönsyöttö.

Versiohallinta

Esimerkkejä versionhallintajärjestelmistä ovat Git, Subversion, CVS, Perforce, and ClearCase. Versiohallinnalla tarkoitetaan järjestelmää, joka tallettaa ja mahdollistaa koodin versioinnin eli tiedostojen kehitysvaiheiden erottamisen toisistaan. Versiohallinnan avulla uudetkin ohjelmoijat pystyvät omaksumaan ja jäljittämään edeltäjiensä työn, joten muutoksia pystytään tekemään hajautetusti ja kehittäjäriippumattomasti omissa kehityshaaroissaan yhtä aikaa tai paljonkin jälkikäteen.

Versiohallinta kuvataan yleensä puumaisena rakenteena, jossa päähaara (master) kuvaa toimivaa tuotetta. Päähaarasta eriytetään sivuhaaroja, jotka jaetaan yleensä työnkulun mukaisesti kehityshaaraan ja testihaaraan. Testi- ja kehityshaara haaroittuvat yleensä vielä pienempiin yksittäisiä ominaisuuksia kuvaaviksi haaroiksi.

Haaroja yhdistämällä voidaan päähaaran ominaisuuksia laajentaa. Kun uusi ominaisuus on testattu testihaarassa toimivaksi voidaan se yhdistää päähaaraan. Yleensä tässä vaiheessa tuotantoympäristö päivitetään ajantasaiseksi.

Työnkulku versionhallinnan näkökulmasta

Tuotantoympäristön koodi on aina ajantasaisena master-haarassa. Muutokset tuodaan tuotantoon lataamalla uusin koodiversio versiohallinnasta ja ottamalla tuodut ominaisuudet käyttöön.

Uusia ominaisuuksia tehdään aina päähaarasta eriytetyllä haaralla. Päähaaraan tuodaan vain toimivia ominaisuuksia, jotka eivät estä tai häiritse sivujen käyttöä. Toisaalta, jos myöhemmin kuitenkin havaitaan jokin konflikti tai rikkimennyt osa-alue, niin versionhallinnasta saa poimittua toimivan tuotteen eli sivuston tilalle. Vaihdon onnistuminen toki riippuu sivuston kehitysvauhdista eli kuinka paljon muita muutoksia on tällä aikavälillä ehtinyt tapahtua.

Drupal ja workflow

Drupal tukee hyvin koodin versiohallintaa kaikkien tärkeimpien ominaisuuksien osalta. Muun muassa sisältötyypit (Content types), näkymät (Views), kontekstit (Context), kenttien asettelu (Display suite) ja paneelinäkymät (Panels) voidaan kaikki muuttaa koodimuotoon Features-moduulin (Drupal 7) tai Configuration Managementin (Drupal 8) avulla. Koodimuodossa ominaisuudet voidaan ottaa mukaan versiohallintaan ja täten siirtää palvelinympäristöstä toiseen.

Tietokannan kätevään kopiointiin tuotantopalvelimelta voidaan käyttää esimerkiksi Drupalin omaa Backup & Migrate -moduulia. Stage file proxy -niminen moduuli tarjoaa mahdollisuuden käyttää tuotantopalvelimen kuvia kehitysympäristössä siten, ettei niitä tarvitse erikseen jälkimmäiseen ladata. Tämä nopeutta kehitystyötä silloin kun ladattavia kuvia olisi paljon.

---

Kuvituskuva (c) Antti Koistinen