Ohjelmistoprojektin säilyttäminen ehjänä yhteisessä kehitystyössä



Suurempia ohjelmistoprojekteja kehitetään yleensä ryhmissä, joihin kuuluu useita kehittäjiä. Jokainen kehittäjä tekee jatkuvia muutoksia ja lisäyksiä lähdekoodiin, jotka integroidaan jollakin versionhallintajärjestelmällä kuten esim. Git tai Subversion. Tavallinen ongelma tällaisissa järjestelyissä on, että muutokset usein sisältävät erilaisia virheitä, jotka väliaikaisesti ns. hajottavat kehityksessä olevan ohjelmiston – saattavat sen tilaan, jossa sitä ei pysty käyttämään osittain tai kokonaan.

Tällaiset tilanteet ovat tuhoisia kehittäjien tuottavuudelle: kaikki ryhmän jäsenet joutuvat joko osallistumaan virheen etsimiseen ja korjaamiseen, tai ottamaan tauon kunnes virhe on korjattu jonkun muun kehittäjän toimesta. Epävarmuutta tilanteessa lisää usein myös se, ettei ole selvä kenen aiheuttama virhe on ja sikäli kenen vastuulla sen korjaaminen ensi kädessä on. Pahassa tapauksessa virheen aiheuttaja – ja todennäköisesti paras korjaaja – on jo ehtinyt lähteä paikalta, ja palaa ehkä vasta tuntien tai päivien kuluttua. Hankalan virheen etsintään voi tällöin mennä runsaasti aikaa muilta ryhmän jäseniltä. Lyhyesti sanoen: nämä virheet aiheuttavat tuskaa ja madaltavat ryhmän tuottavuutta.

Viime vuosina yksikkötestaus, hajautetut versionhallintajärjestelmät ja jatkuva integraatio ovat nousseet yhä enemmän suosioon. Yksittäin näillä työkaluilla ja menetelmillä on oma arvonsa, mutta niitä voi myös yhdistää saavuttaakseen yhä enemmän hyötyjä ohjelmistokehityksessä. Yksi tällainen esimerkki on versionhallintasäiliö, joka hylkää muutokset, jotka eivät läpäise ohjelmistoprojektin yksikkötestejä. Olettaen, että yksikkötesteillä on hyvä kate, kehittäjä ei yksinkertaisesta vahingosta tai tahallaankaan saa levitettyä virheellisiä muutoksia muille kehittäjille. Tämä johtuu siitä, että tällainen versionhallintasäiliö hylkää ja siten ei integroi muille jaettavaan lähdekoodiin virheellisiä muutoksia, mikä vuorossaan johtaa siihen, että muut kehittäjät ovat suojautuneet virheellisiltä muutoksilta. Ja mitä suurempi ryhmä, sitä suuremmat hyödyt tästä suojasta.

Virheellisiä muutoksia hylkäävät versionhallintajärjestelmien viritykset näyttävät kuitenkin olevan vasta kehityksen alussa. Esimerkkejä tosimaailmasta löytyy muun muassa Jane Street Capitalin blogista, jossa kerrotaan miten OCaml-lähdekoodi suojataan versionhallintasäiliössä automaattisilla yksikkötesteillä. Tämänkaltaisia ominaisuuksia kaupallisissa tuotteissa on ainakin TeamCityn pre-tested commit. Avoimen lähdekoodin projektissa Hudson vasta suunnitellaan pre-tested commit -ominaisuutta. Enemmän tällaisen menetelmän hyödyntämistä ja varsinkin enemmän valmistuotteita tähän tarpeeseen toivotaan kuitenkin. Kerrothan kirjoituksen kommenteissa jos itselläsi on kokemusta asiasta!

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

4 kommenttia artikkeliin ”Ohjelmistoprojektin säilyttäminen ehjänä yhteisessä kehitystyössä

  1. Millaisessa tilanteessa “pre-tested commit” suojaa ongelmalta, jolta hajautettu versionhallinta ja tavallinen testaus ei suojaisi? Olettaen että haaroja yhdistetään vasta kun ne ovat valmiita ja testattuja.

  2. Aleksi, hyvä kysymys. Ongelma on että hajautetusta versionhallinnasta riippumatta kehittäjät voivat edelleen tuoda virheitä päähaaraan sulattamalla omia virheellisiä kehityshaaroja. Päähaaran ehjeys riippuu siis kehittäjien itsekurista. Osaako kehittäjä aina itse arvioida, onko oma kehityshaara valmis ja ehjä? Tässä suhteessa “pre-tested commit” voi auttaa, koska se on automatisoitu ratkaisu joka estää sekä tahattomat että tahalliset virheelliset muutokset (tai sulatukset hajautetussa versionhallinnassa).

  3. Jos committiin kytketyt testit kirjoittaa eri taho tai kehittäjät harjoittavat parempaa itsekuria niitä kirjoittaessaan, niin pre-tested commit toki auttaa. Rikkinäisen uuden toiminnallisuuden committia nekään eivät tosin estä.

    Blogikirjoituksen ongelmakuvaus vaikuttaa kyllä kovin tutulta. Meillä kuitenkin hajautettuun versionhallintaan siirtyminen ratkaisi sen “riittävän hyvin”.

  4. Se on tosiaan totta että “pre-tested commit” -järjestelyn lisäarvo riippuu kokonaan automatisoitujen testien kattavuudesta. Ja kaikkia virheitä ei ole edes mahdollista tai järkevää havaita automatisoiduilla testeillä. Mutta ne jotka voidaan kannattaa havaita mahdollisimman aikaisin ja mahdollisimman automatisoidusti, esim. versionhallintaoperaatioiden yhteydessä. Se poistaa vielä yhden käsin tehtävän ja muistettavan askeleen kehityssyklistä.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *