Configuration Management p¥ fem minuter

download Configuration Management p¥ fem minuter

of 16

  • date post

    04-Apr-2016
  • Category

    Documents

  • view

    220
  • download

    1

Embed Size (px)

description

CM, Configuration Management, är konsten att hålla reda på versioner, komponenter och kompletteringar för att därigenom undvika krångel, problem och misstag. Denna broschyr ger en snabb sammanfattning av området.

Transcript of Configuration Management p¥ fem minuter

  • p fem minuter

    CONFIGURATION MANAGEMENT

  • 2HAR NI ORDNING OCH REDA?

    Hur ser det ut nr ni utvecklar produkter eller kod p ert fretag?

    Hnder det att fel och buggar uppstr frn de dda (som i exemplet hr ovan).

    Har ni utvecklat rutiner fr att rtta ett rapporterat fel i flera samtidiga versioner av produkten?

    ARKIV

    EFTERMIDDAG ACME INC.

    Problem, killar! Kunden ringde. I senaste versionen har betalnings-buggen dykt upp igen.

    Du skojar den fixade jag fr tv mnader sedan!

    Jag vet. Men de fr exakt samma krasch nr de kopplar upp till PayPal.

    Fattar inte Lisa fick den ju fr live-testning och skeppade den

    Jaja, du har vl missat att lgga in den i den nya releasen.

    Hall, det mste vara ert jobb att stta ihop releaserna!

  • 3ARKIV

    Och hur ska jag kunna veta vad du har gjort och inte gjort?

    Hr upp vi behver f ordning i den hr rran. Uppenbarligen vet inte hgra han-den vad den vnstra gr

    r arbetet med att f ut en ny version komplicerat, tidskrvande och ett hinder fr nya uppdateringar?

    Saknar ni ett komplett och verskdligt arkiv av tidigare versioner?

    D kanske ni behver vssa fretagets kompetens nr det gller CM, Con-figuration Management konsten att hlla reda p versioner, komponenter och kompletteringar. Detta gller alla organisationer som bedriver ngot slags avancerad produktutveckling, oavsett om det handlar om mjuk- eller hrdvara.

  • 4CONFIGURATION MANAGEMENT 1.0

    CM gr ut p att skapa ordning och sprbarhet dr det behvs. De uppen-bara frdelarna handlar mycket om att undvika krngel, problem och misstag, till exempel genom att

    skapa tydliga regler fr versionsbenmning, dokumentation, lagring av filer etc.

    effektivare kunna spra vad en leverans innehller enklare kunna se vilka buggar och problem som hr ihop med olika ver-sioner av produkterna.

    I stora organisationer som utvecklar omfattande system r CM helt nd-vndigt eftersom hundratals programmerare kan vara inkopplade p sam-ma projekt. Hr r det ltt att motivera medarbetarna eftersom alla inser att formaliserat CM-arbete r skillnaden mellan ordning och kaos.

    I mindre fretag kan det dremot finnas lite strre motstnd mot CM- arbete. Det kan helt enkelt knnas ondigt formellt i en organisation dr alla knner varandra och har verblick ver projekten. Fr att motivera medarbetarna gller det att framhlla de frdelar som CM-arbetet leder till och sluta tala om det som ett ndvndigt ont.

    Alla tillmpar vi CM p ngot stt idag. I sin allra enklaste form kan det se ut som i fljande exempel:

    Exempel 1: Det gemensamma textdokumentet

    Hans och Tage skriver en bok tillsammans dr de jobbar i ett ord-behandlingsprogram. Versionerna ligger i en mapp i molnet. Varje gng ngon av dem jobbar med filen gr han en ny kopia av ord-behandlingsfilen, lgger till dagens datum samt en signatur. Filernas namn blir

    2013-07-01_boken_hans.doc2013-07-02_boken_tage.doc2013-07-03_boken_hans.doc...

    Denna manuella form av versionshantering r ltt att frst men den har brister. Vad hnder t.ex. nr de tv frfattarna sparar en ny version p var sitt hll?

  • 5Exempel 2: Den kommersiella mjukvaran

    Fretaget Microapples viktigaste produkt r ett layoutprogram. S hr ser release-loggen ut:

    0.99 Beta (testversion)1.0 Frsta versionen1.0.1 Buggfix1.1 Uppdatering (buggfixar & funktioner) 1.5 Uppgradering2.0 Omfattande uppgradering2.0.1 Buggfix osv.

    Detta r klassisk versionsidentifiering fr mjukvara. Det r viktigt att se till att det finns ett s tydligt regelverk som mjligt fr numreringen.

    CUSTO

    MER

    REPOR

    TS

    BACKLOG

    2.0 ONLY

    BUGS

    1.5

    BETA

    RELEA

    SE

    2.0

    BETA

    CMDet r viktigt att den

    CM- ansvarige anlgger ett helikopterperspektiv och skaffar sig en ver-

    blick ver utvecklings -arbetet vad som

    skapas, ndras och arkiveras.

  • 6FRDELAR MED CM

    CM r s mycket mer n ett system fr att inte rra till det. Vl fungerande rutiner och verktyg ger en hel rad positiva effekter.

    Utvecklingsarbete blir snabbare.CM hjer tempot i utvecklingsarbetet p mnga olika stt. Frst och frmst mjliggr det att parallella utvecklingsteam kan arbeta i samma projekt p ett kontrollerat stt (se nedan). Dessutom frenklar det systemanalyser, felskning, testning, mtning samt uppfljning.

    Kontrollerat kaos mjliggrs.Ju bttre organisationen blir p CM, desto mer avancera-de projektmodeller kan den tillmpa, med t.ex. parallel-la, sjlvstndiga utvecklings-team, snabba iterationer och tt terkoppling frn mark-naden. CM skerstller t.ex. att buggar inte teruppstr frn de dda och att knda problem tgrdas vid rtt tidpunkt i produktionsfldet.

    Organisationen fr ett helhetsgrepp.Alla intressenter fr bttre verblick ver hur mjukva-ran utvecklas, vilka varianter som skapas samt vad som har ndrats mellan olika versioner. Sist men inte minst r det lttare att hitta bland ldre versioner nr ngot behver kollas upp eller terskapas.

    Produktstrukturering kar flexibiliteten. CM gr det enklare att dela upp och hantera mjukvaran i moduler ngot som ger mnga frdelar. Bl.a. kan man snabbare skapa nya produktvari-anter nr man utgr frn befintliga moduler. Man fr ven en effektivare mjukvaruutveckling nr arbetet delas upp p de olika modulerna.

    R.I.PBUG

  • 7CM-ANSVARIG EN ROLL I FRNDRINGBeroende p organisationens storlek kan rollen som CM-ansvarig ven benmnt Configuration Manager antingen utgra en deltidssyssla fr en person som ven gr ngot annat eller en heltidssyssla. Oavsett vilket mste den CM-ansvarige besitta en stor frstelse fr hela utvecklings-processen och ligga ett steg fre i arbetet. Dagens mngfald av utveck-lingsmodeller och arbetsstt gr att den CM-ansvarige mste vara anpass-ningsbar och frst hur olika team jobbar.

    Nr vattenfallsorienterade utvecklingsmodeller anvnds r CM-arbetet som mest intensivt tidigt och sent i projektfldet: frst intensiv planering i de tidiga projektfaserna och sedan uppfljning, indrivning av leveranser samt administration av ndringshanteringen i de senare faserna.

    Iterativa och inkrementella utvecklingsmodeller gr att komplexiteten i CM-arbetet kar dramatiskt; det r som om flera projekt lper samtidigt dr man jobbar med samma produkt. Det blir fler artefakter att hlla ord-ning p och dessa fr dessutom mer komplicerade livscykler ngot som stller strre krav p bde verktyg och processer.

    Agila modeller kar parallelliteten i arbetet nnu mer och lter dessut-om teamen sjlv bestmma hur de ska jobba. Den CM-ansvarige mste hr vara mycket lyhrd, ha stor frstelse fr teamens arbete och sjlv lta sig vgledas av de agila principerna. I mnga fall blir det naturligt att teamen sjlva tar hand om det rent operativa CM-arbetet. Den CM-ansvarige fr d en expert- och coachroll som fngar upp problem och ider och avgr vilka som ska implementeras.

    P nsta uppslag ska vi se nrmare p dessa utvecklingsmodeller.

  • 8CM I OLIKA MODELLER

    Vattenfallsorienterad utvecklingsmodell

    Ur ett CM-perspektiv r vattenfallsmodellen enkel: det r ett enda spr att hlla reda p, indelat i arbetsfaser. Baselines, statusrapporter och felrap-porter blir drfr relativt enkla att hantera. Det som dock kan komplicera bilden r att man ofta har mnga change requests att hantera.

    Iterativ utvecklingsmodell

    I CM-sammanhang kan en iterativ utvecklingsmodell beskrivas som flera samtidiga vattenfallsprojekt. Eftersom iterationerna r delvis parallella blir situationen naturligtvis mer komplex.

    Hr mste man hlla reda p vad som ingr i vilken iteration vara tydlig i sin rapportering ha en vloljad hantering av felrapporter (vilka fel ska rttas i vilken itera-tion?).

    Nr det gller change requests kan situationen faktiskt bli ngot enklare. Man har ju mjlighet att lgga in en ndring i en iteration som nnu inte r pbrjad och behver d inte ndra ngot som r under arbete.

    Management

    Customer

    Baseline Statusrapport Change request

    B

    B Release Beta releaseR

    RB B

    Management

    Customer

    B B B

    B B B

    B B B

    B B B R

    Team 1

    Team a

    Team b

    Team c

    Team 1

    Team 2 Team 3 Team 4

    Product owner

    Customer

    B R

    R

    R

    B B

    B

    B

    B

    B

    Team 2 Team 3 Team 4

    Team 1 Team 2 Team 3 Team 4

    Team 1 Team 2 Team 3 Team 4

    Team 1 Team 2 Team 3 Team 4

    B B B

    BBBB B B B

    Management

    Customer

    Baseline Statusrapport Change request

    B

    B Release Beta releaseR

    RB B

    Management

    Customer

    B B B

    B B B

    B B B

    B B B R

    Team 1

    Team a

    Team b

    Team c

    Team 1

    Team 2 Team 3 Team 4

    Product owner

    Customer

    B R

    R

    R

    B B

    B

    B

    B

    B

    Team 2 Team 3 Team 4

    Team 1 Team 2 Team 3 Team 4

    Team 1 Team 2 Team 3 Team 4

    Team 1 Team 2 Team 3 Team 4

    B B B

    BBBB B B B

  • 9Agil utvecklingsmodell

    Nr agila utvecklingsmodeller anvnds r komplexiteten nnu strre eftersom man fokuserar mer p ansvar i varje team, tta leveranser och en stndigt pgende testverksamhet. Individuella iterationer fr varje team pgr parallellt och inte ndvndigtvis med samma periodicitet.

    Kraven p statusinformation r hga bde uppt i organisationen och mellan teamen. Varje iteration eller uppgift blir hr en baseline. Det r viktigt att administrativa rutiner r lttviktiga och enkla att flja eftersom det r utvecklingsteamen som kommer att utfra det mesta av det arbetet.

    ndrade krav eller change requests r dremot ett naturligt inslag i en agil organisation och de agila modellerna har fungerande rutiner fr hur man hanterar dem. Dremot r det fortfarande mycket viktigt med sprbarhe