Ohjelmiston versiohallinta

Zellerin mukaan konfiguraationhallinta (engl. Configuration management, CM) on oppi kehittyvien järjestelmien organisoinnista ja hallinnasta.^lähde?

Konfiguraationhallinta pyrkii määräämään menettelytavat komponenttien ja niiden yhdistelmien tunnistamiseksi, julkistusten ja muutosten hallitsemiseksi, tuotteen tilan kirjaamiseksi, sekä tuotteen täydellisyyden ja yhtenäisyyden varmistamiseksi. Tässä komponenteilla tarkoitetaan ohjelmistoalkioita, joita ovat muun muassa ohjelmatiedostot ja dokumentit.

Zeller erottaa ohjelmiston konfiguraationhallinnan (Software Configuration Management, SCM) perinteisestä konfiguraationhallinnasta ohjelmistojen mukautuvuuden, helpon kopioitavuuden ja monimutkaisuuden kautta. Lisäksi ohjelmistojen konfiguraationhallintaa voidaan automatisoida laajalti, koska komponentit ovat tietokoneen hallinnassa. Pressman jakaa ohjelmiston konfiguraationhallinnan tehtäväalueisiin, jotka ovat muutosten identifiointi, versiohallinta, muutoksenhallinta, konfiguraation laadunarviointi ja muutoksista tiedottaminen.

Pressmanin mukaan versiohallinta yhdistää menetelmät ja työkalut ohjelmistoprosessin aikana luotavien konfiguraatio-objektien eri versioiden hallitsemiseksi. Konfiguraatio-objektin voidaan ymmärtää tarkoittavan esimerkiksi asiakirjaa, ohjelmistokomponenttia tai näiden muodostamia yhdistelmiä. Versiohallinta on yhdistelmä konfiguraationhallinnan menetetelmiä, joiden avulla käsitellään konfiguraatio-objektien eri versioita. Versiot ovat eräänlaisia koonteja tai kuvauksia ohjelmistosta. Ne koostuvat joukosta ohjelmistoalkioita, joita joukko ihmisiä yhdessä kehittää; versiot ovat ohjelmiston muunnelmia. Versiointi on joukko määrätyssä järjestyksessä suoritettavia toimenpiteitä, jotka synnyttävät konfiguraatio-objektista uuden version. Versioinnin toimenpiteitä ovat versioinnin ulottuvuuksien määrittely, version merkitseminen, versioiden välisten erojen tunnistaminen ja version tallentaminen.

Muutokset komponentteihin luovat komponenteista uusia versioita, joiden ulottuvuus määräytyy muutoksen tekijän tarkoitusperän mukaan. Zellerin mukaan versioinnin ulottuvuuksiksi luetaan yleisesti historiallinen, looginen ja yhteistoiminnallinen versiointi.

Historiallinen versiointi on kehitystä, jossa uudempi versio syrjäyttää aiemman. Tällaisia syrjäyttäviä versioita kutsutaan revisioiksi (revision). Looginen versiointi on niin kutsuttujen haarojen (branch) luomista, jossa kukin haara kuvastaa kehityksen vaihtoehtoista kulkua. Haarat etenevät omaa kehityskaartaan muista haaroista riippumatta, toisin kuin historiallisessa versioinnissa, jossa uudemmat revisiot syrjäyttävät vanhemmat. Vaikka haaroja voidaan integroida toisiinsa, looginen versiointi korostaa rinnakkaista kehittämistä ja haarojen keskinäistä autonomisuutta.

Yhteistoiminnallinen versiointi on väliaikaisuuden hallintaa siten, että tarkoituksena on luoda hetkellisiä versioita komponenteista, jotka tullaan myöhemmin integroimaan toisten versioiden kanssa. Loogisessa versioinnissa esiintyvän haarautumiseen verraten kyseessä ei ole vaihtoehtoinen kehityssuunta, vaan pikemminkin hetkellinen poikkeama, joka useimmiten on seurausta kehitystilanteessa esiin tulleesta tarpeesta, mutta joka jo luonnin hetkellä tiedostetaan yhdistettäväksi toiseen versioon myöhemmin.

Historiallisessa versioinnissa revisiot järjestetään ja ne identifioidaan järjestyksen mukaan. Identifioiminen voidaan tehdä esimerkiksi numeerisesti siten, että suurin luku viittaa viimeisimpään revisioon. Tällöin revisioita merkittäessä käytetään yleensä kaksitasoista numerointia muodossa [V.R], missä V kuvastaa julkaisunumeroa ja R tasonumeroa. Julkaisunumeroa kutsutaan myös versionumeroksi ja tasonumeroa revisioksi. Julkaisunumeron muutos kuvastaa suurta muutosta ja revisionumeron muutos pienempää muutosta.

Joskus versioninnissa käytetään lisäksi kolmatta tasoa, joka ilmaisee ohjelmaan tehdyn paikan (patch). Paikkausversioita käytetään ohjelmavirheiden korjauksissa.

Ohjelmankehityksessä kehitystason versiot ovat tyypillisesti alle 1.0. Siihen kuuluvat testausversiot alfa-, beta- ja gammatestauksineen. Kun ohjelma on valmis tuotantokäyttöön, se julkistetaan ja senhetkisen ohjelmankehityksen tilan versionumeroksi asetetaan 1.0. Julkistuksen jälkeen ohjelmasta julkaistaan tuotantoversion päivityksiä. Ne ovat numeroinniltaan yli 1.0. Tuotantoversioiden päivitykset ovat tyypillisesti virheenkorjausversioita tai uusia ominaisuuksia sisältäviä versioita. Versionumeroinnille ei ole olemassa täsmällistä ohjeistusta. Useiden tuotantokäytössä laajalti käytössä olevien ohjelmien versionumero on esimerkiksi 0.15. Ja toisaalta on olemassa ohjelmia, joiden tuotantoversiot eivät täytä käyttäjän näkökulmasta toimivan ohjelman kriteerejä.

Loogisen ja yhteistoiminnallisen versioinnin yhteydessä esiintyvien varianttien merkitsemiseen käytetään useimmiten määrättyjä nimiä numeroinnin sijaan, koska variantit eivät välttämättä esiinny toistensa suhteen järjestyksessä.

Ohjelmistoon tehtyjen muutosten selvittämiseksi täytyy voida selvittää versioiden väliset erot. Koska toisiaan seuraavat versiot, eritoten revisiot, saattavat olla hyvin toistensa kaltaisia, eroavaisuuksien tarkan määrittelyn avulla voidaan keskittyä muutokseen ja säästää resursseja. Perinteisesti versioiden välisten erojen tunnistamisella on pyritty säästämään tallennustilaa.

Yleinen tapa erojen tunnistamiseen on suorittaa merkkivertailu tekstitiedostojen välillä. Kyseisen tavan tavoitteena on löytää pienin joukko muutoksia, jotka täytyy suorittaa komponentin version A muuttamiseksi versioksi B. Kyseinen metodologia ei kuitenkaan päde kuin tekstitiedostoja käsitellessä, sillä esimerkiksi binääritiedostoissa pieni paikallinen muutos saattaa tiedoston rakenteesta riippuen vaikuttaa koko tiedoston sisältöön.

Ohjelmistojen kehityksen ja ohjelmiston aikaisempien versioiden uudelleenrakentamisen mahdollistamiseksi on vanhat ja uudet versiot voitava tallentaa pysyvästi. Hyvin yleinen tapa on käyttää varastoja (engl. repository), jonne konfiguraatio-objektien versiot ja niitä koskevat konfiguraationhallinnan tiedot tallennetaan. Tallennuksessa on pyritty hyödyntämään myös valmiita tietokantajärjestelmiä, mutta käyttöä rajoittaa se, ettei niissä yleensä ole tukea versioinnille.

Usein varastoissa käytetään tallentamiseen puurakennetta, jossa puun juuri kuvastaa konfiguraatio-objektin ensimmäistä versiota ja juuren jälkeläiset kuvastavat konfiguraatio-objektin myöhempiä versioita. Historiallinen versionti on puun syvyyden kasvattamista ja looginen versiointi puun haarautumista.

Tilansäästön vuoksi varastoihin tallennetaan eri versioista vain niiden väliset erot. Tämä muutostieto on kohdassa 2.5 esitetty minimaalinen muutosjoukko, jonka perusteella komponentin tietty versio A voidaan muuntaa versioksi B. Kyseistä minimaalista muutosjoukkoa kutsutaan deltaksi. Varastot voivat laskea deltoja kumulatiivisesti ensimmäisestä versiosta lähtien niin, että vain komponentin ensimmäisen versio säilytetään kokonaisuudessaan. Varastot voivat laskea muutostietoja myös toisin päin, jolloin varastoon tallennetaan komponentin uusin versio kokonaisuudessaan ja sen mukana muutostiedot aikaisempien versioiden konstruoimiseksi. Koska komponentin versioiden väliset erot ovat tavallisesti komponentin kokoon nähden pieniä, on deltoja hyödyntämällä saavutettava tilansäästö merkittävä.