Konfigurasjonsstyring og versjonshåndtering

Presentasjon om: "Konfigurasjonsstyring og versjonshåndtering"— Utskrift av presentasjonen:

1 Konfigurasjonsstyring og versjonshåndtering
Kirsten Ribu

2 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.

3 Systemers livssyklus

4 Introduksjon Dette skal administreres:
Endringsforslag, feilrettinger,Tilpasning til maskinvare og operativsystemer Mange versjoner kan være i bruk og utvikling samtidig Hvordan endringer er implementert Konfigurasjonsstyringsprosedyrer 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

5 Introduksjon Konfigurasjonsstyring er ofte kombinert med kvalitetsstyring 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 Hvorfor ulike konfigurasjoner? Plattform Kundespesifikke funksjoner Markedshensyn Konfigurasjonsansvarlig Konfigurasjonsstyringsprosessen Standarder finnes: IEEE konfigurasjonsstyringsplaner Konfigurasjonsstyringshåndbok

6 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

7 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 team-aktivitet

8 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

9 Introduksjon CM når fossefallsmodellen ikke blir anvendt dvs. inkrementell utvikling 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. Fordeler ved hyppig bygging 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

10 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

11 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 ->

12 Eksempel – siste versjon, plattform

13 Eksempel – spesiell funksjonalitet - vaktbyttesystem

14 Konfigurasjonsstyring for mange typer systemer
Programvare Web-applikasjoner Maskinvare Ingeniørprodukter Bøker

15 Produkter Konfigurasjonsstyring kan omfatte alle typer systemprodukter
Spesifikasjoner: Tekstlige kravspesifikasjoner, Use Case diagrammer etc. Design-dokumenter UML klassediagrammer Databaseskjema Skjermbilder Programmer Javakode Kjøreoppsett/Scripts Lagrede prosedyrer i databaser Test-data Brukermanualer

16 Versjoner og konfigurasjoner
En komponent kan foreligge i flere versjoner. Et fullstendig sett med komponenter i bestemte versjoner utgjør en konfigurasjon.

17 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

18 Release-administrasjon
En release er en versjon som distribueres til kunder En release-administrator har ansvar for å bestemme når en release er klar Administrere produksjonen av releasen med distribusjonsmedia Dokumentere hvordan releasen kan framstilles En release er mer enn eksekverbar kode Konfigurasjonsfiler Datafiler Intallasjonsprogram Dokumentasjon i bok og elektronisk Pakkemateriale og tilhørende reklame Du kan ikke forutsette at forrige versjon er installert

19 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.

20 Å 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.

21 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

22 Version/release-struktur

23 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 system-releaser

24 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

25 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

26 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

27 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

28 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.

29 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

30 Endringshåndtering Programvaresystemer er kontinuerlig gjenstand for krav om endringer fra Brukere Utviklere Markedet Myndigheter

31 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?

32 Systembygging

33 konfigurasjonsadministrasjon og CASE
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

34 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

35 Komponenter som avhenger av hverandre

36 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

37 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 kode-komponent? 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 )

38 Verktøy Verktøy for versjonskontroll - CVS, Visula Source safe
Systembygging – hvordan gjenoppbygge systemer etter endringer? Verktøy for systembygging - Make

39 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

40 Lagring av deltaer

41 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

42 Sette shellkommandoen

43 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

44 Ressurser

45 Generasjoner av konfigurasjonsstyringsverktøy
SCCS, RCS, CVS, Make 2. generasjon: Web-baserte overbygninger til CVS DSEE (forløper til ClearCase), Microsoft® Visual SourceSafe™ ( ) PVCS ( ) 3. generasjon: ClearCase

46

47

48

49

50