Vad är ett versionsbaserat arbetsflöde?
Här går vi igenom hur du kan skapa ett versionsbaserat arbetsflöde med hjälp av GitHub.
Vad är ett versionsbaserat arbetsflöde?
Ett versionsbaserat arbetsflöde är en uppsättning mönster och principer som fokuserar på att släppa programvara. Även om den här uppfattningen kan verka som ett uppenbart mål för ett utvecklingsteam, är värdet av det här perspektivet mer nyanserat. I den här lektionen diskuterar vi hur det styr tre olika delar av lanseringscykeln: hantera projektet, välja en förgreningsstrategi och släppa till kunder.
Planera arbete med projekttavlor i GitHub
När det gäller planering så innebär versionsfokuset att ärenden delas upp i distinkta iterationer som skapar en ny version. Dessa iterationer kallas ofta sprintar och är tids boxade i ungefär lika långa perioder för att skapa inkrementella ändringar. Andra team föredrar att paketera hela versioner i en iteration, som kan hålla på några månader eller längre. I GitHub hanteras dessa iterationer som projekt.
Det dominerande inslaget i ett projekt är dess styrelse. Tavlan är den centrala planen för iterationen och innehåller alla kort som ska hanteras. Ett kort kan representera ett ärende, en pull-begäran eller bara en allmän notering.
Som standard startar varje kort i kolumnen Att göra och flyttas till Pågår efter att arbetet har börjat innan det slutar i Klar. Du kan anpassa dessa kolumner, lägga till fler kolumner eller tillämpa automatisering på förflyttningen av dessa kort och deras egenskaper så att de passar teamets process.
Läs mer om att hantera projekttavlor.
Kortets projektstatus är integrerad i lagringsplatsen. Om du till exempel drar ett kort från Att göra till Pågår ändras dess status och den visuella indikatorn uppdateras bredvid projektets rubrik. Det gröna avsnittet anger den del av korten som har markerats som Klar, medan lila används för kort som pågår. Det återstående utrymmet representerar antalet kort som inte har påbörjats ännu. Förutom att dra kort runt brädet kan du uppdatera dem från huvudvyn.
När du använder en projekttavla har alla intressenter ett enkelt sätt att förstå status och hastighet för ett projekt. Du kan också skapa tavlor som är begränsade till enskilda användare eller en samling lagringsplatser som ägs av en organisation.
Läs mer om att spåra förloppet för ditt arbete med projekttavlor.
Spåra specifika milstolpar
För team, eller eventuellt delmängder av team, erbjuder GitHub milstolpespårning .
Milstolpar liknar projektspårning eftersom det finns en betoning på prioriterat slutförande av problem och pull-begäranden. Men där ett projekt kan fokusera på teamets process fokuserar en milstolpe på produkten.
Läs mer om hur du spårar förloppet för ditt arbete med milstolpar.
Välja en förgreningsstrategi
Lagringsplatser där flera utvecklare arbetar parallellt behöver en väldefinierad förgreningsstrategi. Att etablera sig på en enhetlig metod tidigt i projektet sparar förvirring och frustration när teamet och kodbasen skalas.
GitHub-flödet
GitHub är inte bara en plattform för samarbete inom programvaruutveckling utan erbjuder även ett föreskrivet arbetsflöde som utformats för att optimera användningen av de olika funktionerna i GitHub. Även om GitHub kan fungera med praktiskt taget alla programutvecklingsprocesser rekommenderar vi att du överväger GitHub-flödet om ditt team inte har bestämt sig för en process ännu.
Arbeta med långlivade grenar
En långlivad gren är en Git-gren som aldrig tas bort. Vissa team föredrar att undvika dem helt och hållet till förmån för kortlivade funktions- och felkorrigeringsgrenar. För sådana team är målet att producera en pull-begäran som sammanfogar arbetet med main-grenen. Den här metoden kan vara effektiv för projekt som aldrig behöver se tillbaka, till exempel webbprogram från första part som inte har stöd för en tidigare version.
Det finns dock vissa scenarier där långlivade grenar fungerar bättre för teamet. Det vanligaste fallet är när en produkt har flera versioner som måste stödjas under en längre tidsperiod. När ett team behöver planera för ett sådant åtagande bör lagringsplatsen följa en standardkonvention som release-v1.0, release-v2.0 och så vidare. Dessa grenar bör också markeras som skyddade i GitHub så att skrivåtkomst styrs och inte kan tas bort av misstag.
Teamet bör fortfarande underhålla main-grenen som rotgren och slå samman versionsgrenarna med ändringar uppströms så länge de passar in i projektet. När det är dags för release-v3.0 ska den baseras på main-grenen, så att inte arbetet i release-v2.0 gör lagringsplatsen mer komplicerad.
Arbeta med långlivade grenar
Anta att en buggfix har slagits samman i grenen release-v2.0 och sedan uppströms till main-grenen. Det upptäcktes senare att den här buggen också fanns i grenen release-v1.0 och att korrigeringen behövde backporteras för kunder som fortfarande använder den versionen. Vilket är det bästa sättet att backportera den här korrigeringen?
Att slå samman grenen main i release-v1.0 skulle inte vara ett genomförbart alternativ, eftersom det skulle innehålla ett betydande antal incheckningar som inte var avsedda att ingå i den versionen. Av samma anledning skulle det inte vara ett alternativ att release-v1.0 bygga om den aktuella main incheckningen.
Ett alternativ kan vara att implementera om korrigeringen i grenen release-v1.0, men den metoden kräver mycket arbete och blir snabbt opraktisk om det gäller fler versioner. Git har dock en automatiserad lösning på det här problemet i form av kommandot cherry-pick.
Vad är Git-kommandot cherry-pick?
git cherry-pick är ett kommando som gör att du kan tillämpa vissa incheckningar från en gren till en annan. Det itererar bara de valda incheckningarna och tillämpar dem på målgrenen som nya incheckningar. Vid behov kan utvecklare sammanfoga eventuella konflikter innan den retroaktiva ändringen slutförs.
Läs mer om Gits cherry-pick-funktion.
Lansering till användare
När en produktversion är redo att lanseras är det enkelt att paketera den och meddela användarna i GitHub.
Att skapa en version är lika enkelt som att fylla i formuläret:
- Ange en Git-tagg som ska tillämpas, som ska följa semantisk versionshantering, till exempel
v1.0.2. GitHub hanterar processen att skapa den Git-tagg du anger. - Ange ett namn på versionen. Några vanliga metoder är att:
- Använda ett beskrivande namn
- Använda Git-versionen
- Använd en kortfattad sammanfattning av hur versionen har ändrats sedan den föregående
- Använd ett kodnamn eller en slumpmässig fras
- Ange versionskommentarer. Du kan automatisera den här uppgiften med appen Release Drafter, som analyserar ändringarna sedan den tidigare versionen och innehåller tillhörande pull-begäranderubriker.
- Om du vill ange filer som en del av versionen, till exempel fördefinierade installationsprogram, kan du dra och släppa dem i formuläret. Du behöver inte paketera källkoden eftersom GitHub hanterar det åt dig.
- Ange om versionen är förhandsversion genom att markera den rutan. Den här indikationen hjälper kunderna att undvika förhandsversioner om de vill.
När en version har publicerats får alla som tittar på lagringsplatsen ett meddelande.
Läs mer om GitHub-versioner.