ClearCase. Versionshantering

Transkript

1 ClearCase ClearCase är ett verktyg särskilt utformat för att underlätta utveckling av mjukvara i projektgrupper. Det har en praktisk lösning på problem som versionshantering, gemensamma gränssnitt, kontroll över processutveckling, automatisering av viss informationsspridning och att arbeta i grupper spridda över större geografiska områden. Versionshantering I ett projekt arbetar man ofta med olika slags data, inte bara källkod. ClearCase håller reda på alla filer i en utvecklingsmiljö som delas mellan flera användare. Ett nyckelkoncept hos ClearCase är versionsträdet (se bild nedan) som organiserar och presenterar information i ett grafiskt, hierarkiskt format liknande ett filträd. Vanligtvis innehåller versionsträdet till en början bara en gren som representerar en linjär utveckling av en fils olika versioner. I versionsträdet kan användare lätt överblicka utvecklingens gång, skapa nya grenar och förena (merge) två grenar. Man kan börja på en ny gren för att t.ex. reorganisera kod eller experimentera. Antalet versioner och antalet grenar är inte begränsat och de olika versionerna och grenarna kan döpas. Att ha versionsträd för kataloger är bra för att kunna se förändringar såsom tillkomster och borttagningar av filer/underbibliotek, eller omorganiseringar mellan olika underbibliotek.

2 ClearCase stödjer versionshantering av textfiler, källkod, kataloger, bibliotek, kompilerare, binärer, databaser mm. Alla data sparas i databaser kallade versioned object bases (VOBar). En projektgrupp kan sedan strukturera upp sitt arbete genom att bestämma hur många VOBar de behöver samt vilka kataloger och filer dessa bör innehålla. En VOB är ett monterbart filsystem (se bild nedan) och kan därför flyttas mellan olika servrar. När en VOB är monterad och tillgänglig via ClearCase ser det ut och fungerar som ett vanligt filträd. Det innehåller kataloger, filer och länkar, men även information om alla elements olika versioner. När man ska arbeta med en fil är denna till en början endast läsbar. Genom att använda kommandot checkout får man en editerbar kopia av filen. När arbetet med filen är färdigt, resulterar kommandot checkin i att en ny version av filen läggs till i versionsträdet och den editerbara kopian av filen försvinner. Filen blir då åter endast läsbar och åtkomlig för alla användare. Både vid checkout och checkin kan man lägga till en kommentar om arbetet man gjort på filen för att lättare kunna överblicka förändringar som gjorts. Man kan välja mellan att göra en reserved eller unreserved checkout. En reserved checkout garanterar att användarens nya version kommer att vara nästa löv i versionsträdet. En unreserved checkout kan göras av flera användare samtidigt på samma fil och garanterar ingen rätten att skapa nästa version. Om flera användare gjort en unreserved checkout på samma fil kommer den som gör en checkin först att skapa den nya versionen. De andra användarna får använda kommandot merge parallel versions för att få med sina förändringar (resulterar i ännu en version). Andra kommandon som finns är: uncheckout, delete version, create/delete branch, list version history (kronologiskt) och compare versions. Vid utförandet av de flesta ClearCase-kommandon skapas ett event record där användbar information lagras. Där lagras sådant som vem som utförde kommandot, datum, tid, maskinnamn. Användaren kan även skriva in en kommentar (t.ex. att en viss version användes i en särskild utgåva). History Browser är ett grafiskt gränssnitt för att visa VOB- event records. Genom att använda kommandot annotate kan man se innehållet i en textfil med annoteringar radvis, och kan också sätt lätt se när olika rader tillkom eller borttogs.

3 Gränssnittsutformning Användare inom en projektgrupp har kontroll över den egna arbetsytan (på skärmen) med direkt tillgång till projektets alla filer. Användarna arbetar i sin vanliga miljö, men med ClearCase som tillägg. Det finns två sorters vyer (programfönster), anpassade för att arbeta i nätverk eller lokalt. UNIX- och Windows NT-användare som jobbar i nätverk använder sig av dynamiska vyer. Nya versioner av filer etc. registreras då direkt. Snapshot -vyer ger Windows NT-användare möjligheten att jobba hemifrån och sedan lätt införliva sitt arbete med hela projektet. Användare kan använda sig av ett obegränsat antal vyer. Dynamiska vyer implementeras på den virtuella filsystemsnivån genom ClearCases multi-version file system (MVFS). MVFS fångar upp standard I/O anrop, analyserar förfrågan och finner de önskade versionerna (som är de som visas i vyn) av det valda elementen. I dynamiska vyer ser VOBarna ut som vanliga katalogträd med vanliga filer. I Windows NT ligger MVFS oftast under M -driven med aktiva vyer som underkataloger till M. ClearCase tilldelar en virtuell drive till varje aktiv vy. Monterade VOBar ligger som underkataloger till respektive virtuell drive. Fördelen med en dynamisk vy är att den ger transparent och direkt tillgång till alla element (och dess olika versioner) i alla VOBar, dock krävs kontinuerlig uppkoppling till ett nätverk. Snapshot-vyer implementeras i Windows NT genom att utvalda versioner av VOBelement kopieras till en PCs hårddisk (som att ta en bild på en viss dynamisk vy). När snapshot-vyer är nerladdade ser de ut som standardkataloger och filer. Varje snapshotvy visas i en separat katalog. Användare synkroniserar en snapshot-vy med innehållet i en VOB (efter att ha gjort ändringar bortkopplade från nätverket) genom att använda Snapshot View Update Tool. Fördelen med en snapshot-vy är att användaren har möjlighet att arbeta utan att vara kopplad till ett nätverk. Däremot förlorar han/hon vissa funktionsmöjligheter och andra användare kan inte se förändringar förrän dessa införlivas i helheten. Både snapshot- och dynamiska vyer använder sig av en regelbaserad urvalsmekanism. Den uppsättning versioner som ingår i en viss vy kallas dess konfiguration. Denna definieras av en uppsättning regler, en konfigurationsspecifikation (config spec). Varje användare kan ha flera vyer. De olika vyerna kan visa olika versioner av samma element (samma sökväg). Man kan exempelvis ha en vy som visar den senaste versionen av varje element och en annan för att se de versioner som använts i en speciell utgåva. I en vy har man även tillgång till filer och kataloger som inte versionshanteras i ClearCase (ex. lokala script och program). En projektledare kan skapa gemensamma vyer som hela gruppen kan använda sig av. Därmed kan man försäkra sig om att alla i gruppen använder rätt filversioner. Användare kan titta igenom en lista av tillgängliga vyer och välja den/de som uppfyller deras önskemål. Om man vill arbeta med en annan filversion än den som ingår i en vy kan man

4 antingen komma åt filen genom en annan vy eller genom att identifiera filen i dess versionsträd. Merge Manager ClearCase Merge Manager underlättar för flera användare som utvecklar mjukvara parallellt. Den letar automatiskt upp element i ett projekt som behöver slås ihop (t.ex. om flera användare gjort en unreserved checkout på samma fil och vill göra checkin). ClearCase avgör vilken version som är den gemensamma förfadern till filerna som ska slås samman genom att analysera förgreningen på elementets versionsträd och tidigare merge-kommandon som utförts på detta. Om det finns någon konflikt mellan filerna som ska slås ihop kan ClearCase inte automatiskt avgöra vad som ska gälla, utan användaren får istället avgöra detta. Både automatiska och manuella mergebeslut kan lätt ses över och ändras av utvecklare med Diff Merge Tool. Det finns två sorters merge-operationer: additiv och förminskande. En additiv merge kan användas för att specificera utvalda delar av grenar som ska läggas ihop med filerna i en annan gren. En förminskande merge tar bort ändringar som gjorts i en rad versioner, vilket resulterar i en ny version som innehåller alla förändringar utom dem som explicit inte skulle ingå. Kontroll av processer ClearCase har verktyg för att kunna övervaka utvecklingsprocessen, se till att riktlinjer följs, förhindra åtkomst från personal utan behörighet och automatisera en del av kommunikationen inom projektet. ClearCase-verktyg för att kontrollera processer arbetar på meta-nivå, datastrukturerna och procedurerna som används är oberoende av elementens innehåll. Det finns tre kategorier av meta-data i ClearCase:

5 Attribut. Utvecklare kan fästa attribut, namn-värdepar(t.ex. PASSED=Yes) på de flesta objekt. Attributen kan vara integers, strängar, datum mm. Man kan t.ex. ha ett attribut för att avgöra kvaliten på kod (antar exempelvis värdena A, B, C eller D). ClearCase kan då automatiskt avgöra vilket värde på attributet som ska kopplas ihop med ett visst objekt enligt vissa förutbestämda regler. Hyperlänkar. En hyperlänk binder ihop två objekt. En hyperlänk kan t.ex. binda ett designdokument till en källkodsmodul. Hyperlänkar kan relatera hela element, specifika versioner eller delar av ett objekt. De kan binda ett objekt i en VOB till objekt i andra VOBar. Event history. ClearCase lagrar automatiskt viss information i event records. Där kan man hitta information som vem, när, vad som gjorts och användarens egna kommentarer. Det finns flera verktyg för att kontrollera att riktlinjer följs: Pre-event triggers. En pre-event trigger övervakar användandet av ett specifikt ClearCase kommando (t.ex. checkin) eller en klass av kommandon (t.ex. alla kommandon som modifierar en VOB). Innan kommandot utförs kan man sedan specificera t.ex. att ett visst program eller shell-script ska starta först. Man kan även specificera att ett visst kriteria ska vara uppfyllt innan kommandot körs. Lås. Om man applicerar ett lås på ett objekt kan detta inte längre modifieras. Det kan både vara ett specifikt element som låses och en hel VOB. Man kan även ha en undantagslista när man låser ett objekt som gör att vissa användare kan kringgå låset. Åtkomstkontroll. Man kan bestämma om en viss användare, grupp eller alla ska komma åt en fil. Precis som under UNIX sätts läs-, skriv-, och exekveringsrättigheter. Automatisering av kommunikationen inom projekt Det finns några sätt att underlätta kommunikation inom ett projekt: Post-event triggers. En post-event trigger körs efter att ett specifikt kommando slutförts. Vanligtvis underrättar den en eller flera användare om att ett kommando utförts eller fäster ett attribut till ett objekt. Exempelvis kan en post-event trigger för checkin-kommandot skicka mail till en viss grupp som säger att en viss användare modifierat i en specifik fil. Om användaren skrivit in en kommentar vid checkin kan denna finnas med i mailet. Find queries. ClearCases find-kommando ger utvecklare möjligheten att effektivt avgöra vilket stadie ett visst projekt är i (utan att behöva kontakta ansvarig). Exempelvis kan man vilja hitta alla versioner som är med i Release 2.0, med ett visst värde på attributet PASSED. Dynamiska config specar. En config spec-regel väljer specifika versioner av objekt (som ska visas i en vy) utifrån vissa regler. Reglerna kan använda samma queries som find-kommandot. Exempelvis kan en config spec välja den senaste versionen med attributet PASSED=QA, annars den senaste versionen skapad av användare Jim. ClearCase MultiSite

6 MultiSite ger även projekt som har geografiskt utspridda grupper möjligheten att utveckla mjukvara parallellt. MultiSite kopierar innhehållet i en VOB, vilket placeras på önskade servrar. Med kommandot mkreplica skapas en ny instans av en VOB för en specifik site. En klonad VOB är lokal på den server den placerats på och används för dagligt utvecklingsarbete. Varje gren i en klonad VOB måste ägas av någon. En site kan läsa ändringar gjorda på alla grenar och siter, men kan bara ändra (skriva till) grenar som den själv äger. Ägarskapet gör den parallella utvecklingen mer ordnad och förhindrar att konflikter mellan ändringar gjorda i olika repliker uppstår. Eftersom någon site äger varje gren, kan ClearCase MultiSite automatiskt göra uppdateringar på filer, event histories, hyperlänkar och attribut. MultiSite sänder bara ut ändringarna till de andra kopiorna och slipper därmed kopiering av hela VOBen. Projektledare får själva bestämma hur ofta replikerna ska skicka ut sina ändringar sinsemellan. Under uppdateringen kan utvecklingen fortsätta som vanligt. Arbetet skiljer sig inte för utvecklare som jobbar mot en kopierad VOB gentemot dem som arbetar med originalet. Användarstudie På Ericsson uppmanas utvecklingsavdelningarna att använda ClearCase som stöd vid projektarbete. Jag gjorde en enkät som jag lät en projektgrupp på Ericsson Utvecklings AB besvara. Av deras svar att döma var de till större delen nöjda med programmet med några undantag. Utvecklarna i projektet sitter i Älvsjö och i Östersund och arbetar främst med dynamiska vyer. Förutom huvudfunktionerna i ClearCase används ClearCase MultiSite för att samordna arbetet. De största fördelarna tyckte användarna var att programmet smälter in lätt i NTs filsystem och att det fungerar både under UNIX och NT. Likheterna med kända miljöer gör inlärningströskeln relativt låg. Fortsättningsvis var möjligheten att gå tillbaka och använda gamla versioner av filer uppskattad. En nackdel som alla kände av var att MultiSite inte fungerade tillräckligt effektivt. De tyckte att uppdateringarna mellan siterna var för slö och att det inte fungerade till belåtenhet då någon användare (av flera i projektet) hade en långsam uppkoppling mot server. Dessutom kunde det bli problem om en användare satt och debuggade ett system där både egna och andras filer ingick. Om användaren då ändrat i en av de egna filerna (med avseende på de andra filernas utseende) och sedan någon hunnit checka in en ny version av någon fil (nr 2) tog ClearCase automatiskt den nyaste versionen av denna fil (nr 2) där ändringarna gjorda av den första användaren avsåg versionen innan (den som visas i debuggern). En användare hade ibland problem med att ta bort och flytta filer, men startade han om programmet fungerade det. En annan menade på att det med avsikt var svårt att ta bort filer för att det inte skulle bli problem om t.ex. någon annan användare använde sig av dessa. Slutsatser ClearCase är en groupware-produkt med en distribuerad Client/Server arkitektur. Det underlättar samarbete i grupp, både där utvecklarna är lokaliserade tillsammans och åtskilda. Arbetet kan ske parallellt och vid skilda tidpunkter. Versionshanteringen i ClearCase är tidssparande genom att den kan spåra ändringar gjorda i alla

7 filer/kataloger och stödjer parallellt arbete genom möjligheter att skapa nya grenar i versionsträdet och funktioner för att slå ihop filer. Den parallella utvecklingen stöds även av att alla användare kan överblicka hela projektet och ha egna eller gemensamma vyer (ger alla möjligheten att se exakt samma versioner av filerna). Datat sparas i VOBar på en eller flera hostar, men användarna behöver aldrig bry sig om var filer lagras eftersom ClearCase-servrarna gör informationen åtkomlig globalt (versionsträden ser likadana ut oavsett hur många hostar VOBarna är uppdelade på). ClearCase MultiSite ger användare möjlighet att arbeta med samma filer på olika platser i världen, men det verkar ännu så länge inte fungera lika bra (slö uppdatering av filer) som om användarna arbetade i samma nätverk. Allt eftersom tiden går kommer nog dataöverföring att bli snabbare, vilket kanske förbättrar MultiSitefunktionen. Det finns inga direkta kommunikationsmöjligheter mellan användarna i ClearCase (förutom att man ser andras filändringar direkt), men indirekta kommunikationsmöjligheter finns genom event history records och automatiska utskick vid vissa händelser (om man vill). En förbättring skulle kunna vara att debuggern underrättade användare när en fil (som syns i debugg-fönstret) blivit uppdaterad och gav denne valmöjligheten att använda den gamla filen. Jag tycker även att det skulle vara bra om man underrättades när någon annan användare checkade ut samma fil som man själv arbetade med. En chatfunktion kunde ytterligare stödja samarbetet mellan användare som arbetade med samma element.