Visual Studio, Team Foundation Server, Git, Repositories, Teams – og alt det der…….
Det store bildet
Visual Studio er blitt et helt stort øko-system, med mange forskjellige alternativer og muligheter. Systemet utvider seg, muligheter legges til, fleksibiliteten øker, skillet mellom on-premises og online, cloud løsninger og lokale installasjoner viskes ut.
Hvordan henger egentlig alt dette sammen ?
Vi skal se litt på disse sammenhengene og legge opp en del praktiske og pragmatiske retningslinjer for hvordan dette kan anvendes slik at man får et systemet som “henger sammen”. Vi begynner med å se litt på det store bildet (bokstavelig talt), for hvordan hovedkomponentene henger sammen, og vi skal beskrive det i 7 enkle steg.
Visual Studio (1) (f.o.m. version 2012) kan snakke med to grunnleggende forskjellige kildekontrollsystemer. Dette skjer gjennom Team Explorer. Team Explorer vil anta to forskjellige brukersnitt avhengig av hva slags kildekontrollsystem det er knyttet opp mot. Setter man prosjektet til å anvende TFS Versjons kontroll, som altså er den “gamle” versjonskontrollen vi har hatt siden TFS 2005 kom, så ser Team Explorer ut som I punkt (2) i bildet over. Setter man den til å anvende Git, så ser Team Explorer ut som i (3) i bildet over. Det er altså samme kontroll i to forskjellige drakter og med funksjonalitet tilpasset kildekontrollsystemet. Hvilken av variantene som benyttes styres helt av hva man kopler seg til.
Team Explorer for TFS Versjonskontroll (2) kan kun koples til TFS Versjonskontroll (4), enten en On-premises server installasjon eller til Visual Studio Online (VSO), som er TFS server i skyen.
Team Explorer for Git versjonskontroll (3) kan koples til TFS Git versjonskontroll (5), igjen enten on-premises eller til VSO.
Team Foundation Server har altså to forskjellige kildekontroll systemer innebygd, både den gamle versjonskontroller og den nye Git. Det betyr at om du installerer TFS lokalt, eller du anvender VSO, så kan du for hvert team prosjekt du skaper velge om det skal anvende TFS Versjonskontroll eller Git versjonskontroll. Begge to er integrert I TFS serveren og har samme funksjonalitet mhp bygg, work items, test og koplingene mellom disse.
Når anvendes hvilke av disse ? Det er en trend med overgang til Git, Git er meget raskt og fleksibelt, men det er ikke alle steder man kan gå over. Dersom man har store systemer med stor grad av kopling mellom systemene kan det kreve mye arbeid å bryte dette opp for å få til en overgang til Git. Dersom man har meget store filer, dokumenter el lgn, kan det rett og slett lønne seg å ha disse i TFS Versjonskontroll og ikke Git. Med Git vil alt lastes ned lokalt, mens med TFS versjonskontroll lastes kun ned det du trenger å jobbe med. For vanlig kildekode vil dog Git i mange tilfelle være å foretrekke. Git oppleves som veldig utvikler-vennlig!
Man skal også være oppmerksom på at det er en viss terskel for å gå over til Git kompetansemessig, og utviklerne må få tid til å sette seg inn i Git. Erfaringen tilsier at de aller fleste har minimale problemer etter en kort overgangsperiode, og de aller færreste ønsker å gå tilbake.
Det som er spesielt med Team Explorer for Git (3) er den også kan koples til andre Git systemer, eksempel over er kopling til GitHub ( 6 ). Det kan være et hvilket som helst Git system man kopler til. Funksjonaliteten mhp kildekontroll er den samme, men man får selvfølgelig ikke automatisk bygg, workitems og integreringen mellom disse, utover det som eventuelt det eksterne systemet måtte ha på egen hånd.
Det er også verdt å merke seg at den er koplet til et lokalt Git repository (7). Dette skjer automatisk om man kopler seg til et remote og cloner dette. Men man kan også skape lokale Git repositories som ikke er koplet til noe eksternt repository. Dette kan være nyttig når man starter opp et prosjekt, men det normale er at man alltid anvender et remote repository.
Repositories
I TFS versjonskontroll finnes det kun ett “repository” som er felles for alle team prosjekter og hvor all kildekode ligger, med en folder per teamprosjekt. Med Git versjonskontroll endrer dette seg fullstending. For hvert eneste Team Prosjekt kan man ha ikke bare ett, men multiple repositories, og man bør faktisk anvende multiple repositories.
Bildet over viser ett team prosjekt kallt “Main project”, og med ett repository per applikasjon under.
Det er forøvrig etterhvert blitt en etablert praksis med å forsøke å samle prosjektene man har i ett teamprosjekt, the “One teamproject to rule them all”-filosofien.
Med Git er det viktig at repositoriene er små, dette henger sammen med at man bryter ned større systemer i sine respektive komponenter/applikasjoner og da gjør ett repository for hver komponent/applikasjon. Git i seg selv clones ned til din lokale maskin, og da er det teknisk sett smart at repositoriet ikke er for stort.
I praksis betyr dette at et repository kun skal inneholde kildekode, ikke binærfiler og ei heller data. (Unntak er mindre data som anvendes i unit tester). Dette igjen støtter opp under komponenttankegangen og bruken av komponentbiblioteker som f.eks. NuGet, eller Bower (for javascript) Når man anvender NuGet kan man også anvende egne NuGet repositories for å bygge opp avhengigheter mellom egne komponenter. Slike repositories kan man hoste internt med en egen NuGet server, eller man kan anvende 3dje parts tjenester som MyGet.
Teams, og sammenhengen til repositories
Ett Team Prosjekt kan deles opp i multiple team. Når man sier Team så hører man automatisk “en gruppe av mennesker”. Dette er i og for seg riktig, men i TFS kan og bør man tenke litt annerledes. Et Team styres i utgangspunket av en del av area-treet, man kopler et TEam til en bestem node I dette treet. (Det finnes også en opsjon for å anvende et eget Team felt). Area treet definerer produkt treet ditt, og det betyr at et Team representerer et produkt eller del av et produkt.
Altså:
Team : Produkt, eller del av produkt.
Men vi hadde jo:
Repository: Applikasjon eller komponent, og Applikasjon er jo ganske lik Produkt.
Et repository anvendes for kildekode, et Team anvendes for work items. Og, de [kan] representere samme ting!
Det er altså fornuftig å anvende stort sett samme oppdeling for både Team og repositories.
Ser vi på det team prosjektet som anvendes for repositoriene i bildet over, ser det slik ut:
Som man kan se er det ganske likt.
Det å sette disse like gjør det enklere å navigere i TFS, og man får workitems og kildekode på samme nivå. Det er ingen teknisk binding mellom disse i TFS, så dette er en “best practices” konvensjon.
Teamene blir da det vi kaller Feature Teams, og siden organiseringen av TFS er basert på team, betyr at at vi får en backlog per Team, eller da per applikasjon/komponent/produkt. Når dette stemmer overens med et Git repository, så blir det også en bra kopling mellom Team og repository som er lett å forstå.
Chief Geek at Inmeta Consulting
Follow on twitter: @OsirisTerje
Blog on : https://geekswithblogs.net/terje
Inmeta blog: https://www.inbeta.no/