Välj en strategi för kodflöde

Slutförd

Det är viktigt att välja en kodflödesstrategi som passar ditt team. Du har flera strategier att tänka på. I slutet av modulen kan du utforska alternativ. Tailspin-webbteamet bestämmer sig för att utveckla en kodflödesstrategi som baseras på Git och GitHub.

När Mara konfigurerade Azure Boards identifierade hon och teamet några inledande uppgifter som behövde utföras. En uppgift var att skapa ett Git-baserat arbetsflöde.

Vi lyssnar på teamet när de hittar ett bättre sätt att samarbeta. För närvarande använder de ett centraliserat versionskontrollsystem, men planen är att flytta till Git, ett distribuerat system.

Mara arbetar koncentrerat med sina uppgifter när Andy kommer på besök.

Hej Mara. Vid ledningsmötet i morse togs det upp att vårt team och spelutvecklingsteamet använder olika versionskontrollsystem. För att effektivisera hur vi delar resurser mellan team har vi blivit ombedda att gå över till ett distribuerat versionskontrollsystem som bättre kan hantera samarbetet.

Mara: Det är bra att veta. Om du kommer ihåg, sätter vi det på vår bräda. För närvarande använder vi ett centraliserat versionskontrollsystem. Det fungerar bra för oss nu, men jag håller med om att ett distribuerat versionskontrollsystem är ett bättre val när vi börjar dela mellan team och vårt team blir större. Det är också en uppgift i vår styrelse att öka synligheten så att alla intressenter vet vad alla gör. Jag tror att ett distribuerat källkontrollsystem som Git också skulle hjälpa.

Andy: Jag har velat prova Git ett tag. Jag verkar aldrig ha tid. Är det svårt att lära dig eller konfigurera? Om det verkar rimligt kan vi kanske börja ordna det nu. Jag är trött på att alltid skjuta fram saker. Och det skulle vara trevligt att kunna se vad alla gör och att ha åtkomst till hela lagringsplatsen. OK. Hur funkar det?

Mara: Låt mig förklara det, och sedan kan du bestämma om det låter som något vi vill implementera direkt.

Mara och Andy går till whiteboarden för att diskutera versionskontroll.

Vad är Git och distribuerad versionskontroll?

Mara: Ritningen till vänster är centraliserad versionskontroll, som det vi använder nu. Vi har en central version av kodbasen i Team Foundation Version Control (TFVC) som alla använder. Vi arbetar var och en med de filer som vi behöver ändra och sammanfogar dem sedan tillbaka till huvudlagringsplatsen när vi är klara med dem.

Andy: Ja, och det fungerar för oss. Tja, förutom när jag blockerades den gången när en icke-bakåtkompatibel ändring sammanfogades till den centrala lagringsplatsen.

Mara: Höger! Du har blockerats . Vi skulle kunna använda en förgreningsstrategi med TFVC för att lösa blockeringsproblemet, men i vår nuvarande konfiguration kan sammanslagning nog bli mer komplicerat. Och när vi hade den där icke-bakåtkompatibla förändringen kunde ingen få något gjort förrän vi fick det löst. Det problemet lurar alltid, eftersom vi alla använder samma kopia av koden.

Till höger finns illustrationen av distribuerad versionskontroll. Vi har fortfarande en central lagringsplats som är den stabila versionen av kodbasen, men varje utvecklare har en egen kopia av den att arbeta från. Detta gör att vi kan experimentera och prova olika metoder utan att påverka den centrala lagringsplatsen.

Kontroll av distribuerad version säkerställer också att endast arbetskoden slås samman till den centrala lagringsplatsen. Vi kan till och med konfigurera den så att koden inte kan sammanfogas förrän den har granskats.

Det som är coolt med Azure DevOps är att det fungerar bra både med centraliserade versionskontrollsystem och distribuerade versionskontrollsystem.

Andy: Vad händer när fler än en person ändrar samma fil?

Mara: Ofta kan Git sammanfoga flera ändringar automatiskt. Naturligtvis vill vi alltid se till att kombinationen av ändringar resulterar i kod som fungerar. När Git inte automatiskt kan sammanslå ändringar markerar det konflikter direkt i filerna så att en person kan välja vilka ändringar som ska godkännas.

Andy: Just nu lagras vår kod på vår egen server. Var lagras koden om vi övergår till att använda distribuerad versionskontroll?

Mara: Jag är glad att du frågade. Det är här värdhantering kommer till pass.

Var kan jag hantera min lagringsplats?

Mara: När vi bestämmer var vi ska vara värdar för våra lagringsplatser har vi några alternativ. Vi kan till exempel vara värdar för dem på en lokal server, i Bitbucket eller i GitHub. Bitbucket och GitHub är webbaserade värdlösningar. Vi kan komma åt dem var som helst.

Andy: Har du använt någon av dem?

Mara: Jag har använt GitHub tidigare. Den har funktioner som är viktiga för utvecklare, till exempel enkel åtkomst till ändringsloggar och funktioner för versionskontroll från antingen kommandoraden eller onlineportalen.

Andy: Så hur fungerar Git?

Hur arbetar jag med Git?

Mara: Som jag nämnde tidigare, med distribuerade system, kan utvecklare komma åt alla filer de behöver utan att påverka andra utvecklares arbete eftersom de har en egen kopia av lagringsplatsen. En klon är din lokala kopia av en lagringsplats.

När vi arbetar med en funktion eller en buggfix vill vi oftast prova olika metoder tills vi hittar den bästa lösningen. Men att testa kod på din kopia av huvudkodbasen är inte en bra idé, eftersom du kanske inte vill behålla de första försöken.

För att ge dig ett bättre alternativ har Git en funktion som kallas förgrening, där du kan underhålla så många kopior som du vill och slå samman endast den som du vill behålla. Det gör att huvudgrenen förblir stabil.

Andy: Jag förstår begreppen hittills. Hur checkar jag in min kod?

Hur kommer mina lokala ändringar upp till huvudkodbasen?

Mara: I Git kallas standardgrenen eller main vanligtvis .

När du känner att din kod är redo att sammanfogas till grenen main på den centrala lagringsplatsen som delas av alla utvecklare skapar du det som kallas en pull-begäran. När du skapar en pull-begäran berättar du för de andra utvecklarna att du har kod redo att granska och vill att den ska sammanfogas i grenen main . När din pull-begäran godkänns och sedan sammanfogas blir den en del av den centrala kodbasen.

Hur ser ett förgreningsarbetsflöde ut?

Steg 1: När du börjar arbeta med en ny funktion eller buggkorrigering är det första du vill göra att du börjar med den senaste stabila kodbasen. Det kan du göra genom att synkronisera din lokala kopia av main-grenen med serverns kopia. Detta hämtar alla andra utvecklarändringar som har push-överförts till grenen main på servern sedan den senaste synkroniseringen.

Steg 2: För att säkerställa att du bara arbetar med din kopia av koden skapar du en ny gren bara för den funktionen eller buggkorrigeringen. Som du kan föreställa dig kan det bli svårt att komma ihåg många grenar för allt du gör, så det är viktigt att använda en bra namngivningskonvention.

Innan du gör ändringar i en fil kan du checka ut en ny gren så att du vet att du arbetar med filerna från den grenen och inte från en annan gren. Du kan när som helst växla grenar genom att checka ut den grenen.

steg 3: Du är nu säker att göra vilka ändringar du vill eftersom dessa ändringar bara finns i din gren. När du arbetar kan du committa dina ändringar till din branch för att säkerställa att inget arbete går förlorat. Detta ger också ett sätt att återställa alla ändringar som du har gjort i tidigare versioner. Innan du kan checka in ändringar behöver du mellanlagra filerna så att Git vet vilka du är redo att checka in.

Steg 4: Nästa steg är att skicka eller ladda upp din lokala gren till fjärrlagringsplatsen (till exempel GitHub) så att andra kan se vad du arbetar med. Men du kan vara lugn – dina ändringar sammanslås inte ännu. Du kan överföra ditt arbete så ofta du vill. Det är faktiskt ett bra sätt att säkerhetskopiera ditt arbete eller tillåta dig själv att arbeta från flera datorer.

steg 5: Det här steget är vanligt men krävs inte. När du är nöjd med att koden fungerar som du vill kan du hämta eller sammanfoga fjärrgrenen main tillbaka till din lokala main gren. Det har skett ändringar där som din lokala main-gren ännu inte har fått. När du har synkroniserat fjärrgrenen main med din sammanfogar du din lokala main gren till din arbetsgren och testar bygget igen.

Den här processen ser till att din funktion fungerar med den senaste koden. Den kan även säkerställa att ditt arbete integreras korrekt när du skickar pull-begäran.

Steg 6: Din lokala kod måste nu checkas in och push-överföras till den värdbaserade lagringsplatsen. Det här är samma som steg 3 och 4.

Steg 7: Du är äntligen redo att föreslå dina ändringar i fjärrgrenen main . Det gör du genom att skapa en pull-begäran. När det här steget konfigureras i Azure Pipelines eller ett annat CI/CD-system utlöser det byggprocessen och du kan se dina ändringar gå igenom pipelinen. När bygget har slutförts och andra har godkänt din pull-begäran kan koden sammanfogas till fjärrgrenen main . (Det är fortfarande upp till en människa att sammanfoga ändringarna.)

Andy: Allt detta ser komplicerat och svårt att lära sig.

Mara: Git kan verka skrämmande eftersom det är så kraftfullt, men när du har fått kläm på flödet börjar det kännas naturligt.

Du använder bara några få kommandon dagligen. Här är en sammanfattning:

Kategori	Så här utför du uppgiften	Använd följande kommando
Hantering av lagringsplats	Skapa en Git-lagringsplats	git init
	Ladda ned en fjärrlagringsplats	git clone
Filial	Skapa en gren	git checkout
Mellanlagra och checka in ändringar	Se vilka filer som har ändrats	git status
	Mellanlagra filer som ska checkas in	git add
	Checka in filer till din gren	git commit
Fjärrsynkronisering	Ladda ned en gren från en fjärrlagringsplats	git pull
	Ladda upp en gren till en fjärrlagringsplats	git push

Andy: Det låter som en bra utgångspunkt. Det klarar jag definitivt av. Jag kan lära mig mer avancerade kommandon allt eftersom de behövs.