Gren strategiskt

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Källkod är en viktig tillgång i din utveckling. Men det kan vara en utmaning att effektivt hantera och utveckla källfiler när flera utvecklare arbetar samtidigt med filuppdateringar. Du kan använda ett versionskontrollsystem för att lagra källkod i delade lagringsplatser, isolera parallella utvecklingsarbete, integrera kodändringar och återställa tidigare filversioner. Ett nyckelelement i versionskontrollen är förgrening som möjliggör samtidig utveckling. Om du förgrenar dig strategiskt kan du upprätthålla ordningen och konsekvensen för flera versioner av din programvara.

Team Foundation tillhandahåller ett flexibelt och tillförlitligt versionskontrollsystem. Du kan använda Versionskontroll för Team Foundation för att hantera flera revisioner under utvecklingen av källkod, dokument, arbetsobjekt och annan viktig information som ditt team arbetar med.

Hur hanterar teamet kod medan den introducerar flera ändringar samtidigt via flera projektversioner?

När du arbetar med ett versionskontrollsystem måste du överväga hur du konfigurerar en grenstruktur. Du kan skapa en gren genom att spegla källkodsfilen. Sedan kan du ändra grenen utan att påverka källan. Som grenstrukturen i följande bild till exempel visar innehåller MAIN-grenen slutförda funktioner som har klarat integreringstester och utvecklingsgrenen innehåller koden som håller på att byggas. När en ny funktion i utvecklingsgrenen har slutförts och kan klara integreringstester kan du höja upp koden från utvecklingsgrenen till MAIN-grenen. Den här processen kallas omvänd integrering. Om du sammanfogar koden från MAIN-grenen till utvecklingsgrenen kallas processen vidareintegrering.

Mer information om hur du skapar och sammanfogar kodgrenar finns på följande sida på CodePlex-webbplatsen: Team Foundation Server Branching Guide 2.0.

Förgrening och sammanslagning medför följande principer:

1. Varje gren måste ha en definierad princip om hur du integrerar kod i den här grenen. I grenstrukturen i föregående bild kan du till exempel tilldela en gruppmedlem att äga och hantera MAIN-grenen. Den här medlemmen ansvarar för att utföra den inledande grenåtgärden, bakåtintegrera ändringar från utvecklingsgrenen till MAIN-grenen och vidarebefordra integrering av ändringar från MAIN-grenen till utvecklingsgrenen. Framåtintegrering är viktigt när MAIN-grenen även integrerar ändringar från andra grenar.

2. MAIN-grenen måste innehålla kod som har klarat integreringstester så att den alltid är redo för en version.

3. Utvecklingsgrenen (eller arbetsgrenen) utvecklas ständigt eftersom teammedlemmar regelbundet checkar in ändringar.

4. Etiketter är ögonblicksbilder av filerna i en gren vid en viss tidpunkt.

   Mer information finns i Använda etiketter för att ta en ögonblicksbild av dina filer.

Med Team Foundation Build kan du välja mellan flera typer av byggen för dina grenar: manuell, kontinuerlig, gated, rullande och schemalagd. Vi rekommenderar att MAIN-grenen har en gated incheckningsversionstyp. Det innebär att utvecklingsgrenen måste uppfylla alla krav för MAIN-grenen innan du kan genomföra en omvänd integrering. Utvecklingsgrenen bör köra en kontinuerlig byggtyp eftersom ditt team måste veta så snart som möjligt när en ny incheckning påverkar utvecklingsgrenen.

Hur ofta bör ditt team omvänd integrera och integrera framåt?

Som du ser i följande bild bör omvänd integrering och vidareintegrering ske åtminstone när du slutför en användarberättelse. Även om varje team kan definiera fullständighet på olika sätt innebär slutförandet av en användarberättelse vanligtvis att du slutför både funktionerna och motsvarande enhetstester. Du kan bara återställa integreringen till MAIN-grenen efter att enhetstester har verifierat stabiliteten för utvecklingsgrenen.

Om du har fler än en arbetsgren (UTVECKLING) bör integreringen till alla arbetsgrenar ske så snart någon gren integreras i MAIN-grenen. Eftersom MAIN-grenen hålls stabil är framåtintegrering säker. Konflikter eller fel på arbetsgrenarna kan uppstå eftersom du inte kan garantera att arbetsgrenarna är stabila.

Det är viktigt att du löser alla konflikter så snart som möjligt. Genom att använda en gated check-in för MAIN-grenen hjälper du till att göra den omvända integreringen mycket enklare eftersom kvalitetsgrindar hjälper till att undvika konflikter eller fel i MAIN-grenen. Mer information finns i Checka in på en mapp som styrs av en gated incheckningsversionsprocess.

Hur hanterar ditt team källor som implementerar olika användarberättelser?

Som följande bild visar kan du checka in ändringar i en arbetsgren regelbundet för att slutföra en användarberättelse. Du kan implementera flera användarberättelser i samma gren samtidigt. Du kan dock bara återställa integreringen till MAIN-grenen när du slutför allt pågående arbete. Vi rekommenderar att du grupperar användarberättelser efter liknande storlek eftersom du inte vill att en stor användarberättelse ska blockera integreringen av många små. Du kan dela upp de två uppsättningarna användarberättelser i två grenar.

När ska teamet lägga till en gren?

Du bör skapa grenar i följande situationer:

• När du måste släppa kod enligt ett annat schema/en annan cykel än de befintliga grenarna.

• När koden kräver en annan grenprincip. Om du skapar en ny gren som har den nya principen kan du lägga till strategiskt värde i projektet.

• När funktioner släpps till en kund och ditt team planerar att göra ändringar som inte påverkar den planerade lanseringscykeln.

Du bör inte skapa en förgrening för varje användarberättelse eftersom den skapar en hög integrationskostnad. Även om TFVC gör det enkelt att förgrena sig kan omkostnaderna för att hantera grenar bli betydande om du har många grenar.

Hur hanterar teamet versioner från versionskontrollperspektivet?

Ditt team bör kunna släppa kod i slutet av alla sprintar. Genom att använda Team Foundation Server kan du märka en gren för att ta en ögonblicksbild av koden vid en viss tidpunkt. Som följande bild visar kan du märka MAIN-grenen för en version. På så sätt kan du returnera grenen till dess tillstånd i det här läget.

Eftersom du måste implementera uppdateringar på versioner hjälper skapandet av en gren för en version ditt team att fortsätta att arbeta oberoende av varandra i nästa sprint utan att skapa konflikter med framtida versioner. Följande bild visar en gren som innehåller kod för en uppdatering och som är omvänd integrerad i MAIN-grenen efter en version i slutet av den andra sprinten.

När du skapar en gren för en version bör du skapa den grenen från MAIN-grenen, som är den mest stabila. Om du förgrenar för lansering från en arbetsgren kan det orsaka integreringsutmaningar eftersom stabiliteten för arbetsgrenar inte garanteras.

Relaterade artiklar

• Välj en effektiv förgreningsstrategi