Transcript Konfigurasjonsstyring og versjonshåndtering Kirsten Ribu

Konfigurasjonsstyring og
versjonshåndtering
Kirsten Ribu
Konfigurasjonsstyring
Kapittel 15




Konfigurasjonsstyring og
versjonshåndtering
Hvordan håndtere endringer?
Hvordan håndtere versjoner og
releaser?
Verktøy for konfigurasjonsstyring
- CVS, Visual Source Safe,
ClearCase etc.
2
Systemers livssyklus
3
Introduksjon

Dette skal administreres:




Konfigurasjonsstyringsprosedyrer




Endringsforslag, feilrettinger,Tilpasning til maskinvare og
operativsystemer
Mange versjoner kan være i bruk og utvikling samtidig
Hvordan endringer er implementert
Hvordan behandle og registrere endringsønsker
Hvordan knytte disse til systemkomponenter
Hvordan identifisere versjoner
Konfigurasjonsstyringsverktøy



Lagrer versjoner
Bygger systemer av dem
Holder styr på hva som er levert til hvilken kunde
Introduksjon

Konfigurasjonsstyring er ofte kombinert med
kvalitetsstyring


Hvorfor ulike konfigurasjoner?





Baseline: Spesifikasjon eller produkt som er blitt formelt
vurdert og godkjent og som brukes som grunnlag for videre
utvikling. Kan bare endres ved formell
endringskontrollprosess
Plattform
Kundespesifikke funksjoner
Markedshensyn
Konfigurasjonsansvarlig
Konfigurasjonsstyringsprosessen

Standarder finnes:


IEEE 828-1983 konfigurasjonsstyringsplaner
Konfigurasjonsstyringshåndbok
Konfigurasjonsstyring (1)


Konfigurasjonsstyring – disiplin for
å håndtere endringer og ulike
versjoner av komponenter
Konfigurasjonsstyringsverktøy –
støtter håndtering av versjoner av
komponentene og i å konfigurere
(sette sammen) et system
6
Konfigurasjonsstyring (2)



Nye versjoner av et programsystem
lages etter hvert som det endres
Konfigurasjonsstyring støtter
evolusjon av systemer på en
kontrollert måte
Systemendringer er en teamaktivitet
7
Fossefall

Konfigurasjonsstyring ved fossefallsmodellen




Komponentene leveres når de er testet
CM-teamet har ansvar for systemsammenbygging
og testing
Feil som oppdages blir meldt til utviklerne som må
levere en oppdatert komponent
Standardene forutsetter gjerne fossefallsmodell
Introduksjon

CM når fossefallsmodellen ikke blir anvendt dvs.
inkrementell utvikling








Fordeler ved hyppig bygging




Hyppig systembygging
Støtter samtidig utvikling og testing
Tidsfrist for levering av komponenter (kan være skjelett)
Ny versjon bygges av de leverte komponentene ved
kompilering og linking
Systemet leveres til testteamet som kjører tester etter plan
Samtidig arbeider utviklerne videre med systemet
Feil som finnes meldes til utviklerne som må rette dem i
senere versjoner.
Finner integrasjonsproblemer mellom komponenter tidligere
Fremmer bedre enhetstesting før leveranse
Mindre tidsspill med problemer pga dårlig enhetstesting
Utfordringer ved daglig bygging

Holde styr på mange versjoner og feilmeldinger
Viktig

Viktigheten av kunnskap om
konfigurasjonsstyring og bygging


Helt avgjørende i nærmest all
industriell programvareutviklin
Likevel finnes nesten ingen
kompetanse om dette hos
nyutdannete kandidater fra
universitet/høyskole
10
Konfigurasjon

Konfigurasjon – samling av alle
komponentene til et system hvor
hver komponent er representert
med nøyaktig én versjon som er
valgt i hht et bestemt kriterium,



f. eks. siste versjon, plattform
spesiell funksjonalitet
-> illustrasjon neste foiler ->
11
Eksempel – siste versjon,
plattform
12
Eksempel – spesiell funksjonalitet
- vaktbyttesystem
13
Konfigurasjonsstyring for
mange typer systemer

Programvare




Web-applikasjoner
Maskinvare
Ingeniørprodukter
Bøker
14
Produkter


Konfigurasjonsstyring kan omfatte alle typer
systemprodukter
Spesifikasjoner:


Design-dokumenter







UML klassediagrammer
Databaseskjema
Skjermbilder
Programmer


Tekstlige kravspesifikasjoner, Use Case diagrammer
etc.
Javakode
Kjøreoppsett/Scripts
Lagrede prosedyrer i databaser
Test-data
Brukermanualer
15
Versjoner og konfigurasjoner


En komponent kan foreligge i flere
versjoner.
Et fullstendig sett med komponenter i
bestemte versjoner utgjør en
konfigurasjon.
16
Versjoner/varianter/releaser av
systemer





Versjon – en instans av et system som er
funksjonelt forskjellig fra andre systeminstanser
Variant – en instans av et system som er
funksjonelt identisk, men forskjellig fra andre
system-instanser mht feil, ytelse etc.
Release – en instans av et system som
distribueres til brukere utenom utviklingsteamet
Alle disse instansene utgjør en konfigurasjon
17
Release-administrasjon


En release er en versjon som distribueres til kunder
En release-administrator har ansvar for å




En release er mer enn eksekverbar kode






bestemme når en release er klar
Administrere produksjonen av releasen med
distribusjonsmedia
Dokumentere hvordan releasen kan framstilles
Konfigurasjonsfiler
Datafiler
Intallasjonsprogram
Dokumentasjon i bok og elektronisk
Pakkemateriale og tilhørende reklame
Du kan ikke forutsette at forrige versjon er installert
Release-beslutninger



En ny release er kostbart (særlig ved
massedistribusjon)
Balanse mellom hyppige releaser med lite nytt og få
releaser med mye nytt
Faktorer som innvirker:




Systemets tekniske kvalitet (Feilrettingsrelease vs. Patch
over www)
Konkurransesituasjonen.
Markedsførings – krav.
Endringsforslag fra kunder.
Å lage en ny release

Det er å lage en komplett samling av filer og
dokumentasjonen





Både programkode og datafiler
Konfigurasjonsbeskrivelser for forskjellige miljø
Elektroniske kopier av dokumentasjonen
Skript for installasjonsprogrammet
Når alt er klart – lage master-disk


CD-Rom 640MByte
Distribusjon over internett.
Release-dokumentasjon



Dokumenterer hvordan releasen kan lages
Spesielt viktig for systemer med lang levetid
Registrere



Versjon av kildekodekomponentene
Versjon av operativsystem, biblioteker,
kompilatorer
Ta vare på kopier av kildekode og
eksekverbar kode, med alle tilhørende filer
Version/release-struktur
22
Versjon/release-håndtering




Definer notasjon for identifisering av
systemversjoner
Definer kriteriene for når en ny versjon
skal genereres (ikke trivielt)
Sjekk at rutiner og verktøy for
versjonshåndtering anvendes som
planlagt
Planlegg og distribuer nye systemreleaser
23
Release-problemer

Kunder ønsker ikke alltid en ny
release av et system


Kan være fornøyd med eksisterende
versjon og ønsker ikke ny
funksjonalitet (f.eks. MS Word)
Ikke anta at kundene har installert
alle tidligere releaser. Alle filer som
kreves for en release, må genereres
på nytt når releasen skal installeres
24
Håndtering av
komponenter/dokumenter

Flere tusen dokumenter kan
genereres i store program-systemer


Må kunne identifiseres
(navnekonvensjoner),
V1.0, V2.0, V3.0 for releaser, etc.


Potensielt lang levetid
Standardisering påkrevet
25
Standarder for
konfigurasjonsstyring




Konfigurasjonsstyring bør baseres på en
mengde standarder i en organisasjon
Standardene bør definere hvordan komponenter
identifiseres, hvordan endringer kontrolleres og
hvordan nye versjoner håndteres
Det finnes internasjonale standarder som kan
brukes som utgangspunkt (IEEE, ISO etc.), men
er gjerne basert på fossefallsmodellen.
Nye standarder trengs for evolusjonær,
inkrementell utvikling
26
Databasen
Konfigurasjons-databasen er sentral!
Inneholder kildekomponenter i ulike versjoner
Applikasjonskonfigurasjoner: Sammenstilling av versjoner av
kildekomponenter
Endringspakker: Sammenstilling av endringer som skal
anvendes som en enhet
Inneholder avhengigheter mellom objekter
27
Konfigurasjonsdatabase


Hjelpemiddel ved konsekvensanalyse
Bør kunne svare på:









Hvilke kunder har kjøpt versjon 3.11 b2
Hva kreves av maskinvare og operativsystem for å kjøre
versjon 3.11 b2
Hvor mange versjoner er laget og når
Hvilke versjoner vil endres ved endring i en bestemt
komponent
Hvor mange endringsønsker ligger i kø for versjon 3.11 b2
Hvor mange rapporterte feil finnes det i versjon 3.11 b2
Hva ble endret for å rette feilen som blokkerte rente-feltet
Konfigurasjonsdatabasen bør være integrert med
systemet for versjonsadministrasjon
System for versjonsadministrasjon kan


referere til filer
inneholder filer.
Databasen 2

Databasen bør kunne gi svar på:





Hvem arbeider med/er ansvarlig for en
bestemt systemversjon?
Hvilken plattform kreves for en bestemt
versjon?
Hvilke versjoner påvirkes av en endring til
komponent X?
Hvor mange feil er rapportert i versjon U?
Hvis mulig, bør databasen være knyttet
mot selve programvaren som utvikles
29
Endringshåndtering

Programvaresystemer er
kontinuerlig gjenstand for krav om
endringer fra




Brukere
Utviklere
Markedet
Myndigheter
30
Systembygging


Innebærer kompilering og lenking
Dette må du sikre deg:







At alle komponenter er med i byggeinstruksjonen
At riktig versjon av hver komponent blir brukt
At alle nødvendige datafiler er til stede
Blir datafilene tilgjengelige med samme navn/plassering på
systemet du bygger for
Er korrekt versjon av kompilator og andre verktøy til stede?
CM-verktøy sikrer korrekt skript til
systembyggeprosessen.
Systembyggeskript styrer systembyggesystemet.



Viser hvordan filer avhenger av hverandre.
Rekompilering bare hvis nødvendig
Hva med flere versjoner av kildefiler?
Systembygging
System
builder
Build
script
Version
management
system
Source code
component
versions
Compilers
Linker
Object code
components
Executable
system
konfigurasjonsadministrasjon og
CASE

Konfigurasjonsadministrasjon:



Store datamengder og store krav
En feil er nok til at det ikke virker
Mange CASE-verktøy i bruk



1. Generasjon: Revisjonskontroll og Make
2. Generasjon delvis integrert CM
3. Generasjon full integrert CM





Planlegging
Endringsadministrasjon
Versjonsadministrasjon
Systembygging
3. Generasjonsverktøy er komplekst og dyrt
Støtte for systembygging

Kompilering og lenking av større systemer involverer
hundrevis av filer og kan ta mange timer




En feil er nok til å vrake prosessen
Systembyggingsverktøy automatiserer prosessen
Stand alone: Make eller Integrert med CASE
Består av




Avhengighetsspesifikasjonsspråk og interpreter
Verktøyvalgsstøtte
Distribuert kompilering
Håndtering av deriverte objekter
Komponenter som avhenger
av hverandre
comp
scan.o
syn.o
sem.o
cgen.o
scan.c
syn.c
sem.c
cgen.c
defs.h
Hovedpunkter




Konfigurasjonsadministrasjon er administrasjon av
systemendringer
I store prosjekter bør vi lage en plan for å sette navn
på dokumenter
CM-teamet bør støtte seg på en
konfigurasjonsdatabase over systemendringer og
endringsønsker
Planlegg en versjonsidentifiseringsmetode bygd på
versjonsnummer, attributter eller endringer de
implementerer
Endringer



Hvordan ha oversikt over endringsstatus?
Finnes verktøy som holder rede på status og
sikrer at de riktige forespørslene er sendt til de
riktige personene til riktig tid, ofte integrert med
e-post
Logging/arkivering



Hva er endret på et gitt dokument eller kodekomponent?
Hvorfor, når og av hvem ble endringen utført?
Hvis spesielle konvensjoner for kommentering i kode
følges, kan slik info ekstraheres automatisk (f.eks.
JavaDoc, se http://java.sun.com/j2se/javadoc/ )
37
Verktøy



Verktøy for versjonskontroll - CVS,
Visula Source safe
Systembygging – hvordan
gjenoppbygge systemer etter
endringer?
Verktøy for systembygging - Make
38
Verktøy for versjonskontroll







Identifisering av versjoner og releaser
o Verktøysystemene genererer
automatisk en ny
identifikator når en ny versjon legges inn
i systemet
Endringshistorie
o Lagrer motivet for hver ny versjon
Lagringseffektivitet
o Forskjellen mellom versjoner lagres
istedenfor all kode for alle versjoner
39
Lagring av deltaer
40
CVS – Concurrent Versions
System




CVSbygger på RCS Revision Control
System.
RCSbygger igjen på erfaringer fra
SCCS
Source Code Control System SCCS
følger med standard Unix og ble brukt
mye før i tiden
CVS ligger på cube
41
Sette shellkommandoen
42
Bruk av CVS
Framgangsmåte for å lage ny versjon:
1. cvs checkout
 Kopierer endringer du har gjort inn i
CVS databasen
2. cvs diff
Viser arbeidet du har gjort siden sist du
la innenendring
3. cvs log Viser loggmeldinger
man cvs for info
43
Ressurser

http://www.loria.fr/~molli/cvs-index.html
44
Generasjoner av
konfigurasjonsstyringsverktøy

1. generasjon:


2. generasjon: Web-baserte overbygninger til
CVS



SCCS, RCS, CVS, Make
DSEE (forløper til ClearCase), Microsoft® Visual
SourceSafe™
(http://msdn.microsoft.com/ssafe/default.asp )
PVCS (http://www.pvcs.synergex.com )
3. generasjon: ClearCase
http://www.rational.com/products/clearcase/
45
46
47
48
49
50