Versionhallinnan vajaakäyttö

Ohjelmistoja tuottavat organisaatiot tyypillisesti käyttävät versionhallintaa. (Jotkut eivät, vaikka tietävät, että pitäisi. Mutta ei heistä tänään.)  Versionhallintahan on helppoa, kun sen osaa. Vai onko? Tarkastellaanpa asiaa lähemmin.

Kaikki versionhallintaa käyttävät softaorganisaatiot luovat uusia projekteja versionhallintaan, lisäävät uutta koodia, ajoittain jopa palaavat vanhempiin versioihin huomattuaan tehneensä virheitä. Jostain syystä laajamittainen versionhallinnan käyttö tuntuu rajoittuvan tähän.

Branchien käyttö on  vierasta monille. En nyt väitä, että brancheja käyttää vain koodarien kärkiprosentti, tai jotain vastaavan älytöntä. Väitän, että yli puolelle branchit kuitenkin ovat käsitteenä tuttuja, ja ehkä kysyttäessä vastaukseksi saa “totta kai osaan käyttää versionhallintatyökalussani brancheja”. Kuitenkin käytännön toimintaa tarkastellessa brancheja ei koskaan käytetä.

Mistä tämä johtuu? Aiheuttaako tämä haittoja? Voitaisiinko asialle tehdä jotain?

Pidän syitä lähinnä historiallisina. Vanhoissa versionhallintatyökaluissa (CVS ja kaikki sitä edeltävä) branchien tekeminen oli kyllä helppoa, mutta mergeäminen usein työlästä.

Jos brancheja ei käytetä, mutta kuitenkin tehdään normaalia ohjelmistokehitystä, osa koodin hallinnasta tapahtuu väistämättä versionhallintatyökalun ulkopuolella. Tilapäiset kokeilut, päähaaraan kelpaamattoman koodin jakaminen työkaverin kanssa, uuden koodin siirtäminen erilliselle testaajalle tulevat kaikki hankalammaksi. Itse asiassa brancheja käyttämättömät organisaatiot usein sallivat päähaaraan koodia, jonka ainoa testaus on kehittäjän oma smoke test, usein vielä puutteellisemmin ainoa testaus on kääntyykö koodi.

Tilanteen korjaus alkaa sillä, että varmistetaan käytössä olevan modernin versionhallintajärjestelmän, jossa mergeäminen on mahdollisimman yksinkertaista. Jopa Subversion täyttää tämän ehdon. Distributoitujen versionhallintajärjestelmien muut edut saattavat tosin puoltaa siirtymistä niihin, jos järjestelmänvaihtoon ryhdytään.

Organisaatiossa tulee eksplisiittisesti käsitellä versionhallinnan käyttöä. Versionhallinnan käytännöistä ei ole ainakaan tällä hetkellä yhtä oikeaa tapaa, jonka voitaisiin olettaa olevan kaikille alan ammattilaisille tuttu. Koska on monta oikeaa tapaa, pitää valita niistä yksi, ja tehdä selväksi mikä on valittu.

Tässä muutamia käyttötapauksia, joiden avulla voi miettiä, ovatko versionhallintaprosessit kunnossa. Jokaisessa kysymys on, onnistuuko tehtävä versionhallinnan sisällä, vai pitääkö siitä poistua ja joutua ad hocin vaaralliseen maailmaan.

• Poistun töistä ja jatkan kotona täysin keskeneräisen toiminnallisuuden toteuttamista.
• Saan toiminnallisuuden valmiiksi ja annan sen testausosastolle testattavaksi. En voi laittaa sitä päähaaraan, koska en tiedä rikkooko se softan kaikille muille.
• Toimitan asiakkaalle testatun snapshotin koodista
• … jota sekä asiakas että Codento ovat kehittäneet sitten viimeisen synkronisaation
• … ja asiakkaan versionhallintaan ei meillä ole suoraa pääsyä.
• Totean kesken olevan ominaisuuteni olevankin oikeasti kaksi ominaisuutta, ja jaan kehityshaaran kahtia ja luovutan toisen Santerille.

Tämän kaiken mahdollistaminen on nykyisillä versionhallintatyökaluilla enemmänkin hallinnollinen ja organisaatiokulttuurillinen ongelma kuin tekninen. Subversion toimii. Mercurial toimii (kunhan siinä on local branchs -laajennus). Git toimii (kunhan dokumentaation yliteoreettisuudesta päästään yli, esimerkiksi kirjoittamalla runsaasti esimerkkejä siitä, kuinka paikallisten käytäntöjen mukaan toimitaan).