Strategisch vertakking

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Broncode is een belangrijke asset in uw ontwikkelingsinspanning. Het kan echter een uitdaging zijn om bronbestanden effectief te beheren en te ontwikkelen wanneer meerdere ontwikkelaars gelijktijdig aan bestandsupdates werken. U kunt een versiebeheersysteem gebruiken om broncode op te slaan in gedeelde opslagplaatsen, om parallelle ontwikkelingsinspanningen te isoleren, codewijzigingen te integreren en eerdere bestandsversies te herstellen. Een belangrijk element in versiebeheer is vertakking die gelijktijdige ontwikkeling mogelijk maakt. Als u strategisch vertakt, kunt u de volgorde en consistentie van meerdere versies van uw software behouden.

Team Foundation biedt een flexibel en betrouwbaar versiebeheersysteem. U kunt Versiebeheer van Team Foundation gebruiken om meerdere revisies te beheren tijdens het ontwikkelen van broncode, documenten, werkitems en andere essentiële informatie waaraan uw team heeft gewerkt.

Hoe beheert uw team code terwijl er meerdere wijzigingen tegelijk worden geïntroduceerd via verschillende projectreleases?

Wanneer u met een versiebeheersysteem werkt, moet u overwegen hoe u een vertakkingsstructuur instelt. U kunt een vertakking maken door het broncodebestand te spiegelen. Vervolgens kunt u de vertakking wijzigen zonder dat dit van invloed is op de bron. Zoals bijvoorbeeld de vertakkingsstructuur in de volgende afbeelding laat zien, bevat de MAIN-vertakking de voltooide functionaliteit die is geslaagd voor integratietests en bevat de DEVELOPMENT-vertakking de code die in aanbouw is. Wanneer een nieuwe functionaliteit in de DEVELOPMENT-vertakking is voltooid en integratietests kan worden uitgevoerd, kunt u de code van de DEVELOPMENT-vertakking naar de MAIN-vertakking promoveren. Dit proces wordt omgekeerde integratie genoemd. Als u daarentegen de code van de MAIN-vertakking samenvoegt met de ONTWIKKELINGSbranch, wordt het proces ook wel doorsturende integratie genoemd.

Zie de volgende pagina op de CodePlex-website: Team Foundation Server Branching Guide 2.0 voor meer informatie over het maken en samenvoegen van codevertakkingen.

Vertakking en samenvoeging omvatten de volgende principes:

1. Elke vertakking moet een gedefinieerd beleid hebben over het integreren van code in deze vertakking. In de vertakkingsstructuur van de vorige afbeelding kunt u bijvoorbeeld een teamlid toewijzen aan de eigenaar en het beheer van de MAIN-vertakking. Dit lid is verantwoordelijk voor het uitvoeren van de eerste vertakkingsbewerking, het reverse integreren van wijzigingen van de DEVELOPMENT-vertakking naar de MAIN-vertakking en het doorsturen van wijzigingen van de MAIN-vertakking naar de DEVELOPMENT-vertakking. Vooruitintegratie is belangrijk wanneer de MAIN-vertakking ook wijzigingen van andere vertakkingen integreert.

2. De MAIN-vertakking moet code bevatten die is geslaagd voor integratietests, zodat deze altijd gereed is voor een release.

3. De branch DEVELOPMENT (of work) ontwikkelt zich voortdurend omdat teamleden regelmatig wijzigingen inchecken.

4. Labels zijn momentopnamen van de bestanden in een vertakking op een bepaald tijdstip.

   Zie Labels gebruiken om een momentopname van uw bestanden te maken voor meer informatie.

Met Team Foundation Build kunt u kiezen uit verschillende soorten builds voor uw vertakkingen: handmatig, doorlopend, gated, rolling en gepland. Het is raadzaam dat de MAIN-vertakking een gated check-in buildtype heeft. Dit betekent dat de DEVELOPMENT-vertakking aan alle vereisten voor de MAIN-vertakking moet voldoen voordat u een omgekeerde integratie kunt doorvoeren. De DEVELOPMENT-vertakking moet een doorlopend buildtype uitvoeren, omdat uw team zo snel mogelijk moet weten wanneer een nieuwe check-in van invloed is op de DEVELOPMENT-vertakking.

Hoe vaak moet uw team omgekeerd integreren en doorsturen?

Zoals wordt weergegeven in de volgende afbeelding, moet omgekeerde integratie en voorwaartse integratie ten minste plaatsvinden wanneer u een gebruikersverhaal voltooit. Hoewel elk team volledigheid anders kan definiëren, betekent voltooiing van een gebruikersverhaal over het algemeen dat u zowel de functionaliteit als de bijbehorende eenheidstests voltooit. U kunt integratie met de MAIN-vertakking pas ongedaan maken nadat eenheidstests de stabiliteit van de ONTWIKKELINGSbranch hebben gecontroleerd.

Als u meer dan één werkbranch (DEVELOPMENT) hebt, moet de integratie doorsturen naar alle werkbranches plaatsvinden zodra een vertakking in de MAIN-vertakking is geïntegreerd. Omdat de MAIN-vertakking stabiel blijft, is voorwaartse integratie veilig. Conflicten of fouten in de werkvertakkingen kunnen optreden omdat u niet kunt garanderen dat de werkvertakkingen stabiel zijn.

Het is belangrijk dat u alle conflicten zo snel mogelijk oplost. Door een gated check-in te gebruiken voor de MAIN-vertakking, kunt u de omgekeerde integratie veel eenvoudiger maken, omdat kwaliteitspoorten helpen conflicten of fouten in de MAIN-vertakking te voorkomen. Zie Inchecken in een map die wordt beheerd door een gated check-in buildproces voor meer informatie.

Hoe beheert uw team bronnen die verschillende gebruikersverhalen implementeren?

Zoals in de volgende afbeelding wordt weergegeven, kunt u regelmatig wijzigingen in een werkbranch inchecken om een gebruikersverhaal te voltooien. U kunt meerdere gebruikersverhalen tegelijkertijd in dezelfde vertakking implementeren. U kunt de integratie echter alleen omkeren naar de MAIN-vertakking wanneer u alle actieve werkzaamheden voltooit. Het wordt aanbevolen om gebruikersverhalen op vergelijkbare grootte te groeperen, omdat u niet wilt dat een groot gebruikersverhaal de integratie van veel kleine artikelen blokkeert. U kunt de twee sets gebruikersverhalen splitsen in twee vertakkingen.

Wanneer moet het team een vertakking toevoegen?

In de volgende situaties moet u vertakkingen maken:

• Wanneer u code op een andere planning/cyclus moet vrijgeven dan de bestaande vertakkingen.

• Wanneer uw code een ander vertakkingsbeleid vereist. Als u een nieuwe vertakking met het nieuwe beleid maakt, kunt u strategische waarde toevoegen aan uw project.

• Wanneer de functionaliteit wordt vrijgegeven aan een klant en uw team van plan is wijzigingen aan te brengen die niet van invloed zijn op de geplande releasecyclus.

U moet geen vertakking maken voor elk gebruikersverhaal, omdat hiermee hoge integratiekosten worden gemaakt. Hoewel TFVC vertakkingen eenvoudig maakt, kan de overhead van het beheren van vertakkingen aanzienlijk worden als u veel vertakkingen hebt.

Hoe beheert het team releases vanuit het perspectief van versiebeheer?

Uw team moet code kunnen vrijgeven aan het einde van elke sprint. Met Behulp van Team Foundation Server kunt u een vertakking labelen om een momentopname van de code op een bepaald moment te maken. Zoals in de volgende afbeelding wordt weergegeven, kunt u de MAIN-vertakking labelen voor een release. Hiermee kunt u de vertakking op dit moment terugsturen naar de status.

Omdat u updates voor releases moet implementeren, helpt het maken van een vertakking voor een release uw team onafhankelijk te blijven werken op de volgende sprint zonder conflicten met toekomstige releases te creëren. In de volgende afbeelding ziet u een vertakking die code bevat voor een update en die is omgekeerd in de MAIN-vertakking na een release aan het einde van de tweede sprint.

Wanneer u een vertakking maakt voor een release, moet u die vertakking maken van de MAIN-vertakking, wat het stabielst is. Als u vertakking voor vrijgave van een werkbranch vertakt, kan dit integratieproblemen veroorzaken omdat de stabiliteit van werkbranches niet wordt gegarandeerd.

Verwante artikelen:

• Een effectieve vertakkingsstrategie selecteren