Versionhallintasuunnitelma

Projektiryhmä Tete Työajanseurantajärjestelmä Versionhallintasuunnitelma

Muutoshistoria Version Date Author Description 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja 0.20 19.10.2003 Tuomas Heino 0.21 20.10.2003 Tuomas Heino 1.00 26.10.2003 Niilo Fredrikson Oikoluku/hyväksyntä toimitusta varten: korjauksia, selvennyksiä ja ulkoasun viimeistely dokumenttimallin mukaiseksi. 2.00 1.12.2003 Niilo Fredrikson Korjauksia + hyväksyntä palautusta varten 2.01 1.12.2003 Pauli Aho Hienosäätöä

Sisällysluettelo Muutoshistoria... Sisällysluettelo... 1. Johdanto... 1.1 Versionhallinnan tarkoitus... 1.2 Laajuus ja rajaukset... 1.3 Sanasto ja määritelmät... 2. Versionhallinta... 2.1 Versionhallintaorganisaatio... 2.2 Versionhallinnan vastuuhenkilöt... 2.3 Versionhallinta ohjelmistoprosessin elinkaaren aikana.... 3. Versionhallinnan aktiviteetit... 3.1 Komponenttien versiointi... 3.1.1 Versioitavat komponentit... 3.1.2 Komponenttien nimeäminen... 3.1.3 Komponenttien tallettaminen... 3.2 Muutoksien hallinta... 3.2.1 Muutospyyntö... 3.2.2 Muutoksen arviointi... 3.2.3 Muutoksen hyväksyminen... 3.2.4 Muutoksien toteuttaminen... 3.2.5 Muutoksenhallinnan työkalut... 3.3 Komponenttien tilan seuranta... 3.4 Komponenttien katselmointi... 4. Versionhallinnan aikataulut...

5. Versionhallinnan resurssit... 6. Koulutus... 7. Versionhallintasuunnitelman päivitys... Viitteet... Liitteet...

1. Johdanto 1.1 Versionhallinnan tarkoitus Versionhallinnan avulla pyritään tukemaan projektin suorittamista projektin tuottaman materiaalin (komponenttien) käsittelyn automatisoinnilla ja niihin liittyvien muutospyyntöjen ja muutoksien tilan seurannalla. 1.2 Laajuus ja rajaukset Koska projekti on kohtuullisen pieni eikä projektiryhmällä ollut aikaisempaa versionhallintakäytäntöä, joudutaan resurssien vähyyden takia versionhallintaan käytetty työmäärä pitämään mahdollisimman pienenä, kuitenkin niin, että versionhallinnasta yritetään saada mahdollisimman paljon hyötyä. Käytännössä aluksi rajaudutaan tiedostojen ja versioiden nimeämiskäytäntöihin, automatisoituun versionhallintaan käyttäen BitKeeper-työkalua, helposti asennettavissa ja käytettävissä olevan kehitysympäristön toteuttamiseen sekä muutospyyntöjen, bugikorjauksien hallintaan Bugzillalla ja kevyehköihin versioitavien komponenttien katselmointeihin. Myöhemmissä vaiheissa voidaan ottaa mukaan myös muitakin ohjelmistotuotteen hallinnan osa-alueita. 1.3 Sanasto ja määritelmät Komponentti Versionhallinta Komponenteilla tarkoitetaan versionhallintaan tallennettavaa materiaalia; dokumentteja, lähdekooditiedostoja, jne. Ks. lisätietoja kohdasta 3.1 Versioitavat komponentit. Versionhallinnalla tarkoitetaan kaikkia ohjelmistotuotteen hallinnan osa-alueita eikä pelkästään ohjelman ja dokumentaation versioiden hallintaa. 2. Versionhallinta 2.1 Versionhallintaorganisaatio Näin suppeassa projektissa versionhallintaorganisaatio koostuu käytännössä vastuuhenkilöistä, eikä mitään muodollista aliorganisaatiota tehdä ainakaan aluksi. Koko projektiryhmä Tete:n organisaatiosta löytyy kuvaus projektisuunnitelmasta. 2.2 Versionhallinnan vastuuhenkilöt Versionhallinnan pääasiallisena vastuuhenkilönä toimii Tuomas Heino. Varavastuuhenkilöä ei ole vielä nimetty. Arkkitehtuurisuunnittelijan (Marko Nikula) vastuulla on huomattava osa kehitysympäristön suunnittelusta ja toteuttamisesta. 3. kappaleessa mainittujen aktiviteettien vastuuhenkilöjä/organisaatiota voidaan määritellä tässä jos projektin laajuus huomioon ottaen näyttää siltä, että niiden määrittely olisi perusteltavissa.

2.3 Versionhallinta ohjelmistoprosessin elinkaaren aikana. Tässä kohdassa voidaan myöhemmin tarkentaa versionhallinnan suhtautumista muihin projektiryhmän organisaatioihin sekä näiden vastuisiin versionhallintaan liittyvissä asioissa, sekä näihin vaikuttavia prosesseja ja muita ulkoisia tekijöitä. 3. Versionhallinnan aktiviteetit 3.1 Komponenttien versiointi 3.1.1 Versioitavat komponentit Kaikki projektin dokumentaatio, tuotettu ohjelmakoodi, testausdata sekä käytettyjen valmiiden komponenttien jakelupaketit talletetaan versionhallintakantaan. 3.1.2 Komponenttien nimeäminen Komponentit tallennetaan hakemistohierarkiaan käyttötarkoituksiensa mukaisiin paikkoihin. Dokumenteissa pidetään yllä sisäistä versiotietoa käsin, mutta mitään tiedostoja ei nimetä version mukaisesti, ts. mitään versiosuffikseja ei käytetä. Projektin ulkopuolelle tiedostoja välitettäessä, kantaan laitetaan leima, jonka avulla kyseinen versio voidaan myöhemmin hakea kannasta. Leimojen muotoa tarkennetaan vielä, mutta alustavasti käytetään seuraavaa käytäntöä: wtas-0.6.0-pre1 versiota 0.6.0 edeltävä testausversio wtas-0.6.0 versio 0.6.0. Jos 0.6.0-pre1 oli tarpeeksi hyvälaatuinen, se voi olla sama kuin tämä. wtas-0.5.17 kehitysversio, joka on todettu edes joiltain osin toimivaksi, minimissään sen täytyy ainakin kääntyä. wtas-0.5.17-tuomas1 version 0.5.17 jälkeinen mistä tahansa syystä nimetty versio, joka voi olla täysin keskeneräinen. Vastaavan tyyppistä nimeämistä voidaan käyttää myös kun toimitetaan jotain keskeneräisiä komponentteja ulkopuolisille, jolloin leiman nimeen voidaan laittaa lisätietoa. 3.1.3 Komponenttien tallettaminen Versionhallinnassa käytetään hajautettua versionhallintakantaa, jolloin kaikilla kehittäjillä on kopio kaikista tiedoista. Tästä johtuen erillistä varmuuskopiointia ei tarvitse suunnitella muuten paitsi siltä osin, että kannasta otetaan aina varmuuskopiot palautusta/toimitusta tehtäessä. Nämä kopiot säilytetään vähintään kolmen eri paikoissa asuvan ryhmän jäsenen tietokoneilla projektin loppuun asti. Vaihtoehtoisesti nämä kopiot voidaan säilyttää myös ulkoisella medialla (cd-rom, yms.), jos tästä menettelystä ei aiheudu merkittävää lisätyötä/lisäkustannuksia. Tällä siis varaudutaan mahdollisiin käytettyjen ohjelmien bugeista aiheutuviin ongelmiin ja muihin epätodennäköisiin katastrofeihin. Versionhallintatyökalu ottaa tarkistussummat kaikista tiedostoista ja muutoksista, joten mahdolliset ongelmat havaitaan todennäköisesti hyvinkin nopeasti, jolloin ryhmän jäsenien on tarkoitus tiedottaa ongelmista versionhallinnan vastuuhenkilöille.

Hajautettu versionhallinta voisi teoriassa toimia haittaohjelmien (matojen/viruksien) leviämiskanavana, joten kannassa olevien triggereiden muutokset joutuu jokainen kannan käyttäjä hyväksymään aina käsin. Tästä aiheutuvaa työmäärää yritetään rajoittaa tekemällä muutoksia triggereihin mahdollisimman harvoin ja tekemällä muutoksien hyväksymisestä mahdollisimman suoraviivaista. Käytännön syistä käytetyt valmiit komponentit talletetaan eri kantaan kuin muut komponentit. Jos valmiiden komponenttien versioihin tulee muutoksia, ne leimataan samalla leimalla kumpaankin kantaan. Lisenssiehdoista täytyy vielä tarkistaa, sallivatko kaikki jakelupaketit tallettamisen kantaan; jos eivät salli, silloin kyseessä olevien komponenttien osalta versiot täytyy kirjata ylös käsin. 3.2 Muutoksien hallinta 3.2.1 Muutospyyntö Muutospyynnön sisältönä tulisi olla vähintään komponentin nimi ja versio (voi olla aluksi tuntematon), pyynnön lähettäjän tiedot, pyyntöhetki, kiireellisyys, muutostarve ja kuvaus pyydetystä muutoksesta / korjattavasta ongelmasta. 3.2.2 Muutoksen arviointi Projektipäällikkö hoitaa muutospyyntöjen alustavan arvioinnin ja hoitaa tarvittaessa arvioinnin asiantuntijoiden avustuksella. Isommista muutoksista voidaan keskustella palavereissa. 3.2.3 Muutoksen hyväksyminen Osa muutoksista voi vaatia hyväksymistä asiakkaalta, osan taas voi hyväksyä osa-alueen vastuuhenkilökin. Kaikkiin projektiryhmän ulkopuolelta tuleviin muutospyyntöihin tarvitaan aina lopuksi projektipäällikön hyväksyntä. 3.2.4 Muutoksien toteuttaminen Kun muutos saadaan tehtyä, siitä tehdään merkintä muutoksenhallintaan. Merkintään laitetaan viittaus muutoksen toteuttavaan ChangeSet:iin (sisältää tiedot komponenteista, niiden versioista ja päiväyksistä), muutospyyntöön ja tiedot verifioinnin ajankohdasta ja toteuttajasta. Merkintä voidaan tehdä ennen kuin verifiointia on tehty, jolloin verifioinnin yhteydessä tiedot päivitetään ajan tasalle. 3.2.5 Muutoksenhallinnan työkalut Muutosten hallintaan käytetään kurssin tarjoamaa Bugzillaa. Jos menettely osoittautuu liian raskaaksi, selvitetään muiden vaihtoehtojen soveltuvuus. Versionhallintatyökalu tukee muutoskokonaisuuden (ChangeSet) käsitettä, joten muutoksen voi poistaa tarvittaessa käytöstä helposti ja sen takaisin käyttöönottaminenkin hoituu yksinkertaisesti. ChangeSetin kommenttiin laitetaan viittaus toteutettuun muutoksen (Bugzillan buginro).

3.3 Komponenttien tilan seuranta Ohjelmiston tilaa seurataan käytettyjen työkalujen raportointiominaisuuksien mukaan. Sekä Bugzillasta että BitKeeperistä löytyy raportointia tukevia osia. Käytäntöjä tarkennetaan tarvittaessa asiakkaan ja projektin tarpeiden mukaan. Komponenteista seurataan ainakin hyväksynnän tilaa, niihin liittyviä muutospyyntöjä ja hyväksyttyjen muutospyyntöjen tilaa. 3.4 Komponenttien katselmointi Komponentit katselmoidaan ennen palautuksia. Tätä aluetta on ajateltu myös projektisuunnitelmassa, joten toistaiseksi sitä ei dokumentoida tässä sen enempää. 4. Versionhallinnan aikataulut Projektin aikataulu käsitellään projektisuunnitelmassa myös versionhallinnan osalta. 5. Versionhallinnan resurssit Komponenttien versionti suoritetaan BitKeeper-versionhallintaohjelmiston avulla niin, että kehittäjien tehtäväksi jäävä versionhallintatyö on mahdollisimman vähäistä, mutta kaikki joutuvat tekemään tästä oman osuutensa. Muutoksien hallinnassa käytetään apuna Bugzillaa ja mahdollisuuksien mukaan BitKeeperiäkin. Komponenttien tilan seurantaa automatisoidaan jonkun verran BitKeeper:n ja Bugzillan avulla. Komponenttien katselmoinnissa käytetään apuna BitKeeper:iä ja Bugzillaa. Tarkemmin tästä työtehtävästä ja sen resursseista projektisuunnitelmassa ja/tai testaussuunnitelmassa. Versionhallinnan resursseja tulee tarkentaa projektin edetessä. Koulutuksesta erikseen alla kohdassa 6. 5.1Versionhallintapalvelimet Hajautetussa versionhallinnassa pääasiallinen versionhallintapalvelin on jt5-255.tky.hut.fi jonka peilaus uuteen työtilaan voidaan tehdä käskyllä bk clone bk://tete@tete uusi_hakemisto (edellytyksenä.ssh/config:ssa tete-aliaksen tiedot ja salainen/julkinen avain, esimerkkejä löytyy hakemistosta util/ssh_config/). Sähkökatkojen, verkko-ongelmien ja muiden vastaavien tilanteiden varalta niksulassa on varalla toinen paikka, jonne muutokset voidaan tarvittaessa keskittää. Edellytyksenä varajärjestelmän käyttöön on.ssh/config:ssa tete2-aliaksen tiedot (kuten yllä teten osalta) ja käytettävät käskyt bk pull bk://iheino@tete2 sekä bk push bk://iheino@tete2 (muutoksien haku/lähetys). Muutoksien lähetys sähköpostilla on myös mahdollista, mutta esimerkiksi word-dokumenttien osalta muutokset ovat yleensä niin isoja, ettei tätä vaihtoehtoa suositella. Sen sijaan testipalvelimen (wtas.tky.hut.fi) käyttäminen on aivan suositeltavissa oleva vaihtoehto. Sillä joutuu BitKeeperin osalta käyttämään hieman monimutkaisempaa urlia, esimerkiksi ssh://tunnus@wtas.tky.hut.fi:/opt/wtas-tunnus osoittaa henkilökohtaiseen testaushakemistoon.

6. Koulutus Versionhallintatyökalujen ja tapojen osalta koulutus koostuu itsenäisesti suoritettavasta puolen tunnin tutoriaalista, tarpeiden mukaan kirjoitettavista ohjeista eri ongelmatilanteisiin ja yleisimpiin kehityksessä tehtäviin toimenpiteisiin sekä ohjatusta koulutuksesta joka yhdistetään aikataulullisesti muuhun kehitysympäristön käytön ja arkkitehtuurin koulutukseen. 7. Versionhallintasuunnitelman päivitys Projektipäällikön tehtäväksi jää tämän dokumentin ylläpitäjän (Tuomas Heino) muistuttaminen suunnitelman ylläpidosta. Suunnitelman sisältö tarkistetaan ainakin I2-iteraation alkupuolella sekä tarvittaessa. Muutoksista suunnitelmaan keskustellaan niiden kanssa, joita ne koskevat tarvittaessa asiaa pohtimaan kasataan sopiva työryhmä. Viitteet Configuration Management Plans: The Beginning to your CM Solution http://www.sei.cmu.edu/legacy/scm/papers/cm_plans/cmplans.mastertoc.html IEEE Std 828-1998: Software Configuration Management Plans Projektisuunnitelma Liitteet