INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1
Temaer i dagens forelesning Versjonshåndtering Systembygging Endringshåndtering Release håndtering Eksempel Git INF1050 Systemutvikling ->Konfigurasjonsstyring 2
Konfigurasjonsstyring Konfigurasjonsstyring handler om prosesser og verktøy for å håndtere endringer i programvaresystemer Hvorfor konfigurasjonsstyring Programvaresystemer er i konstant endring både under utvikling og bruk Lett å miste oversikten over hvilke endringer og versjoner av komponenter som har blitt tatt med i hver system versjon Viktig å ha kontroll på endringer gjort av ulike utviklere INF1050 Systemutvikling ->Konfigurasjonsstyring 3
Konfigurasjonsstyring - hovedaktiviteter Versjonshåndtering Systembygging Endringshåndtering Release management Fra fig. 25.1 i lærebok INF1050 Systemutvikling ->Konfigurasjonsstyring 4
Smidig utvikling Systemer og komponenter endres opptil flere ganger daglig umulig uten konfigurasjonsstyringsverktøy Endelig versjon av komponentene holdes i en felles repository og utviklere kopierer disse inn til sitt egen arbeidsområde (lokalt) Gjør endringer i kode og bygger et nytt system lokalt for testing. Returnerer de endrede komponentene til felles repository Bruk av Git svært utbredt INF1050 Systemutvikling ->Konfigurasjonsstyring 5
Flere versjoner i store systemer Fra fig. 25.2 i lærebok INF1050 Systemutvikling ->Konfigurasjonsstyring 6
Begreper - terminologi Begrep Baseline Forklaring Spesiell, kontrollert konfigurasjon av komponenter som fungerer som plattform for videreutvikling av systemet Codeline Sett av versjoner av en komponent og andre konfigurasjonselementer som denne komponenten er avhengig av Branching Konfigurasjon Konfigurasjonselement Mainline Oppretting av en ny codeline fra en versjon i en eksisterende codeline En samling av alle komponentene til et system hvor hver komponent er representert med nøyaktig en versjon etter bestemte kriterier, f.eks. siste versjon, plattform, spesiell funksjonalitet, etc. Alt som er assosiert med et systemutviklingsprosjekt (design, kode, test data, dokumentasjon etc.) og som er under konfigurasjonskontroll. Alle elementer har unike navn (eller id) En sekvens av baselines som representerer ulike versjoner av et system INF1050 Systemutvikling ->Konfigurasjonsstyring 7
Begreper terminologi - 2 Begrep Fletting (Merging) Release Repository Systembygging (System building) Versjon Arbeidsområde (Workspace) Forklaring Oppretting av en ny versjon av en programvarekomponent ved å flette separate versjoner i ulike codelines En versjon av systemet som er released til kunden (eller andre) for bruk Database av ulike versjoner av programvarekomponenter og (meta) informasjon om alle endringer til disse komponentene Oppretting av et kjørbart system ved å kompilere og linke de riktige versjonene av komponentene og bibliotekene som utgjør systemet. En instans av et konfigurasjonselement som er forskjellig fra andre instanser av samme element. Versjoner har alltid en unik ID Privat arbeidsområde der programvare kan endres uten at det berører andre utviklere som jobber med samme programvare INF1050 Systemutvikling ->Konfigurasjonsstyring 8
Versjonshåndtering Versjonshåndtering holder rede på ulike versjoner av programvarekomponenter og de systemer der disse komponentene brukes Sørger for at endringer gjort av ulike utviklere ikke ødelegger for hverandre Versjonshåndtering kan bli sett på som styring av codelines and baselines INF1050 Systemutvikling ->Konfigurasjonsstyring 9
Codelines and Baselines Fra fig. 25.4 Sommerville INF1050 Systemutvikling ->Konfigurasjonsstyring 10
To hovedsystemer av versjonshåndtering Sentraliserte systemer - en singel master repository som vedlikeholder alle versjoner av programvarekomponentene som har blitt utviklet. Subversion er et mye brukt eksempel. Distribuerte systemer, der flere versjoner av repository finnes samtidig. Git er et mye brukt eksempel INF1050 Systemutvikling ->Konfigurasjonsstyring 11
Sentralisert versjonskontroll Utviklere sjekker ut komponenter (filer) fra felles repository inn på deres private arbeidsområde og jobber på denne kopien Når endringene er utført, sjekker de komponentene (filene) tilbake til repository Når flere jobber på samme komponent samtidig, og sjekker ut en komponent som allerede er sjekket ut av en annen, vil det bli gitt en advarsel om at komponenten allerede er sjekket ut INF1050 Systemutvikling ->Konfigurasjonsstyring 12
Sjekk inn /sjekk ut Fra fig. 25.5 Sommerville INF1050 Systemutvikling ->Konfigurasjonsstyring 13
Distribuert versjonshåndtering En master repository finnes på en server Isteden for å sjekke ut, laster utviklerne ned en klone av repository på deres private arbeidsområde Endringene blir committed og deres private repositiory blir oppdatert. Endringene vil så pushes til master repository. Fordeler Backup ( master kan bli lastet opp fra lokale kopier) Jobbe off-line (uten nett) Utviklere kan kompilere og teste hele systemet på deres lokale maskin etter at endringer er gjort Sentralt i open source utvikling (open source manager avgjør om han vil pulle endringene som hver enkelt utvikler har pushet ) INF1050 Systemutvikling ->Konfigurasjonsstyring IKT 14
Eksempel fra DHIS2 (HISP prosjektet) clone repository INF1050 Systemutvikling ->Konfigurasjonsstyring 15
Branching and merging Fra fig. 25.8 Sommerville INF1050 Systemutvikling ->Konfigurasjonsstyring 16
Eksempler fra DHIS2 (HISP prosjektet) Branch INF1050 Systemutvikling ->Konfigurasjonsstyring 17
Systembygging Under systembygging skapes et komplett kjørbart system gjennom kompilering og linking av systemkomponenter, eksterne bibliotek, konfigurasjonsfiler etc. Verktøy for systembygging og versjonshåndtering må kommunisere fordi byggeprosessen involverer å sjekke ut komponentversjoner fra repository som styres av versjonshåndteringssystemet Konfigurasjonsbeskrivelsen som er brukt til å identifisere en baseline er også brukt INF1050 Systemutvikling ->Konfigurasjonsstyring 18
Utvikling og bygging Fra fig. 25.11 Sommerville INF1050 Systemutvikling ->Konfigurasjonsstyring 19
Smidig utvikling og bygging Sjekk ut mainline systemet fra versjonshåndteringsystemet til lokalt arbeidsområde. Bygg systemet og kjør automatiserte tester. Hvis det er feil, gjør endringer og gjenta prosessen Når systemet er feilfritt, sjekk inn til byggesystemet, men ikke commit som ny baseline. Bygg systemet på build server og kjør testene i tilfelle andre har endret siden du sjekket inn. If OK, commit endringene som ny baseline INF1050 Systemutvikling ->Konfigurasjonsstyring 20
Kontinuerlig integrasjon Fra fig. 25.12 Sommerville INF1050 Systemutvikling ->Konfigurasjonsstyring 21
Endringshåndtering Organisatoriske endringer og krav endres, og feil må rettes Endringshåndtering skal sørge for at systemutviklingen følger en gjennomtenkt endringshåndteringsprosess I prosessen analyseres kost/nytte av alle foreslåtte endringer, og hvilke komponenter i systemet som blir berørt av endringene De viktigste og mest kostnadseffektive endringene prioriteres INF1050 Systemutvikling ->Konfigurasjonsstyring 22
Viktige faktorer i endringsanalyse Konsekvenser av å ikke gjøre endringen Fordeler av endringen Antall brukere som blir berørt av endringen Kostnaden ved å implementere endringen Release syklus INF1050 Systemutvikling ->Konfigurasjonsstyring 23
Endringshåndtering og smidige metoder Ofte er kunden direkte involvert i endringshåndteringen Ved forslag til endringer i krav, vil kunden og teamet vurdere konsekvensen av endringen og avgjøre om endringen skal utføres i neste increment. Forbedring av software ( refactoring ) blir bestemt av utviklerne, og blir sett på som en nødvendig del av utviklingsprosessen. INF1050 Systemutvikling ->Konfigurasjonsstyring 24
Release håndtering (release management) En system release er en versjon av systemet som distribueres til kundene. Hyllevare To typer: 1) Major release med betydelig ny funksjonalitet og 2) minor release med bug fixing og problemer som er rapportert av brukere etc. Kundetilpassede systemer Kan være ulike versjoner tilpasset hver kunde INF1050 Systemutvikling ->Konfigurasjonsstyring 25
Faktorer som påvirker release planlegging Konkurranse og markedskrav Endringer i plattform må release ny versjon Teknisk kvalitet på systemet (kritiske feil etc.) Ved for hyppige releaser og kundene må betale, velger mange kunder å ikke kjøpe ny release Når releaser er for sjeldne, kan kundene velge alternative løsninger og markedsandeler kan tapes. INF1050 Systemutvikling ->Konfigurasjonsstyring 26
Eksempler fra DHIS2 (HISP prosjektet) teams INF1050 Systemutvikling ->Konfigurasjonsstyring 27
Eksempler fra DHIS2 (HISP prosjektet) repositories INF1050 Systemutvikling ->Konfigurasjonsstyring 28
Eksempler fra DHIS2 (HISP prosjektet) dokumenter INF1050 Systemutvikling ->Konfigurasjonsstyring 29
Eksempler fra DHIS2 (HISP prosjektet) Issue INF1050 Systemutvikling ->Konfigurasjonsstyring 30