Välj en effektiv förgreningsstrategi

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

Det är användbart att skapa grenar för dina TFVC-lagringsplatser (Team Foundation Version Control) för att isolera risker. Tänk på några utmaningar som teammedlemmar vanligtvis står inför när de arbetar med ett programvaruprojekt som är bemannat av mer än fem eller tio personer:

• Gruppen har några (eller kanske flera) olika funktionsteam, var och en arbetar med en uppsättning funktioner som är ganska diskreta. Men varje team är också beroende av funktioner som skapats av andra team. Du måste isolera risken för de ändringar som introduceras av det arbete som utförts i vart och ett av dessa team, men så småningom måste du sammanfoga alla deras ansträngningar till en enda produkt.

• Testteamet behöver en stabil version av koden för att testa, men samtidigt måste utvecklarna fortsätta att gå vidare med nya funktioner som ibland destabiliserar produkten.

• Programvaran har två tidigare versioner och en aktuell version pågår. Även om det mesta av utvecklingsinsatsen investeras i den aktuella versionen, måste de tidigare versionerna fortfarande stödjas med tillfälliga versioner av Service Pack, kritiska korrigeringar och säkerhetskorrigeringar och andra ändringar.

I den här artikeln beskrivs några vanliga förgreningsstrategier som hjälper dig att fatta rätt beslut.

Till skillnad från Git-grenar, som är begränsade till lagringsplatsen, är TFVC-grenar sökvägsomfång och inte lika lätta. Ange fältet för att skapa grenar med hög och enda gren när du behöver kod- eller versionsisolering.

Endast huvud

Main Only-strategin kan vara mappbaserad eller med huvudmappen konverterad till en gren för att aktivera ytterligare synlighetsfunktioner. Du checkar in ändringarna i huvudgrenen och kan också ange milstolpar för utveckling och lansering med etiketter.

RISK: Föränderlighet och brist på historik med TFVC-etiketter kan öka risken för ändringskontroll.

Börja med den huvudsakliga enda förgreningsstrategin, förgrena strategiskt och anta andra strategier för att utvecklas till mer komplexa strategier efter behov.

Utvecklingsisolering

När du behöver underhålla och skydda en stabil huvudgren kan du förgrena en eller flera utvecklingsgrenar från huvudgrenen. Det möjliggör isolering och samtidig utveckling. Arbetet kan isoleras i utvecklingsgrenar efter funktion, organisation eller tillfälligt samarbete.

Det är möjligt att det finns ändringar i huvudgrenen. Vidarebefordra alltid huvudintegren (FI) till utvecklingsgrenen och lös sammanslagningskonflikter. Sedan ändras omvänd integrering (RI) tillbaka till main. Behåll samma kvalitetsfält mellan grenar. Skapa och köra verifieringstester (BVT) på dev på samma sätt som du gör på main.

Obs! Med den här strategin kommer team sannolikt att behålla utvecklingsgrenen för alltid, vilket potentiellt skapar en stor sammanslagningsbiljetthistorik.

Funktionsisolering

Funktionsisolering är en särskild härledning av utvecklingsisoleringen, så att du kan förgrena en eller flera funktionsgrenar från huvudgrenarna, som du ser eller från dina utvecklingsgrenar .

När du behöver arbeta med en viss funktion kan det vara en bra idé att skapa en funktionsgren.

Håll livslängden för funktionsarbete och tillhörande funktionsgren kortlivad. Vidarebefordra integreringsändringar (FI) från den överordnade grenen ofta. Omvänd integrering (RI) tillbaka till den överordnade endast när vissa överenskomna teamkriterier, till exempel definition av gjort, uppfylls. Återställning av funktioner på huvudsidan kan vara kostsamt och kan återställa testningen.

Versionsisolering

Versionsisolering introducerar en eller flera versionsgrenar från main. Strategin möjliggör samtidig versionshantering, flera och parallella versioner och ögonblicksbilder av codebase vid lanseringstillfället.

När versionen är redo att låsas är det dags att skapa en ny gren för versionen.

Vidarebefordra aldrig integrera (FI) från main. Lås versionsgrenar med åtkomstbehörigheter för att förhindra oavsiktliga ändringar i en version. Korrigeringar och snabbkorrigeringar som görs i versionsgrenen kan vara bakåtintegrerade (RI) tillbaka till huvudgrenen.

Obs! Inget av förgreningsscenarierna är oföränderliga, vilket är anledningen till att du märker att snabbkorrigeringar för nödsituationer utförs på versionsgrenar. Utveckla varje strategi för att matcha dina krav, utan att förlora komplexitet och tillhörande kostnader ur sikte.

Service- och versionsisolering

Service- och versionsisoleringsstrategin introducerar servicegrenar . Den här strategin möjliggör samtidig tjänsthantering av servicepaket och ögonblicksbilder av kodbaser vid lanseringstillfället.

Använd den här strategin om du behöver en servicemodell för kunder för att uppgradera till nästa större version och ytterligare servicepaket per version.

Precis som versionsisoleringen skapas underhållsisoleringen och versionsgrenarna när versionen är redo att låsas. Vidarebefordra aldrig integrering från huvud - till service eller från service till lansering. Lås versionsgrenen för att förhindra ändringar. Framtida serviceändringar kan göras på servicegrenen.

Skapa nya service- och versionsgrenar för efterföljande versioner om du behöver den isoleringsnivån.

Service, snabbkorrigering, versionsisolering

Även om det inte rekommenderas kan du fortsätta att utveckla strategierna genom att introducera ytterligare snabbkorrigeringsgrenar och tillhörande versionsscenarier.

Nu har du utforskat några av de vanliga TFVC-förgreningsscenarierna. Du kan utveckla dem eller undersöka andra strategier, till exempel funktionsväxling, växla funktioner till och från för att avgöra om en funktion är tillgänglig vid körning.

Frågor och svar

Varför ska grenar vara kortlivade?

Genom att hålla grenar kortlivade hålls sammanslagningskonflikter till så få som möjligt.

Varför bara gren om det behövs?

För att kunna använda DevOps måste du förlita dig på automatisering av bygge, testning och distribution. Ändringar är kontinuerliga, frekventa och sammanslagningsåtgärder som är mer utmanande eftersom sammanslagningskonflikter ofta kräver manuella åtgärder. Vi rekommenderar därför att du undviker förgrening och förlitar dig på andra strategier, till exempel funktionsväxling.

Varför ta bort grenar?

Målet bör vara att få tillbaka ändringarna till huvuddelen så snart som möjligt för att minimera långsiktiga sammanslagningskonsekvenser. Tillfälliga, oanvända och rikliga grenar orsakar förvirring och omkostnader för teamet.

Kan en kodbas förgrenas mellan projekt?

Ja. Det rekommenderas inte, såvida inte teamen måste dela källan och inte kan dela en gemensam process.

Hur är det med kodhöjningsstrategin?

Code Promotion-strategin känns som en relik från vattenfallsutvecklingstiden. Det är vanligtvis med långa testcykler och separata utvecklings- och testteam. Strategin rekommenderas inte längre. Mer information om den här strategin finns i vägledningen för förgrening.

Varför identifieras inga ändringar när dev slås samman till huvudgrenen?

Du har förmodligen ignorerat ändringar i tidigare sammanslagningar, till exempel med hjälp av konfliktlösningsalternativet keep source . Mer information finns i Slå samman utvecklingsgrenen till huvudgrenen: det fanns inga ändringar att sammanfoga .

Finns det likheter mellan TFVC- och Git-grenstrategier?

Förgreningsstrategin för TFVC-funktionsisolering liknar grengrenarna för Git-ämnet.

Författare: Jesse Houwing, Marcus Fernandez, Mike Fourie och Willy Schaub från ALM | DevOps Rangers. Du kan kontakta dem här.

(c) 2015 Microsoft Corporation. Med ensamrätt. Det här dokumentet tillhandahålls "i den mån det är". Information och vyer som uttrycks i det här dokumentet, inklusive URL och andra webbplatsreferenser, kan ändras utan föregående meddelande. Användande sker på egen risk.

Det här dokumentet ger dig inga juridiska rättigheter till någon immateriell rättighet i någon Microsoft-produkt. Du får kopiera och använda det här dokumentet som referens för interna syften.