Jutussani Gutenberg-lohkojen tekemisestä viittasin WordPressin kehittämisestä versionhallinnan avulla. Tämä herätti kysymyksiä, joten katsoin tarpeelliseksi avata asiaa – kyse on kuitenkin jutusta, jonka pitäisi olla itsestäänselvä, mutta joka ei sitä välttämättä ole.
Mitä on versionhallinta?
Versionhallinnassa kyse on yksinkertaisesti siitä, että aina kun koodin tehdään muutokset, muutokset tallennetaan versionhallintaan siten, että voidaan nähdä mitä muutoksia on tehty. Versionhallinta mahdollistaa muutosten seuraamisen ja perumisen – jos joku juttu ei toimi, voidaan helposti palata aikaisempaan versioon.
Versionhallintaan on olemassa erilaisia ratkaisuja, mutta de facto -standardi on Linus Torvaldsin kehittämä git. En käsittele tässä muita vaihtoehtoja, koska niihin ei käytännössä törmää (paitsi WordPress-pluginien julkaisussa, jossa vastaan tulee Subversion, mutta harva sitäkään muuhun käyttää).
Git on komentorivityökalu, jonka opetteleminen vaatii vähän vaivannäköä. Peruskomennot kannattaa opetella, mutta elämää helpottavia sovelluksiakin on. GitHub Desktop on hyvä, samoin SourceTree.
Työnkulku versionhallinnan kanssa
Gitissä on kaikenlaista hienoa, mutta webbisivujen kehityksessä pärjää melko vähällä, etenkin jos kehitystyötä tekee yksin. Gitiä voi käyttää webbisivujen kehityksessä kolmella eri tavalla, joista kaikki ovat hyvä parannus siihen verrattuna, että ei käytä ollenkaan:
- Vain paikallisesti. Paikallinen kehitysympäristö ei ole suoraan yhteydessä tuotantoon, eli tiedostot kopioidaan yhä vaikka SFTP:llä, mutta kaikki omassa kehitysympäristössä tehdyt muutokset kirjataan versionhallintaan. Tämä on hyvä lähtökohta, jos palveluntarjoaja ei tue gitin käyttöä kehityksessä ja parempi kuin ei mitään, mutta pidemmän päälle tämä ei ole hyvä.
- Paikallisesti ja web-palvelimella. Kehitystyö tehdään paikallisesti ja muutokset kirjataan versionhallintaan, josta ne pusketaan web-palvelimella olevaan git-repoon, jolloin ne julkaistaan. Tämä on tavanomainen työnkulku silloin kun palveluntarjoaja tukee gitin käyttöä ja kyse on pienemmistä projekteista.
- Paikallisesti, erillisessä git-repossa ja web-palvelimella. Kehitystyö tehdään paikallisesti, jonka jälkeen muutokset pusketaan erilliseen git-repoon vaikkapa GitHubissa ja sieltä julkaistavat muutokset ohjataan sitten tuotantoon. Tämä ratkaisu toimii parhaiten isommille tiimeille ja suuremmissa projekteissa.
Mitä versionhallinnassa kannattaa seurata?
Koko saitin sisältöä ei tietenkään kannata versionhallinnassa pitää. Versionhallinnan kannalta kiinnostavia ovat pääasiassa teema ja itse tehdyt lisäosat. WordPressin tiedostoja, muiden kehittämiä lisäosia tai mediatiedostoja ei kannata versionhallinnassa pitää mukana.
Tähän näppärä työkalu on Composer, joka on PHP-ympäristössä tapahtuvaan riippuvuuksien hallintaan kehitetty ohjelmisto. Composeriin voidaan määritellä saitilla käytettävät lisäosat, jolloin tarvittaessa Composer osaa asentaa WordPressin ja käytetyt lisäosat uudestaan automaattisesti.
Composerin käyttöönotto tyhjästä on sen verran mutkikas juttu, etten sitä tässä esittele sen tarkemmin. Parhaassa tapauksessa palveluntarjoaja hoitaa nämä pohjatyöt puolestasi.
Miten päästä alkuun
Paikallinen versionhallinta
Oletetaan, että on sivusto, joka on hostattuna jossakin, jonne on SFTP-yhteys, mutta palvelimella ei ole käytössä versionhallintaa. Tähän asti muutokset on tehty suoraan palvelimelle, mutta tästä barbaarisesta tavasta halutaan päästä eroon.
Ensin tarvitaan paikallinen kehitysympäristö. Sen saa kaikista helpoimmin Local by Flywheelillä.
Sitten kopioidaan sivusto paikalliseen ympäristöön. Se hoituu kätevimmin All-in-one WP Migrationilla. Asenna lisäosa tuotantoon, vie sivusto tiedostoksi, luo Localiin paikallinen sivusto, asenna sinne lisäosa ja tuo sitten sivusto tiedostosta.
Nyt jos halutaan vaikkapa oma teema versionhallintaan, mennään vain teeman hakemistoon ja annetaan komento git init. Se luo tyhjän git-repositorion. Sitten vain lisätään kaikki tiedostot komennolla git add . ja tehdään commit: git commit -m "Tervetuloa kaunis versionhallinnoitu tulevaisuus!"
Nyt vain aina kun tehdään muutoksia tiedostoihin, muutosten jälkeen annetaan komento git commit -a -m "Fiksattiin asia X" ja muutokset tallentuvat versionhallintaan. Kun avaa hakemiston git-sovelluksessa, on helppo tarkastella muutoshistoriaa ja palata tarvittaessa vanhaan (onnistuu se komentoriviltäkin, esimerkiksi git log näyttää historiaa).
Jos sivuston kanssa työskentelee useampi kehittäjä, git-repositorion voi perustaa GitHubiin, jolloin se on useamman kehittäjän muokattavissa. Jokaisen kehittäjän tekemät muutokset näkyvät kaikille muille.
Muutokset eivät tällä tavalla toimittaessa siirry palvelimelle automaattisesti. Muutetut tiedostot täytyy yhä siirtää käsin esimerkiksi SFTP-ohjelmalla tai rsyncillä.
Tällaisella järjestelyllä on pidemmän päälle ongelmia oman kehitysympäristön pitämisessä ajan tasalla julkaistun sivuston kanssa. Pitäisi kopioida tietokantaa kehitysympäristöön, huolehtia mediatiedoistoista ja niin edelleen – siksi kannattaa pyrkiä järjestelyyn, jossa kehitysympäristö on suoraan yhteydessä tuotantoympäristöön.
Versionhallinta palvelimella
Tässä vaihtoehdossa tyhjästäkin voi lähteä, mutta silloin pitää varautua monimutkaiseen rakenteluun.
Kaikista vaivattominta versionhallintaa käyttävän kehitystyön tekeminen on silloin, jos palveluntarjoaja tukee versionhallintaa ja kehitysympäristöjä suoraan. Tämä alkaa yleistyä ja etenkin jos panostaa hostaukseen sen verran, että ottaa peruswebhotellin sijasta WordPress-erikoistuneen hostauksen, pitäisin git-tukea suorastaan kriittisenä vaatimuksena.
Itse käytän WP-Palvelua, jolla on tarjolla valmis git-tuki ja kehitysympäristö. Uuden projektin aluksi vain kloonataan gitillä kehitysympäristö omalle koneelle. WP-Palvelu käyttää Vagrant-virtuaalikonetta, jolla omalle koneelle saa palvelinympäristön, joka vastaa hyvin pitkälle sitä, missä saitti WP-Palvelun koneilla pyörii.
WP-Palvelun työkaluilla on helppo kopioida tuotannon tietokannan sisältö omaan kehitysympäristöön. Mediatiedostoja ei tarvitse siirrellä, mikä säästää aikaa ja vaivaa, kehitysympäristö osaa näyttää mediatiedostot suoraan tuotannosta. Kehitysympäristö on helppo pitää ajan tasalla – jos tietokanta alkaa olla liian vanha, yksi komento riittää ja tietokanta kopioidaan tuotannosta kehitysympäristöön.
Kun muutokset on tehty paikallisessa kehitysympäristössä, git commit ja git push vie ne suoraan palvelimelle ja starttaa palvelimen uudestaan ilman että tiedostoja tarvitsee siirrellä käsin. Tällä tavoin muutosten tekeminen on sekä vaivatonta että turvallista.
Git-tuki löytyy WP-Palvelun lisäksi muun muassa Zonerin WP-Cloudista, Hostingpalvelun WordPress-webhotellista ja Louhen WordPress-sovellushotellista (ja varmasti monilta muiltakin palveluntarjoajilta), mutta siinä missä WP-Palvelu ohjeistaa kattavasti versionhallinnan ja kehitysympäristön käyttöön, mikään näistä kolmesta ei tarjoa ainakaan julkisilla tukisivuillaan minkäänlaisia ohjeita git-työnkulkujen käyttöön. En pysty siis sanomaan mitään siitä, miten helposti asiat näillä palveluntarjoajilla käyvät.
Versionhallinta on turvallisuutta
Toimit miten tahansa, koodi kannattaa aina pitää versionhallinnan alla. Versionhallinta huolehtii siitä, että pysyt aina selvillä, mikä koodissa on muuttunut, pystyt palaamaan vanhoihin versioihin ja työskentelemään helpommin yhteistyössä muiden kehittäjien kanssa, kun kenenkään ei tarvitse varoa työskentelemistä yhtä aikaa samojen tiedostojen kanssa.
Versionhallintaa voi itse asiassa ulottaa muuallekin kuin koodiin – git toimii erinomaisesti minkä tahansa tekstimuotoisen datan muutosten seurataan.