Dit is een ouder artikel. Inmiddels werk ik niet meer op dit gebied. Al maak ik zelf wel gebruik van Subversion voor beheer van projecten.
Software configuratie management (SCM) definieert de wijze waarop een organisatie omgaat met veranderingen in code en documentatie.. De basis is het versie beheer van code en documentatie tijdens de software ontwikkeling. Het doel van versie beheer is om op enig moment in de toekomst een bepaalde situatie van het ontwikkelproces in het verleden te reconstrueren. Samen met bug-tracking vormt versie-beheer de noodzakelijke basis van een klassieke software configuratie management systeem. Modern SCM gaat echter verder onderdelen als ‘requirements tracking’, ‘configuratie identificatie’, ‘release beheer’ en ‘auditing’ ondersteunen ontwikkelaar en manager om een kwalitatief betere software te maken in kortere tijd. Met een goed SCM proces is deze kwaliteit ook te bewaken. Uiteindelijk beschrijft een kompleet SCM-proces het volledige traject van productdefinitie tot het uiteindelijke product.
Een succesvolle introductie van SCM begin bij de definitie van het proces, in wezen niets anders dan een verzameling afspraken over de werkwijze binnen het ontwikkelteam. Elk bedrijf heeft zijn eigen cultuur, een standaard oplossing voor SCM is er niet. Doelen van SCM verschillen, is het doel een goede ontwikkelomgeving met archivering te hebben, of het verkrijgen van certificatie zoals CMM en ISO. Het opzetten van een proces en de introductie is maatwerk, de ervaren proces engineer of configuratie manager zal een goede analyse maken van de doelen, en op basis hiervan een proces ontwikkelen. Ook na introductie spelen de proces engineer en configuratie manager een belangrijke rol in de bewaking en verbetering van het proces.
Er zijn legio producten die SCM ondersteunen, commerciële tools voor versie beheer, clearcase, synergy(continuus), sourcesafe, perforce, ptscvs of freeware zoals CVS. Er zijn talrijke bug-tracking methoden, van het gele memo briefje op de muur tot freeware producten zoals gnats, bugzilla, Zentrac en CV Strac, of als onderdeel van een commercieel pakket. Gewenste functionaliteit zal leiden tot een keuze voor uitvoering van SCM is deze keuze niet wezenlijk, een goede configuratie manager zal met elk product uit de voeten kunnen om een team en proces te ondersteunen.
Invoeren van SCM gaat verder dan het simpel installeren van een of meerder producten, een goede begeleiding en training van de medewerkers is vereist om succesvol te kunnen werken.
SCM algemeen – process
Versiebeheer is geen doel op zich maar een middel. Hoewel een schot voor open doel word dit in de praktijk vaak uit het oog wordt verloren, zo van we hebben een tool voor versiebeheer dus we zijn er. Belangrijker is dat heel de organisatie bewust is van de processen die hier aan ten grondslag liggen, bv hoe gaan we met changes om en dergelijke. Ander punt is de verantwoordelijkenheden van de rollen.
Algemene goede-praktijken:
- Identificatie/definitie objecten die onder versie beheer moeten komen en hoe deze op te slaan.
- controle/audit wijzigingen objecten
- organiseer objecten in meer abstracte componenten
- maak baselines op project milestones van componenten (zie 3), objecten hebben versies, componenten hebben baselines (abstractie)
- record en track ‘requests for changes’.
- organiseer consistente set versies in activiteiten, atomic change/deltas (abstractie)
- zie er op toe dat de workspace van gebruiker stabiel en consistent blijft.
- onsteuning van parallel kan voordelen bieden tav sequentieel, echter ook nadelen als men hier te makkelijk mee om gaat
- integreer vaak en frequent.
- reproduceerbaarheid vd software build
Onderstaande in aantal goede en slechte praktijken uit ervaringen. Of een bepaalde manier van werken als meer of minder wenselijk beschouwd moet worden is vaak afhankelijk van het soort en omvang van het project.
Good
In overleg met de architect(en) moet een SCM structuur worden gekozen die overeekomsten heeft met de architectuur en/of incrementele ontwikkeling. Kies componenten die in isolatie te ontwikkelen zijn. enige programmeer en architectuur kennis is belangrijk voor de CM’er, het belangrijkst is de comunicatie met alle andere rollen. vooral in grotere projecten zal de CM een coordinerende rol vd PL op zich nemen betreffende technische aspecten. Vooral in multisite is communicatie erg belangrijk.
Good
Voor ontwikkelaars moet basis kennis van SCM voldoende zijn, streef naar een minimalistisch systeem en flexibel systeem om ballast op de ontwikkelaar klein te houden. Voor de integrator is meer kennis vereist, maar ook hier geld vaak minder is beter. Het is niet nodig dat deze rollen alle kennis hebben om elke situatie aan te kunnen, hiervoor is er de CM’er.
Good
over het algemeen is het verstandig om naast versie beheer op code ook versie beheer op de compiler te doen. Voor Visual C++ en Delphi kun je bv de command line versie opslaan onder versie beheer. Vooral in een grote (multisite) omgeving is het uitermate belangrijk dat iedereen exact dezelfde compiler gebruikt. Automatiseer de build waar mogelijk, maar houdt het eenvoudig mbt maintenance.
Good
Wat voor de bouw-omgeving geld, geld ook voor de test omgeving: de reproduceerbaarheid van de test omgeving zelf. In geval dat het test platform een PC is, is het een goede zaak om test images op een centrale PC te definieren.
Good
Build Early Build Often Test zo vaak en zo vroeg mogelijk. Zorg dat je niet in het eindtraject veel moet testen maar zo iteratief en vroeg mogelijk. De bouw- en test-omgeving moeten dit mogelijk maken
Bad
In de praktijk blijken sommige CM’ers de onstopbare behoefte te hebben om hun eigen software/scripts en dergelijke om het SCM systeem heen te schrijven. Mijn inziens is dit gevaarlijk en erg onderhouds/persoons gevoelig. Hou systeem basic/eenvoudig zonder te veel toeters en bellen die je toch niet of nauwelijks nodig hebt.
Bad
Vaak blijven in werkomgeving van de developer allerlei files staan die niet onder versie beheer staan en daarmee mogelijk invloed hebben op consistentie. Sommige developers hebben de neiging om snel buiten het versiebeheer systeem om zaken te regelen via mail, of ingecheckte versie tijdelijk even van read-only af te halen. Zie hier op toe, opvoeding is vaak het sleutelwoord.
Bad
Verantwoordelijkheden zijn vaak niet duidelijk. Verantwoordelijken mbt verschillende rollen (architect, PL, developer, build manager, config management, test manager) zouden in het (project) CMP moeten staan daar in moeten staan en gedurende het project verfijnen.
Bad
Processen worden onder invloed van tijdsdruk vaak aan de kant geschoven. Met name het test traject heeft daar onder te lijden. Vaak gaat het goed, tot die ene keer