Een effectieve vertakkingsstrategie selecteren

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

Het maken van vertakkingen voor uw TFVC-opslagplaatsen (Team Foundation Version Control) is handig om risico's te isoleren. Houd rekening met enkele uitdagingen waarmee teamleden meestal te maken krijgen wanneer ze aan een softwareproject werken dat wordt bemand door meer dan vijf of tien personen:

• De groep heeft een paar (of misschien meerdere) verschillende functieteams, die elk werken aan een set functionaliteit die redelijk discreet is. Maar elk team is ook afhankelijk van de functionaliteit die door andere teams is gebouwd. U moet het risico isoleren van de wijzigingen die worden geïntroduceerd door het werk dat in elk van deze teams wordt uitgevoerd, en toch moet u uiteindelijk al hun inspanningen samenvoegen tot één product.

• Het testteam heeft een stabiele versie van de code nodig om te testen en toch tegelijkertijd moeten de ontwikkelaars doorgaan met nieuwe functies die het product af en toe zullen stabiliseren.

• De software heeft twee eerdere versies en één huidige versie die wordt uitgevoerd. Hoewel de meeste ontwikkelingsinspanningen worden geïnvesteerd in de huidige versie, moeten de vorige versies nog steeds worden ondersteund met incidentele releases van servicepacks, kritieke oplossingen en beveiligingspatches en andere wijzigingen.

In dit artikel worden enkele veelvoorkomende vertakkingsstrategieën besproken om u te helpen bij het nemen van de juiste beslissing.

In tegenstelling tot Git-vertakkingen, die opslagplaatsbereik hebben, zijn TFVC-vertakkingen een padbereik en niet zo licht. Stel uw balk in voor het maken van vertakkingen hoog en alleen vertakkingen wanneer u code of release-isolatie nodig hebt.

Alleen hoofd

De strategie Alleen-hoofd kan worden gebaseerd op mappen of met de hoofdmapdie is geconverteerd naar een vertakking, om extra zichtbaarheidsfuncties in te schakelen. U brengt uw wijzigingen door in de hoofdbranch en geeft eventueel mijlpalen voor ontwikkeling en release aan met labels.

RISICO: De mutabiliteit en het ontbreken van geschiedenis met TFVC-labels kunnen het risico van wijzigingsbeheer toevoegen.

Begin met de belangrijkste vertakkingsstrategie, vertakking strategisch en adopteer andere strategieën om naar behoefte complexere strategieën te ontwikkelen.

Isolatie van ontwikkeling

Wanneer u een stabiele hoofdbranch wilt onderhouden en beveiligen, kunt u een of meer dev-vertakkingen vertakken van het hoofd. Het maakt isolatie en gelijktijdige ontwikkeling mogelijk. Werk kan worden geïsoleerd in ontwikkelingsbranches per functie, organisatie of tijdelijke samenwerking.

Het is mogelijk dat er wijzigingen zijn in de hoofdbranch . Integreer (FI) altijd door naar de dev-vertakking en los samenvoegingsconflicten op. Vervolgens keert u wijzigingen (RI) terug naar de hoofdmap. Behoud dezelfde kwaliteitsbalk tussen vertakkingen. Bouw en voer testtests voor buildverificatie (BVTs) op dezelfde manier uit als op de belangrijkste manier.

OPMERKING: Met deze strategie houden teams waarschijnlijk de dev-vertakking voor altijd bij, waardoor mogelijk een grote samenvoegingsticketgeschiedenis wordt opgebouwd.

Functie-isolatie

Functie-isolatie is een speciale afleiding van de ontwikkelingsisolatie, zodat u een of meer functievertakkingen kunt vertakken van hoofdvertakkingen, zoals wordt weergegeven of vanuit uw ontwikkelvertakkingen .

Wanneer u aan een bepaalde functie moet werken, is het misschien een goed idee om een functiebranch te maken.

Houd de levensduur van het functiewerk en de bijbehorende functievertakking kortlevend. Integreer (FI)-wijzigingen van de bovenliggende vertakking regelmatig. Omgekeerde integratie (RI) alleen terug naar het bovenliggende item wanneer aan bepaalde overeengekomen teamcriteria, bijvoorbeeld definitie van gereed, wordt voldaan. Het terugdraaien van functies op het hoofd kan kostbaar zijn en kan testen opnieuw instellen.

Isolatie vrijgeven

Release-isolatie introduceert een of meer release-vertakkingen van het hoofd. De strategie maakt gelijktijdig releasebeheer, meerdere en parallelle releases en momentopnamen van codebase mogelijk tijdens de release.

Wanneer de release klaar is om te worden vergrendeld, is het tijd om een nieuwe vertakking voor de release te maken.

Nooit doorsturen integreren (FI) vanuit de hoofdmap. Vertakkingen van release vergrendelen met behulp van toegangsmachtigingen om onbedoelde wijzigingen in een release te voorkomen. Patches en hot fixes die zijn aangebracht in de releasebranch kunnen terug worden omgekeerd geïntegreerd (RI) naar de hoofdbranch .

OPMERKING: Geen van de vertakkingsscenario's kan onveranderbaar zijn. Daarom ziet u dat hotfixes voor noodgevallen worden uitgevoerd op releasevertakkingen. Ontwikkel elke strategie om aan uw vereisten te voldoen, zonder verlies van complexiteit en bijbehorende kosten.

Isolatie van onderhoud en release

De strategie voor onderhouds- en releaseisolatie introduceert onderhoudsbranches . Met deze strategie kunt u gelijktijdig servicebeheer van servicepacks en momentopnamen van codebasis op releasetijd.

Gebruik deze strategie als u een onderhoudsmodel nodig hebt voor klanten om een upgrade uit te voeren naar de volgende grote release en extra servicepacks per release.

Net als bij de release-isolatie worden de onderhoudsisolatie en release-vertakkingen gemaakt wanneer de release gereed is om te worden vergrendeld. Integreer nooit van hoofd naar onderhoud of van onderhoud tot release. Vergrendel de releasebranch om wijzigingen te voorkomen. Toekomstige onderhoudswijzigingen kunnen worden aangebracht in de onderhoudsbranch .

Maak nieuwe service- en releasebranches voor volgende releases als u dat isolatieniveau nodig hebt.

Onderhoud, hotfix, release-isolatie

Hoewel dit niet wordt aanbevolen, kunt u de strategieën blijven ontwikkelen door aanvullende hotfix-vertakkingen en bijbehorende releasescenario's te introduceren.

Op dit moment hebt u een aantal veelvoorkomende TFVC-vertakkingsscenario's verkend. U kunt deze ontwikkelen of andere strategieën onderzoeken, zoals het in- en uitschakelen van functies, om te bepalen of een functie beschikbaar is tijdens runtime.

V&A

Waarom zouden vertakkingen kortlevend moeten zijn?

Door vertakkingen kort te houden, worden samenvoegingsconflicten zo min mogelijk bewaard.

Waarom alleen vertakking indien nodig?

Als u DevOps wilt omarmen, moet u vertrouwen op automatisering van build, test en implementatie. Wijzigingen zijn doorlopende, frequente en samenvoegbewerkingen lastiger omdat samenvoegingsconflicten vaak handmatige tussenkomst vereisen. Het wordt daarom aanbevolen om vertakkingen te voorkomen en te vertrouwen op andere strategieën, zoals het in-/uitschakelen van functies.

Waarom vertakkingen verwijderen?

Het doel is om zo snel mogelijk wijzigingen terug te krijgen in het hoofd , om de gevolgen van samenvoeging op lange termijn te beperken. Tijdelijke, ongebruikte en overvloedige vertakkingen veroorzaken verwarring en overhead voor het team.

Kan een codebase worden vertakt tussen projecten?

Ja. Het wordt niet aanbevolen, tenzij teams de bron moeten delen en geen gemeenschappelijk proces kunnen delen.

Hoe zit het met de strategie voor codepromotie?

De codepromotiestrategie voelt als een relic uit het watervalontwikkelingstijdperk. Het is meestal met lange testcycli en afzonderlijke ontwikkel- en testteams. De strategie wordt niet meer aanbevolen. Zie de vertakkingsrichtlijnen voor meer informatie over deze strategie.

Waarom worden er geen wijzigingen gedetecteerd bij het samenvoegen van dev naar de hoofdbranch ?

U hebt waarschijnlijk wijzigingen in eerdere samenvoegingen genegeerd, bijvoorbeeld met behulp van de keep source optie voor conflictoplossing. Zie het samenvoegen van de ontwikkelingsbranch naar het hoofd: er zijn geen wijzigingen aangebracht om samen te voegen voor meer informatie.

Zijn er overeenkomsten tussen TFVC- en Git-vertakkingsstrategieën?

De vertakkingsstrategie voor TFVC-functieisolatie is vergelijkbaar met de Git-onderwerpvertakkingen.

Auteurs: Jesse Houwing, Marcus Overzetten, Mike Fourie en Willy Schaub van de ALM | DevOps Rangers. U kunt hier contact met hen opnemen.

c) 2015 Microsoft Corporation. Alle rechten voorbehouden. Dit document wordt 'as-is' opgegeven. Informatie en weergaven die in dit document worden uitgedrukt, met inbegrip van URL's en andere internetwebsiteverwijzingen, kunnen zonder kennisgeving worden gewijzigd. U gebruikt deze op eigen risico.

Aan dit document kunt u geen enkel wettelijk recht ontlenen op enige intellectuele eigendom van een Microsoft-product. U mag dit document kopiëren en gebruiken voor uw eigen referentiedoeleinden.