Konfigurasjonsstyring INF1050: Gjennomgang, uke 11
Kompetansemål Konfigurasjonsstyring Hva og hvorfor? I en smidig sammenheng Endringshåndtering Versjonhåndtering Systembygging Release -håndtering
Del I: Konfigurasjonsstyring Grunnleggende: Hva? Hvorfor? Ulike aktiviteter
Konfigurasjonsstyring: Hva? Output fra en systemutviklingsprosess kan deles i tre kategorier
Konfigurasjonsstyring: Hva? Konfigurasjon Samling av alle komponenter som inngår i et system Hver komponent representeres med en versjon Konfigurasjonsstyring Software Configuration Management (SCM) Aktiviteter, prosesser og verktøy Håndtere endringer i programvaresystemer gjennom hele utviklingsprosessen Spore endringer som gjøres Systematisk kontroll over utviklingsprosessen og det som utvikles
Konfigurasjonsstyring: Hvorfor? Programvaresystemer er i konstant endring Systemer og kode kan bli veldig komplekse Lett å miste oversikten over endringer / versjoner av komponenter Varierer fra versjon til versjon Ønsker å ha kontroll over endringer Hva ble endret? Hvem har endret hva? Bringer kontroll over systemutviklingsprosessen! Forenkler teamarbeid / koordinering Unngå endringsrelaterte problemer
Konfigurasjonsstyring: Hvorfor? Hvordan sikrer vi kvalitet? Konfigurasjonsstyring spiller en sentral rolle! Achieving Software Quality (Pressman, 1997)
Konfigurasjonsstyring: Aktiviteter Figur 25.1 (Sommerville, 2011)
Konfigurasjonsstyring: Aktiviteter Endringshåndtering (Change Management) Oversikt over endringer fra kunde / utviklere >> Change Request Form Kostnadsestimering og virkning (fordeler, ulemper) av foreslåtte endringer Slutninger om hvorvidt foreslåtte endringer skal implementeres Versjonhåndtering (Version Management) Oversikt over ulike versjoner av system og systemkomponenter Sørge for at endringer fra ulike utviklere ikke kolliderer med hverandre >> Git
Konfigurasjonsstyring: Aktiviteter Systembygging (System Building) Setter sammen systemkomponentene Programvare, data, biblioteker Kompilering og integrering Skaper et fullstendig (kjørbart) system Release-håndtering (Release Management) Forberede / ferdigstille programvare for ekstern utgivelse (release) Oversikt over ulike versjoner av systemet som har blitt gitt til kunden
Forholdet til smidig utvikling Systemer / komponenter endres flere ganger daglig Hyppig bygging og testing av programvare Selvstyrte team med mye frihet Kunden er i stor grad involvert i endringshåndtering Pågående kommunikasjon om hva som har blitt gjort / skal gjøres Håndtering av endringer er tilnærmet umulig uten konfigurasjonsstyring
Gjennomgang av ukesoppgaver Ukens tema: Testing av programvare
Oppgave 1 Foreslå 3-5 mulige problemer som kan oppstå hvis et softwareselskap ikke bruker effektive styringsverktøy og prosesser (policies).
Oppgave 1: Løsningsforslag Mulige problemer hvis ikke effektive styringsverktøy og prosesser brukes. Begrenset oversikt over Systemets tilstand Utviklingsprosessen Mangel på oversikt over endringer Kildekode Krav Svekket dokumentasjon Tilnærmet umulig å gjenskape eldre (tidligere) versjoner av systemet
Oppgave 2 Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline Baseline Versjon Release Branching
Oppgave 2: Løsningsforslag Codeline Sekvens av versjoner av en programvarekomponent (kildekode) Senere versjoner i sekvensen er utledet av tidligere versjoner Figur 25.6 (Sommerville, 2011)
Oppgave 2: Løsningsforslag Baseline Beskrivelse av en samling av komponenter som utgjør et system Spesifiserer codeline-versjonene som er inkludert i systemet Definerer øvrige komponenter (og versjoner) inkludert i systemet Biblioteker Konfigurasjonsfiler Øvrig dokumentasjon Kan gjenskape komplette og spesifikke versjoner av et system Viktig funksjonalitet Nødvendig dersom kunden rapporterer om feil
Oppgave 2: Løsningsforslag Baseline Figur 25.6 (Sommerville, 2011)
Oppgave 2: Løsningsforslag Versjon Et tilfelle av en konfigurasjon Skiller seg fra andre tilfeller av samme konfigurasjon Har en unik identifikator Konfigurasjonsnavn + versjonsnummer Release Versjon av et system overført til kunden Klar for bruk
Oppgave 2: Løsningsforslag Branching Forgrening av codelines Opprettelse av nye codelines fra eksisterende codelines Kan ha flere uavhengige sekvenser av versjoner Dette er et vanlig scenario Utviklere jobber med ulike versjoner av kildekoden Til slutt blir det nødvendig å flette sammen (merge) codeline-grenene Lager ny komponentversjon som inneholder alle endringer
Oppgave 2: Løsningsforslag Branching Utviklere jobber med ulike versjoner, uavhengig av hverandre V2.1.2 Her utvikles funksjonalitet A V2.2 Her utvikles funksjonalitet B V2.4 En flettet versjon Figur 25.9 (Sommerville, 2011)
Oppgave 3 Hva er et repository? Forklar forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering.
Oppgave 3: Løsningsforslag Bakgrunn Sentrale spørsmål i tidlig versjonhåndtering Hvordan kan vi løse lagringsproblemet? / Hvordan kan vi spare plass? Løsning Ikke nødvendig å lagre alle tidligere versjoner av et system Kan bruke en liste med forskjeller (delta) mellom tidligere og nåværende versjoner Figur 25.7 (Sommerville, 2011)
Oppgave 3: Løsningsforslag Hva er et repository? Lagringsplass Kildekode / Programvarekomponenter Verktøy for versjonhåndtering Oversikt over endringer som utføres Kan være Sentraliserte Distribuerte
Oppgave 3: Løsningsforslag Forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Sentraliserte systemer Det finnes én kopi av systemet Master repository Ligger på en server Utviklere sjekker ut komponenter fra master repository, over på eget arbeidsområde Etter at endringer er utført sjekkes komponentene inn igjen gjennom commit Commit Registrere endringen i det sentrale systemet Andre utviklere kan nå se denne endringen Ikke nødvendig å lagre mange kopier av filer på privat arbeidsområde
Oppgave 3: Løsningsforslag Forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Eksempel: Sjekk inn / ut Fra figur 25.8 (Sommerville, 2011)
Oppgave 3: Løsningsforslag Forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Distribuerte systemer Master repository ligger på en server Utviklere laster ned (pull) en klone til privat arbeidsområde Har nå tilgang til hele historien på egen maskin Data + metadata Endringer blir oppdatert privat gjennom commit Endringer oppdateres globalt ved push til master repository
Oppgave 3: Løsningsforslag Forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Fordeler med distribuerte systemer Aktiviteter utenom push og pull går veldig raskt Trenger kun å aksessere lokalt minne, ikke en annen server Kan jobbe offline Uten nett Kan kompilere og teste systemet isolert Ferdige endringer kan deretter pushes Utfordringer med distribuerte systemer Vanskelig å komprimere store, binære filer Kan ta lang tid å laste ned et prosjekt med en lang, omfattende historie (changeset)
Oppgave 4 Hvilke problemer kan oppstå når to utviklere samtidig gjør endringer i tre programvarekomponenter?
Oppgave 4: Løsningsforslag Hvilke problemer kan oppstå når to utviklere samtidig gjør endringer i tre programvarekomponenter? En utvikler endrer en funksjon som en annen utvikler er avhengig av Oppstå feil Endringer som ikke er kompatible
Oppgave 5 Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke.
Oppgave 3(b): Løsningsforslag Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke. Sentral aktivitet Inngår i endringshåndtering Ønskede endringer presenteres gjennom et Change Request Form Avgjør om foreslåtte endringer er gyldige / gjennomførbare Husk: Ikke alle endringer er nødvendige å gjennomføre! Analyseres i lys av kostnader og gevinst Prioriterer de viktigste og mest kostnadseffektive endringene
Oppgave 3(b): Løsningsforslag Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke. Faktorer i en endringsanalyse Konsekvenser Hva skjer dersom foreslåtte endringer ikke følges opp / utføres? Fordeler / gevinst av foreslåtte endringer Brukere Hvem, og hvor mange, berøres av de foreslåtte endringene? Kostnader knyttet til implementasjon av endringene
Oppgave 3(b): Løsningsforslag Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke. Sporbarhet Sammenheng mellom krav, design, tester Brukes ofte for å definere omfang av å implementere endringer Avhengigheter Sammenheng mellom komponenter, variabler, logikk, moduler Brukes for å avdekke konsekvenser av å implementere endringer Erfaring Omfang og konsekvenser av endringer påvirkes av erfaring
En siste oppfordring Lær å benytte dere av ulike verktøy for versjonhåndtering Eksempler: Git Distribuert Subversion Sentralisert Dette er svært nyttig når man er flere som jobber på/med samme kode!
Spørsmål? Ta kontakt Yulai Fjeld ydfjeld @ uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene
Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.
Takk for meg Neste uke : IT-kontrakter