Software Konfigurationstyring

1. Software Konfigurationstyring Datalogifagets sorte får… Henrik Bærbak Christensen

2. Spørgsmålene • Software udvikles i teams. Det giver ofte nogle ”spændende” oplevelser: • Det virkede igår!!! Det gjorde det altså... • Kunden rapporterer en fejl, som jeg mener, at vi har rettet??? • Hvad er det egentligt, der kører ude ved kunden? • Er bug #37 fixet i release 2.4.9? • Hvem f….. har rettet i mine filer??? • Min rettelser forsvandt da Benny savede oveni! Henrik Bærbak Christensen

3. Versioner og varianter • Det handler om identitet • ’Hvilken version af comm-lib bruger du?’ • ’Jeg skal bruge database interfacet, der passer til Oracle’ • Kunden har rapporteret en fejl i version 2.4.9 • Hvilken version af comm-lib blev der brugt i version 2.4.9? Henrik Bærbak Christensen

4. Samarbejde • Samarbejde vha. fil-organisering • Alle arbejder på et ’shared’ directory •  ’omvendt race-condition’ – hvem save’r sidst? • Hver arbejder på en kopi •  fletning af rettelser meget tidskrævende • Veldefineret ansvar for individuelle kilde-tekster • Omstændeligt ! Henrik Bærbak Christensen

5. Løsningen (!) • Software konfigurationstyring (software configuration management SCM) er en af de få discipliner i software engineering som faktisk har formået at levere (store dele) af varen: • Teoretiske modeller for versions- og variant håndtering som er praktisk anvendelige • Værktøjer til at støtte praktisk arbejde • Dog... Det fleste kommercielle værktøjer benytter modeller på ret lavt abstraktionsniveau... Henrik Bærbak Christensen

6. Centrale begreber • Centralt for SCM er: • Et fælles lager hvori man gemmer (dele af) ens software som det så ud på et bestemt tidspunkt (snapshot) • Et skema for hvorledes atomare og sammensatte software-enheder defineres • Et skema for automatisk identifikation af sådanne snapshots • Et ubegrænset antal individuelle arbejdsområder hvortil man kan hente konfigurationer, videreudvikle dem, samt igen gemme dem i lageret • Et skema for hvorledes samarbejde foregår, oftest i form af en politik for hvorledes konfigurationer gemmes i lageret / arbejdsområderne. Henrik Bærbak Christensen

7. Terminologi ProductSpace (Workspace) ProductSpace (Workspace) VID = check-in() check-out(VID) VersionSpace (Repository) ProductSpace (Workspace) Check-in: Gem en kopi af den nuværende tilstand af arbejdsområdet i versionslageret, og returner en unik identifikation (VID) af det gemte. Check-out: Genskab en tidligere tilstand af arbejdsområdet, identificeret ved VID, i arbejdsområdet. Henrik Bærbak Christensen

8. Terminologi • Atomare enheder: • Den mindste ’udelelige’ enhed som SCM systemet kan håndtere. • Typiske kommercielle systemer har filen som atomar enhed • forskningsbaserede systemer har været helt nede på tegn niveau. • Sammensatte enheder (konfigurationer): • Composite pattern: Veldefineret mængde af atomare og sammensatte enheder • Typiske kommercielle systemer har kataloget/mappen som sammensat enhed Henrik Bærbak Christensen

9. Terminologi • Definition: En konfigurationer en navngiven samling af atomare enheder og andre konfigurationer. • (Design pattern: Composite). • Eks.: • Windows98 er en veldefineret (?) mængde af programmer, dll’er, grafiske resourcer, osv. Henrik Bærbak Christensen

10. Terminologi • Definition: En version, vi, repræsenter tilstanden af en softwareenhed under udvikling til tid i. • Et SCM-systems fornemmeste opgave er at sikre • Automatisk identifikation af versioner • dvs. at det er SCM systemet som egenhændigt bestemmer hvad version vi skal hedde • Organisere versioner i relation til hinanden • dvs. at SCM systemet opretholder en fast struktur af versionerne. Denne struktur er fundamentalt baseret på det tidslige aspekt Henrik Bærbak Christensen

11. Versions identifikation • Standarden for identifikation var i mange år de såkaldte dewey numre: • 1. version kaldes 1.1 • derefter kaldes de 1.2, 1.3, 1.4, 1.5 osv. • Talparret kaldes major og minor revisionnumre • Version 1.3 er yngre end version 1.2. Basta! • Major revision nummeret kan man også inkrementere: • 1.256, 1.257, 2.0, 2.1, 2.2, 2.3, … Henrik Bærbak Christensen

12. Versions identifikation • Dewey-nummeret bliver tildelt ved check-in. • Kun hvis en softwareenhed faktisk er ændret bliver nummeret ændret! • Dvs. hvis man står med version 1.4 og 1.5 af ens fil ’hans.txt’ så er man garanteret at der er sket ændringer imellem de to versioner. Henrik Bærbak Christensen

13. Versions organisering • Dewey-numrene definerer en udvikling over tid af vores software enhed. Dette opfatter man ofte som en orienteret graf. • Grafen kalder vi versionsgrafen. Her er den simpel men den kan hurtig blive meget kompliceret når vi får parallel udvikling af software enheder. hans.txt 1.1 hans.txt 1.2 hans.txt 1.3 hans.txt 1.4 Henrik Bærbak Christensen

14. Et eksempel: Et af de første† • Tichy: RCS = Revision Control System (1982) c:\tmp>ci hans.txt hans.txt,v <-- hans.txt enter description, terminated with single '.' or end of file: NOTE: This is NOT the log message! >> En beskrivelse af Hans >> . initial revision: 1.1 done c:\tmp>ci hans.txt hans.txt,v <-- hans.txt new revision: 1.2; previous revision: 1.1 enter log message, terminated with single '.' or end of file: >> Beskrivelsen er detaljeret yderligere. >> . done RCS gemmer kun differencen mellem to versioner: -storage. c:\tmp>co -l hans.txt hans.txt,v --> hans.txt revision 1.1 (locked) done † Et endnu ældre system er SCCS Henrik Bærbak Christensen

15. RCS realisering • Versionspace: Et subkatalog kaldet RCS med datafiler • Atomar enhed: En tekstfil (speciel håndtering af binære) • Konfigurationer: [ingen understøttelse] • Productspace: Et vilkårligt katalog • Identifikation: • Revision numre: 1.1, 1.2, 1.3 på atomart niveau • Etiketter på konfigurations niveau • Samarbejde: Låsning = pessimistic concurrency • Sidstnævnte er som en monitor abstraktion: Kun een udvikler kan rette ad gangen (men alle kan læse...) Henrik Bærbak Christensen

16. Pessimistic concurrency • RCS’s låse model sørger for en streng sekventialisering af opdateringer på fil-niveau. • Udviklere: ArneBirte • Ofte er det for pessimistisk • Hvis de arbejder i hver sin ’del’ af filen • Hvis eks. Arne glemmer at slippe låsen... • Visse filer bliver let flaskehalsen i systemet hans.txt 1.1 hans.txt 1.2 hans.txt 1.3 hans.txt 1.4 Henrik Bærbak Christensen

17. Konfigurationer • I de ’gode gamle’ dage da ’en fil = et program’ var RCS’s model tilstrækkeligt; men hvis et program består af mange kildetekster går det galt. RCS kan ikke håndtere konfigurationer særlig elegant! • Eksempel: Et program bygges af kildeteksterne W, S, og senere også T Henrik Bærbak Christensen

18. The Selection Problem Application Release 1.0 W 1.3 S 1.1 T 1.1 W 1.4 S 1.2 T 1.2 Application Release 2.0 W 1.5 S 1.3 T 1.3 W 1.6 S 1.4 T 1.4 Henrik Bærbak Christensen

19. Bunden versus generisk • En konfiguration er enten bunden eller generisk: • Bunden: • Identiteten af alle atomare versioner er fastlagt • Generisk: • For mindst een atomar enhed gælder at dens versionsidentitet ikke er fastlagt Henrik Bærbak Christensen

20. Konfigurationer • Øvelse: • Hvor vil man typisk ønske bundne konfigurationer? • Hvad er formålet med bundne konfigurationer? • Hvor har man typisk generiske konfigurationer? Henrik Bærbak Christensen

21. RCS’s løsning • RCS løser ’selection problem’ vha. etiketter: • Man definerer en etiket (=en streng) og den kan man klistre på alle de revisioner, man har liggende i sit workspace: • Men: det virker kun i et katalog ad gangen! c:\tmp>rcs -nRel01:*.txt RCS file: hans.txt,v done Det vil sige at en bunden konfiguration defineres ved at sætte etikette på alle fil-versioner, der indgår i den. c:\tmp>co -rRel01 *.txt hans.txt,v --> hans.txt revision 1.2 done Henrik Bærbak Christensen

22. Problemer med RCS • To umiddelbare problemer ved RCS: • Den pessimistiske låsning • Meget besværligt at håndtere komplekse konfigurationer (dvs. over flere kataloger) Henrik Bærbak Christensen

23. CVS • CVS: Concurrent Version System • Versionspace: En katalogstruktur med rod i CVSROOT • Atomar enhed: En tekstfil (speciel håndtering af binære) • Konfigurationer: Kataloger (rekursivt!) • Productspace: En vilkårlig katalogstruktur • Identifikation: • Revision numre: 1.1, 1.2, 1.3 på atomart niveau • Etiketter på konfigurations niveau • Samarbejde:Optimistic concurrency - dvs ingen låsning • CVS bygger faktisk ovenpå RCS… Henrik Bærbak Christensen

24. Optimistic concurrency • Både Arne og Birte må nu rette i ’hans.txt’ i parallel. • Den første til at checke ind får uden videre lov. • Den næste skal først lave en fletning(merge) inden vedkommende kan få lov. • Fletning: Ved en fletning skal mængden af rettelser siden sidste forgreningspunkt i versionsgrafen forenes. Henrik Bærbak Christensen

25. hans.txt 1.1+  hans.txt 1.2+ hans.txt 1.1+ Optimistic concurrency commit hans.txt 1.1 hans.txt 1.2 hans.txt 1.3 hans.txt 1.4 update En fletning kan naturligvis give en konflikt, som så først skal rettes. En konflikt opstår hvis mere end en person har rettet i det samme område af filen. Henrik Bærbak Christensen

26. Subversion • Versionspace: En rigtig database, flere protokoller for adgang (http, svn, file) • Atomar enhed: En vilkårlig fil (håndterer binær og tekst ligegodt) • Konfigurationer: Kataloger (rekursivt!) • Productspace: En vilkårlig katalogstruktur • Identifikation: • Atomart: Eet globalt og unikt versionsnummer e.g. ’772’ • Konfigurationer: Det samme! Hurra!!! • Samarbejde:Optimistic concurrency - dvs ingen låsning • ‘A better CVS’ Henrik Bærbak Christensen

27. Subversion • Version nummeret er globalt på repository! • se springet fra 708-771 Henrik Bærbak Christensen

28. Subversion • Version nummer metafor • En fuld, dyb, kopi af projekt folderen med det given nummer • “zip det hele fra roden og giv det navnet v772.zip” • Det vil sige at alle ændringer i filer og katalogstruktur bliver gemt • det sidste kan etiketter slet ikke finde ud af • hvad betyder det at en fil IKKE har en etiket? • den er blev slettet? det er ikke tilføjet endnu? • cvs fjerner ikke filer ved check-out • Version nummeret er en entydigt specifikation! Henrik Bærbak Christensen

29. Subversion • Subversion kan tale flere protokoller • HTTP og HTTPS: Med en apache server • I kan f.eks. gratis hoste jeres gruppes projekt på code.google.com • file: brug et katalog på din lokale maskine (eller mounted drev) som repository. svn klienten kan selv opdatere database som ligger deri. • SVN: start en ‘svnserve’ process op på en maskine med reference til en eksisterende database. Henrik Bærbak Christensen

30. TortoiseSVN • [Demo] Henrik Bærbak Christensen

31. Subversion versus CVS • Subversion er en ‘better CVS’ • Stort set samme syntax • Samme gode optimistic concurrency model for samarbejde • Men en væsentlig bedre release og version control model (CVS stinker virkelig der) • Så – skift til Subversion!!! Henrik Bærbak Christensen

32. Branching • Ofte må et produkt vedligeholdes samtidigt i flere forskellige konfigurationer; f.eks. bug-fix releases • Man kan så flette (merge) rettelser fra den ene gren ind i en anden (ofte under stor pine…). hans.txt 1.1 hans.txt 1.2 hans.txt 1.3 hans.txt 1.4 hans.txt 1.2.1.1 hans.txt 1.2.1.1 Henrik Bærbak Christensen

33. Varianter • Versioner udelukker i en eller anden forstand hinanden: Enten bruger man version 1 eller 2. • Varianter, derimod, lever et parallelt liv • Database model til Oracle, dBase, ... • En lokal eller distribueret variant • Variant som får data fra rigtige instrumenter/en stub Henrik Bærbak Christensen

34. Varianter • Varianter håndteres ofte med een af to teknikker • Single-source variant • f.eks. #ifdef i C++ • Variant segregation • Branches i SCM’ tool • Variant segregation problemer • multiple-maintenance problem: Fælles kode i de forskellige branches skal holdes konsistente • kombinatorisk eksplosion af muligheder: Er der tre variationsdimensioner, hver med tre muligheder, er der ialt 27 branches at vedligeholde! Henrik Bærbak Christensen

35. Varianter • Single-source problemer • Kildeteksten bliver overfyldt med meta-information • Svært at følge det logiske flow i kildeteksten • Varianter er ofte karakteriseret ved at være på sætnings-niveau; derfor er SCM branches som regel alt for grovkornede. • Endnu bedre: Brug design patterns til at isolere og afkoble variationspunkter (lav designet til et framework ) Henrik Bærbak Christensen