Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Konfigurasjonsstyring og versjonshåndtering Kirsten Ribu.

Liknende presentasjoner


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

1 Konfigurasjonsstyring og versjonshåndtering Kirsten Ribu

2 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 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 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 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 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 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 12 Eksempel – siste versjon, plattform

13 13 Eksempel – spesiell funksjonalitet - vaktbyttesystem

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

15 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 16 Versjoner og konfigurasjoner En komponent kan foreligge i flere versjoner. Et fullstendig sett med komponenter i bestemte versjoner utgjør en konfigurasjon.

17 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 22 Version/release-struktur

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

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 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 38 Verktøy Verktøy for versjonskontroll - CVS, Visula Source safe Systembygging – hvordan gjenoppbygge systemer etter endringer? Verktøy for systembygging - Make

39 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 40 Lagring av deltaer

41 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 42 Sette shellkommandoen

43 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 44 Ressurser

45 45 Generasjoner av konfigurasjonsstyringsverktøy 1. generasjon:  SCCS, RCS, CVS, Make 2. generasjon: Web-baserte overbygninger til CVS  DSEE (forløper til ClearCase), Microsoft® Visual SourceSafe™ (http://msdn.microsoft.com/ssafe/default.asp )  PVCS (http://www.pvcs.synergex.com ) 3. generasjon: ClearCase

46 46

47 47

48 48

49 49

50 50


Laste ned ppt "Konfigurasjonsstyring og versjonshåndtering Kirsten Ribu."

Liknende presentasjoner


Annonser fra Google