ClearCase on Git Steroids March 21, 2009 01:39 about 1 year ago
Concentration breaker: Manden ved siden af mig skriger: “pis, min kode er væk, jeg er sikker på jeg har lavet den ændring mindst en gang før og nu kan koden ikke kompilerer”. Dette udtrykker en typisk situation på min hypotetiske arbejdsplads.
Moderne udvikling har brug for effektiv versionsstyring der understøtter iterative udviklingsmetodikker med ultra korte roundtrips. Samtidigt må alle versionsstyringsprocesser være kendte og enkel at benytte. De basale egenskaber ved ved hver enkelt versionssystem bør nøje svare til udviklingafdelingens arbejdsproces og bør som minimum give et implicit indtryk af rutine og sikkerhed.
Det forventes at alle kender og forstår versionsstyring men det er ofte en overset faktor ligesom der aldrig undervises på området. Det er mig en gåde at organisationerne ikke bruger flere ressource på uddannelse og videnspredning på et områder som berøre hele afdelinger. Holdningen er ofte den at versionsstyring er et nødvendigt onde og ingen gider at forfølge versioneringen i bund. Processen bliver sekundær og kan trækker både stemning og produktivitet i negativ retning.
Versionsstyring kan oversættets til revisionskontrol Revisionskontrol hjælper os med at kontrollere de små skridt som tilsammen udgør den samlede værdiforøgelse. I Systemudvikling benyttes ofte ordet Software Configuration Management men er blot et anden ord for samme proces.
Basale ting man kan bedømme et revisionskontrol system efter:
- Granularitet. Hvor store “change set”: opereres der med? Hvis en ændring kun berører en fil af gangen betyder denne skelnen ikke noget men jo flere filer eller biblioteker der indgår er det en fordel at kunne håndtere ændringerne samlet i “change set”.
- Låsning. Man opererer med låsning eller fletning af de berørte elementer og uden denne mekanisme er der kun en regel som gælder: sidst skriver bedst.
- Centralt/decentralt. Den traditionelle løsning har en central server eller “repository” mens nye decentrale løsninger er kopieret ud over mange noder hvor alle vægter lige højt.
Basal problematik
Problemerne i versionsstyring er basale. To personer skriver i den samme fil samtidig. Den første levere den “nye” fil tilbage til versions styringssystemet. Den anden levere den “nye” fil tilbage til versions styringssystemet. Indtil nu er det en normal “merge” situation som opstår. Begge henter A ud og sender B og C tilbage og de sammenlægges til A1. Desværre er det normale at “merge” bliver afhængig af sourceversion. Når C vil sende sin kode tilbage til A har B opløftet A til A1.
Vertikal kontra horisontal udviklingsmetodik kræver forskellige egenskaber i versionsstyring. Misforstår disse koncepter kan det kan det betyde forskellen mellem succes og fiasko. Måske er det ikke den bedste ide at vælge et indviklet system til rene start op projekter hvor kodebasen er ustabil og kræver hyppige opdateringer.
Hvis man hypotetisk tænker sig et projekt hvor projektledelsen har valgt ClearCase kan man være ret sikker på at modstanden i udviklingsafdelinger er stor og de fleste vil påstår at værktøjet ligefrem står i vejen for deres fremdrift. Version kontrol er et afgørende aspekt af enhver software-projekt, og dets betydning bør ikke undervurderes.
ClearCase er fx baseret på sikkerhed. Det påstås at produktet aldrig har tabt data. Git er skabt med henblik på integration mellem brugerne. Spørgsmålet er naturligvis om man kan opnår begge egenskaber uden at tilføre ekstra uhensigtsmæssigheder. Valg af versionssystem kan ødelægge udviklingsprocessen eller bidrage til udviklings livscyklusen som en naturlig udvidelse af tool setttet. I værste fald kan det have en afskrækkende indflydelse på god udviklingspraksis såsom refactoring, hyppige commits, og løbende build strategier.
Moderne udviklingsmetodikker kræver gode versionsstyringssystemer. De bedste programmører i verden arbejder sammen fra forskellige fysiske lokationer i verden og derfor er nye decentrale versionsstyringssystemer populære. Metoden hvor man benytte et centralt styret versionsstyringssystem til en virksomhed er ved at uddø. Og med god grund. Det kan ikke længere betale sig at samle et udviklingshold indenfor de 4 vægge og lade dem tro at de bygge et superprodukt. Hidtil har den centrale løsning med et repository og kopier hos udviklerne være den mest brugte. Alle committer deres ændringer til det fælles repository og andre kan update deres lokale kopi fra denne source.
Den decentrale løsninger består af mange ens kopier som alle vægter lige højt. Man kan hente eller sende nye ændringer til og fra alle noder og man vil selv stå for evt merge konflikter i begge retninger. I den decentrale løsning kan man hente ændringer et vilkårligt sted fra og skulle det medfører konflikter skal man selv løse problemet. Der er altså ingen fast rollefordeling.
Modellen med et centralt repository lader sig realisere på den decentrale model og man vil “nok” blive enig om at have en knude som “master”. Det er muligt at bygge et hierarki i flere niveauer hvilket kunne indenholde states, som f.eks. "unstable”, “stable” og “accepct”. Den decentrale model er mindre sårbar for permanente udfald. De andre knuder kan reorganisere sig og køre videre på deres kollektive viden.
Clearcase
Clearcase er et centralt versionsstyringssystem med en server som hoster et fælles repository. De mindste skridt spores: individuelle filer, mappetræ, versioner, grene, brugere, tilladelser, socialsikringsnummer, DNA-sekvenser osv. klienten får en fungerende kopi af projektet filer og værktøjer til at kommunikere med serveren. Clearcase klienten kan ikke opererer uden forbindelse til det centrale repository.
Clearcase VOB
Clearcase er opbygget omkring en VOB. En VOB består af filer, biblioteker, elementer og links. Hver gang der checkes noget ind fra et view tilføres en ny version. Alle filer og biblioteker kaldes elementer og alle elementer har fremadløbende revisionnummer. Alt der checkes ind kaldes en version. I VOB’en findes alle versioner af et element samt metadata med checkout kommentare og der beskriver hver enkelt version. Et projekt vil ofte skulle hente sourcekode fra flere VOB’s.
Man kan ikke operere direkte på VOB’en. Dette gøres gennem en VOB pool med personlige views. I hvert view findes metadata om klienten og en række aktiviteter. Alle bevægelser på et view er forbundet med en aktivitet. Enhver aktivitet har et “changeset”. Et “changeset” er en logisk sammenhørende pakke hvori alt er relateret til præcist en aktivitet. Et “changeset” kan bestå af filer, biblioteker, links, samt metadata som aktivitetsbeskrivelse. Et “changeset” bliver til en personlig version når det bindes til VOB’en med et tidstemple(baseline). Denne version kan releases til VOB.
Andre udviklere på projektet vil ikke kunne se ændringer før de er “baselinet”, altså flettet ind i den fælles integrations strøm. Derfor er clearcase modellen er ikke velegnet til eksperimentel og iterativ udviklingmetodik. Hvis et kreativt projektteam laver store mængder af eksperimentel udvikling kræves der mange branch’s. Clearcase fraråder eksperimentel branch’ing med streams som er centraliseret. Clearcase er linjeorienteret og har problemer med at flette ikke traditionelle filer. Clearcase understøtter ike patch’ing men bygget på fælles baseline. Clearcase aktiviteter tillader ikke logisk commits i en aktivitet men kun checkin. Clearcase understøtter ikke decentral udvikling.
Git
Git er et distribueret versions system lavet af Linus til at opretholde Linuxkernen. Git kræver ingen tilgang til centraliseret server. Git gemmer repository i en enkelt skjult mappe øverst i projekt træet. Det er meget let at lave et git repository fra et eksisterende projekt:
cp -R ./clearcase/project ./git/project cd ./git/project git init git add . git commit
Git repository er lokalt og kontrollers lokalt. Git operere kun med merge, det lader sig ikke gøre at låse en fil eller bibliotek. Der behøves ikke en tilladelse til at oprette eller ændre elementer og der er ikke forbindelse til et centralt repository. Git fordre mange branch’s og de opbygget som letvægts processer. Derfor betragtes modellen som velegnet til eksperimentel udvikling.
Den fineste egenskab i Git er support for “non-linear” udvikling. Det betyder at git er velegnet adræt branching og merging. Git giver hver udvikler en lokal kopi af hele repositoriet og ikke kun den sidste “recommended” version.
Effektivt håndtering af store projekter. Git er langt bedre end ClearCase når det gælder store source mængder. ClearCase er nærmest kendt for sin langsommelige adfærd når en VOB overstiger et par gigabyte indhold. Git derimod er hurtigt og skalerbart selv ved meget store repositorier. Git har også en veldefineret flette strategi når mange merges points findes. Interne har Git flere forskellige metoder og som sidste udvej er manuel editering.
Her checkes to branch’s spor ud, en bugfix og en refactoring. Der tilføjes og testes hvorefter der udføres en commit med kommentaren “fixed”. Herefter merges refactoring ind i bugfix branch.
cd ./git/project git checkout bug_fix git checkout -b refactoring // change, compile, test git add * git commit -m 'Fixed' git checkout bug_fix git merge refactoring
Hvis refactoring var unødvendigt kunne det sidste merge undlades eller den eksperimentale refactoring kunne fjernes permanent. Branch blev oprettet hurtigt for at afprøve nogle ideer og kan ignoreres eller fjernes. At konstruere, flette og fjerne branch er op til denne enkelte udvikler. Git understøtter mulighed for at opbygge logiske changesets.
ClearCase til Git
Hvis et projekt både har udviklere på Clearcase og Git samtidigt skal ændringerne fra CC først merges ind i en Git instans. Dette kan behandles som en rsync proces hvor koden i en fra en lokal clearcase stream hentes ind i en git branch og merges ind i udviklingsstrømmen og fixer konflikter undervejs. Git rebase udføre dybest set dine commits på din branch og merger med den ønskede branch, for derefter at indføre dine commits igen. Denne metode holder historien enkel. Det anbefales dog at man udføre sit udviklingsarbejde i en sub-branch af master branch. Behold master branch alene for rebases.
cd /clearcase/project cleartool rebase -recommended cd ./git/project git checkout master rsync -r ./clearcase/project ./git/project git commit -a -m 'rebased from clearcase' git checkout dev_branch git rebase master
Git til Clearcase
Hvis man vil levere kode tilbage til Clearcase er den nemmeste måde at gøre dette på er ved at anvende patches til Clearcase. Man lader git generere et patch for et enhvert commit.
git diff 3 > change.patch
Hvis man navn giver git-diff til et branch navn i stedet for et commit generes en patch for hver divergerende commits mellem de to branches. Hvis master branch repræsenterer strømmen i en rebased clearcase branch og din dev branch er ’git rebasered to master" kommandoen.
cd ./project/git git checkout bug_fix git diff master > bug_fix.patch cd ./clearcase/project patch -p2 < /git/project/bug_fix.patch
Build, test and submit to clearcase.
Hvis et projekt har seriøse problemer med at benytte og forstå versionsstyring vil problemerne ikke forsvinde ligemeget hvilket tool man benytter. Mens jeg afslutningsvis lave en kop kaffe slår det mig at vi operere med versionstyring på samme måde som vi laver kaffe. Nogle mennesker udmåler manisk hver ske af den fineste ristede bønne man kan tænke sig og venter på at vandtemperaturen falder til 93 grader, mens andre fylder kaffe i direkte fra posen og sjusser sig frem til den rette blanding af spilkogende vand og bønner.
En ting er sikkert, det kræve meget kaffe at kunne kontroller versionstyring i projekterne.
By Frank Vilhelmsen - 1 tag: git - 2 comments on ClearCase on Git Steroids - Add comment
Stig March 31, 2009 05:28 about 1 year ago
Det er en smule spøjst, at du beskriver to så markant forskellige versionsstyringsværkøjer – du ku’ dårligt vælge nogen, der ligger længere fra hinanden end netop dem. Men det er måske netop pointen??
Hvis det skal bidrage seriøst til valg af versionsstyring, mangler der helt klart mellemvaren, nemlig subversion (eller det hedengangne CVS).
Alle 3 (subversion, ClearCase & git) har deres fordele og ulemper, men lige meget hvordan jeg end vender og drejer det, har jeg viiiildt svært ved at forstår berettigelsen for ClearCase. ;)
Frank Vilhelmsen April 01, 2009 21:55 about 1 year ago
Hi Stig, jeg er rigtig glad for du læser mine posts. Du ved jo at jeg skriver for mit personlige forgodtbefindende på baggrund af min hverdag. Jeg prøver at undgå at referer til eksakte prikære situationer men jeg lader mig jo påvirke af kollegaer, projektledere og andet godtfolk. Disse input krydser jeg med dramaturgi fra mit tidligere virker som reklamefotograf på samme måde som et nyhedsindslag, der findes kun helte og skurke. Alt indimellem er bare fyld og uden interesse. :-)
Håber det kan føre til svaret. Et par af de egenskaber jeg berøre er:
- Tvang og ønske
- Gammel og ny
- Central og decentral
- Tung og let
- Langsomt og hurtigt
- Administrator eller udvikler
Min opgave var blot at ridse de to yderpunkter op, og måske kan de kombineres?
Pointen med hele denne post må være at man grundlæggende ikke løser problemer med et versionstyringssystem, man versionere.