Software Configuration Management Plan Michiel De Keyser Configuration Manager van Software Engineering groep 3 December 14, 2010 Versie Datum Beschrijving 0.1 3 November 2010 Eerste ruwe versie 0.2 3 November 2010 Nagekeken door Quality Manager 1.0 13 December 2010 Aanpassingen gemaakt aan de hand van feedback van assistenten 1
Contents 1 Introductie 3 1.1 Afkortingen............................ 3 2 SCM management 3 2.1 Organisatie............................ 3 2.2 SCM-verantwoordelijkheden................... 3 2.2.1 Configuration Manager.................. 3 2.2.2 Backup Configuration Manager............. 4 2.2.3 Groepsleden........................ 4 2.3 Toegepast beleid, richtlijnen en procedures........... 4 3 SCM activiteiten 5 3.1 Configuratie identificatie..................... 5 3.1.1 Identificatie van configuratie items........... 5 3.1.2 Benoemen van configuratie items............ 5 3.1.3 Verkrijgen van configuratie items............ 6 3.2 Configuratiebeleid......................... 6 3.2.1 Veranderingen aanvragen................. 6 3.2.2 Veranderingen evalueren................. 6 3.2.3 Aanvaarden of niet aanvaarden van veranderingen... 6 3.2.4 Veranderingen implementeren.............. 6 3.3 Configuratie status........................ 7 3.4 Configuratie evaluatie....................... 7 3.5 Interfacebeleid........................... 7 4 SCM resources 7 5 Onderhoud van het SCMP 7 2
1 Introductie Dit document bevat het Software Configuration Management Plan in het kader van het project van Software Engineering groep 3. Het project bestaat er in een website te bouwen die het mogelijk maakt zogenaamde location based games te spelen. Het SCMP beschrijft de afspraken die binnen het team gelden over Subversion, het gekozen version control system. 1.1 Afkortingen SCMP: Software Configuration Management Plan SCM: Software Configuration Management VCS: Version Control System VC: Version Control CM: Configuration Manager CI: Configuration Item PM: Project Manager SVN: Subversion 2 SCM management 2.1 Organisatie Het Version Control System staat onder het beheer van de Configuration Manager. Indien hij niet beschikbaar is neemt de back up Configuration Manager dit van hem over. 2.2 SCM-verantwoordelijkheden 2.2.1 Configuration Manager De Configuration Manager is verantwoordelijk voor het opstellen, onderhouden en uitvoeren van het Configuration Management Plan. Hij beheert 3
de VCS repository en ondersteunt de groepsleden met eventuele problemen met VC tools. Problemen met de repository zelf worden door hem opgelost. Michiel De Keyser is voor dit project aangesteld als Configuration Manager. 2.2.2 Backup Configuration Manager De Backup Configuration Manager neemt de functies en verantwoordelijkheden van de CM over indien deze afwezig of onbeschikbaar is. Ruben Tytgat is voor dit project aangesteld als back up Configuration Manager. 2.2.3 Groepsleden De overige groepsleden dienen de regels te volgen die beschreven zijn in dit document. Voor informatie en verdere uitleg kunnen zij terecht bij de CM. 2.3 Toegepast beleid, richtlijnen en procedures De CM maakt wekelijks een complete backup van de gehele repository. Alle huidige en vorige versies van de CI s worden bijgehouden en zijn steeds beschikbaar voor alle leden van het team. De repository is publiek beschikbaar op de website van de groep. Alle groepsleden dienen het Branch-When-Needed systeem te volgen wanneer er gewerkt wordt aan de code van het project: Regel 1: Individueel werk dient (minstens) dagelijks gecommit te worden. Regel 2: De code in de trunk moet ten allen tijden compileerbaar en werkend zijn. Regel 3: Elke afzonderlijke commit mag niet zo groot zijn dat deze peer-review ontmoedigt. In de praktijk betekent dit dat code die gecommit wordt leesbaar en van beperkte lengte is. Bij elke commit moet eveneens een beschrijving van de gemaakte wijzigingen geleverd worden. Regel 4: Wanneer regel 2 en regel 3 conflicterend zijn moet de gebruiker een aparte branch aanmaken om zo peer-review mogelijk te maken zonder de trunk te destabiliseren. 4
Peer-review: alle groepsleden worden aangemoedigd (maar niet verplicht) om zo veel als mogelijk de code van andere groepsleden na te kijken. Gevonden bugs worden gemeld via Mantis, het bug tracking systeem van de groep. 3 SCM activiteiten 3.1 Configuratie identificatie 3.1.1 Identificatie van configuratie items De repository werkt met een boomstructuur. De rootdirectory splitst op in een trunk, branch(es), tags en andere directories waarin de individuele CI s bewaard worden. Elk configuratie item is toegewezen aan een groepslid die dan eigenaar wordt van dat configuratie item. 3.1.2 Benoemen van configuratie items Zoals hierboven vermeld is bevinden de CI s zich in verschillende mappen, nl. trunk, branches, tags, docs en website. trunk: deze directory bevat de stabiele source code van het gehele project. branch: code die zich afsplitst van de trunk en verder apart van de trunk ontwikkeld wordt. Wanneer de code in de branch stabiel en bugvrij is wordt deze toegevoegd aan de trunk (merging). tags: een kopie van een of meerdere CI s die enkel gelezen mogen worden. Het is een snapshot van de code op een bepaald moment tijdens de levensduur van het project. Een tag heeft meestal een naam die voor een menselijke lezer meer betekenis heeft, bijvoorbeeld release-1.0. docs: documenten opgesteld door leden van de groep komen in deze map terecht. website: de source code van de website De groepsleden dienen de volgende regels te volgen als zij hun CI s benoemen: 5
Spaties worden vermeden. In de plaats daarvan wordt een underscore, een punt of een liggend streepje gebruikt. Java-bestanden beginnen steeds met een hoofdletter en bevatten geen spaties. Aparte woorden krijgen een hoofdletter en worden aan mekaar geschreven. Bijvoorbeeld: MijnKlasse. Documenten die in docs komen de staan krijgen een versienummer mee. 3.1.3 Verkrijgen van configuratie items Er staat geen beperking op het verkrijgen van configuratie items. 3.2 Configuratiebeleid 3.2.1 Veranderingen aanvragen Elk groepslid is vrij om aanpassingen te maken aan CI s waarvan hij de eigenaar is, rekening houdend met de regels in sectie 2.3. Wijzigingen aan een CI waarvan hij niet de eigenaar is zijn enkel toegestaan na toestemming van de eigenaar of de Project Manager. 3.2.2 Veranderingen evalueren Peer-review wordt aangemoedigd door toepassing van het Branch-when-needed systeem. Bugs worden gemeld op het bug tracking systeem van de groep. Bovendien kunnen opmerkingen gemaakt worden op het forum, via de mailing list en tijdens teamvergaderingen. Het is aangewezen grotere evaluaties van de code tijdens teamvergaderingen uit te voeren. 3.2.3 Aanvaarden of niet aanvaarden van veranderingen De regels in sectie 2.3 dienen gerespecteerd te worden. Zo niet kan de Implementation Manager of Configuration Manager aangebrachte veranderingen weigeren. De Implementation Manager kan daarbuiten altijd veranderingen weigeren en ongedaan maken. 3.2.4 Veranderingen implementeren Veranderingen worden geïmplementeerd met het commit-commando. 6
3.3 Configuratie status De status van de SVN repository kan opgevraagd worden met het statuscommando. Door gebruik te maken van dit commando kan je onder meer te weten komen of je lokale versie van de repository verschilt van de eigenlijke repository en in welke files deze verschillen zich bevinden. Met het diffcommando zijn deze verschillen ook daadwerkelijk te zien. 3.4 Configuratie evaluatie De Project Manager is vrij om de configuratie van de repository te evalueren wanneer hij dit nodig acht. Hij maakt eventuele opmerkingen over aan de Configuration Manager. 3.5 Interfacebeleid Via viewsvn is de SVN repository beschikbaar op de website van de groep. De webmaster heeft controle over deze interface. 4 SCM resources SVN repository op de wilma server (ten laatste beschikbaar op maandag 22 november 2010) viewsvn interface Elk groepslid heeft vrije keuze over de te gebruiken tools om een update/checkout (of andere SVN commando s) uit te voeren op de SVN repository op voorwaarde dat deze tools gratis beschikbaar zijn. Forum op de website van de SE3-groep. 5 Onderhoud van het SCMP Wijzigingen aan het plan dienen besproken te worden tijdens de teamvergaderingen, via de mailing list of op het forum van de groep. Enkel met toestemming van de team manager worden de besproken wijzigingen daadwerkelijk opgenomen in het SCMP. Indien er tussen de teamvergaderingen 7
meer dan drie weken verstrijken informeert de CM naar voorstellen gemaakt op het forum. 8