Delen via

Vertakkingsbeleid en -instellingen

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

Met vertakkingsbeleid kunnen teams hun belangrijke takken van ontwikkeling beschermen. Beleidsregels dwingen de codekwaliteits- en wijzigingsbeheerstandaarden van uw team af. In dit artikel wordt beschreven hoe u vertakkingsbeleid instelt en beheert. Zie Instellingen en beleidsregels voor Git-opslagplaatsen voor een overzicht van alle beleidsregels en instellingen voor opslagplaatsen en vertakkingen.

Een branch met vereiste policies die zijn geconfigureerd, kan niet worden verwijderd en vereist PR's voor alle wijzigingen.

Vereisten

  • Als u vertakkingsbeleid wilt instellen, moet u lid zijn van de beveiligingsgroep Projectbeheerders of moet u beleid op opslagplaatsniveau Beleidsregels bewerken machtigingen hebben. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie.

Vertakkingsbeleid configureren

Als u het vertakkingsbeleid wilt beheren, selecteert u Opslagplaatsen>Vertakkingen om de pagina Vertakkingen te openen in de webportal.

Schermopname van het menu-item Branches.

U kunt ook naar de vertakkingsbeleidsinstellingen gaan met Projectinstellingen>Repository>Beleidsregels>Vertakkingsbeleid><Vertakking Naam>.

Afdelingen met beleid tonen een beleidspictogram. U kunt het pictogram selecteren om rechtstreeks naar de instellingen van het beleid van de tak te gaan.

Als u beleid voor vertakkingen wilt instellen, zoekt u de vertakking die u wilt beheren. U kunt in de lijst bladeren of naar uw filiaal zoeken in het vak Zoeken op filiaalnaam rechtsboven.

Selecteer het pictogram Meer opties naast de branch en selecteer vervolgens Branchbeleid in het contextmenu.

Schermopname die toont hoe je het vertakkingsbeleid opent vanuit het contextmenu.

Stel beleidsregels in op de instellingenpagina van de vestiging. Zie de volgende secties voor beschrijvingen en instructies voor elk beleidstype.

Vereis een minimum aantal beoordelaars

Codebeoordelingen zijn belangrijk voor softwareontwikkelingsprojecten. Om ervoor te zorgen dat teams pull-aanvragen beoordelen en goedkeuren, kunt u goedkeuring van een minimum aantal revisoren vereisen. Het basisbeleid vereist dat een opgegeven aantal revisoren de code goedkeurt, zonder afwijzingen.

Om het beleid in te stellen, stelt u onder VertakkingsbeleidEen minimum aantal revisoren vereisen in op Aan. Voer het vereiste aantal revisoren in en selecteer een van de volgende opties:

Schermopname van het beleid Codebeoordelingen vereisen inschakelen.

  • Selecteer Aanvragers toestaan om hun eigen wijzigingen goed te keuren om de maker van een pull request toe te staan te stemmen op de goedkeuring ervan. Anders kan de maker nog steeds stemmen met Goedkeuren op de pull-aanvraag, maar hun stem telt niet mee voor het minimale aantal beoordelaars.

  • Selecteer het verbieden van de meest recente pusher om hun eigen wijzigingen goed te keuren om de scheiding van taken af te dwingen. Standaard kan iedereen met pushmachtigingen voor de bronbranch zowel commits toevoegen als stemmen op de goedkeuring van de pull request. Als u deze optie selecteert, betekent dit dat de stem van de meest recente pusher niet telt, zelfs niet als ze hun eigen wijzigingen gewoonlijk kunnen goedkeuren.

  • Selecteer Voltooiing toestaan, zelfs als sommige revisoren stemmen om te wachten of af te wijzen om pr-voltooiing toe te staan, zelfs als sommige revisoren tegen goedkeuring stemmen. Het minimale aantal revisoren moet nog steeds goedkeuring geven.

  • Onder Wanneer nieuwe wijzigingen worden gepusht:
    • Selecteer Ten minste één goedkeuring vereisen voor de laatste iteratie om ten minste één goedkeuringsstem te vereisen voor de laatste wijziging van de bronvertakking.
    • Selecteer goedkeuringsstemmen opnieuw instellen (stelt stemmen niet opnieuw in om te weigeren of te wachten) om alle goedkeuringsstemmen te verwijderen, maar houd stemmen om af te wijzen of te wachten, wanneer de bronbranch wijzigt.
    • Selecteer Alle stemmen van de coderevisor opnieuw instellen om alle revisorstemmen te verwijderen wanneer de bronbranch verandert, inclusief stemmen om goed te keuren, te weigeren of te wachten.
  • Onder Wanneer nieuwe wijzigingen worden gepusht:
    • Selecteer Ten minste één goedkeuring vereisen voor elke iteratie om ten minste één goedkeuringsstem voor de laatste wijziging van de bronvertakking te vereisen. De goedkeuring van de gebruiker wordt niet meegeteld bij een eerdere niet-goedgekeurde iteratie die door die gebruiker wordt gepusht. Als gevolg hiervan moet een andere goedkeuring voor de laatste iteratie worden uitgevoerd door een andere gebruiker. Er is ten minste één goedkeuring vereist voor elke iteratie die beschikbaar is in Azure DevOps Server 2022.1 en hoger.
    • Selecteer Ten minste één goedkeuring vereisen voor de laatste iteratie om ten minste één goedkeuringsstem te vereisen voor de laatste wijziging van de bronvertakking.
    • Selecteer Alle goedkeuringsstemmen opnieuw instellen (stelt stemmen niet opnieuw in om af te wijzen of te wachten) om alle goedkeuringsstemmen te verwijderen, maar houd stemmen om af te wijzen of te wachten, wanneer de bron-branch verandert.
    • Selecteer alle stemmen van de coderevisor opnieuw instellen om alle stemmen van de revisor te verwijderen wanneer de bronbranch verandert, inclusief stemmen voor goedkeuren, weigeren of wachten.

Als aan alle andere beleidsregels wordt voldaan, kan de maker de pull request voltooien wanneer het vereiste aantal beoordelaars deze goedkeurt.

Controleer de gekoppelde werkitems

Voor het beheer en bijhouden van werkitems kunt u verbindingen tussen PR's en werkitems vereisen. Het koppelen van werkitems biedt meer context voor wijzigingen en zorgt ervoor dat updates het traceringsproces van uw werkitems doorlopen.

Als u het beleid wilt instellen, stelt u onder VertakkingsbeleidControleren op gekoppelde werkitems in op Aan. Voor deze instelling moeten werkonderdelen worden gekoppeld aan een PR voordat de PR kan worden samengevoegd. Voer de instelling Optioneel in om te waarschuwen wanneer er geen gekoppelde werkitems zijn, maar toestaan dat de pull-aanvraag is voltooid.

Schermopname van het vereisen van gekoppelde werkitems in pull-aanvragen.

Controleren op resolutie van opmerkingen

Het beleid Controleren op oplossing van opmerkingen controleert of alle pr-opmerkingen zijn opgelost.

Configureer een oplossingsbeleid voor opmerkingen voor uw vertakking door de optie Controleren op resolutie van opmerkingen op Aan te zetten. Selecteer vervolgens of u het beleid vereist of optioneel wilt maken.

Schermopname van Controleren op resolutie van opmerkingen.

Zie Pull-aanvragen controleren voor meer informatie over het werken met opmerkingen bij pull-aanvragen.

Samenvoegtypen beperken

Azure-opslagplaatsen hebben verschillende samenvoegstrategieën en standaard zijn ze allemaal toegestaan. U kunt een consistente branch-geschiedenis onderhouden door een samenvoeg-strategie af te dwingen voor het voltooien van pull requests.

Stel Samenvoegtypen in op Aan om te beperken welke samenvoegtypen in uw Opslagplaats mogen worden toegestaan.

Schermopname van Limiteer samenvoegingstypen.

  • Met een eenvoudige samenvoeging (geen fast-forward) wordt een merge-commit gemaakt in de doelbranch waarvan de ouders de doel- en bronbranch zijn.
  • Squash merge maakt een lineaire geschiedenis met één commit in de doelbranch inclusief alle wijzigingen van de bronbranch. Meer informatie over squash-merge en hoe dit invloed heeft op de geschiedenis van takken.
  • Rebase en fast-forward maakt een lineaire geschiedenis door bron commits opnieuw toe te passen op de doelbranch zonder merge commit.
  • Rebase met merge commit plaatst de bronscommits opnieuw op het doel en maakt ook een mergecommit.

Buildvalidatie

U kunt een beleid instellen dat vereist dat wijzigingen in pull-verzoeken succesvol worden gebouwd voordat het pull-verzoek kan worden voltooid. Bouwbeleid vermindert onderbrekingen en zorgt ervoor dat uw testresultaten worden doorgegeven. Het bouwen van beleidsregels helpt zelfs als u continue integratie (CI) op uw ontwikkelvertakkingen gebruikt om problemen vroeg te ondervangen.

Met een buildvalidatiebeleid wordt een nieuwe build in de wachtrij geplaatst wanneer er een nieuwe pull request wordt aangemaakt of wanneer wijzigingen worden gepusht naar een bestaande pull request die op de vertakking gericht is. Het beleid voor builds evalueert de buildresultaten om te bepalen of de pull request kan worden voltooid.

Belangrijk

Voordat u een buildvalidatiebeleid opgeeft, zorgt u ervoor dat u een build-pijplijn hebt. Als u geen pijplijn hebt, zie Een build-pijplijn maken. Kies het type build dat overeenkomt met uw projecttype.

Een buildvalidatiebeleid toevoegen

  1. Selecteer de + button naast buildvalidatie.

    Schermopname van de knop Toevoegen naast buildvalidatie.

  2. Vul het formulier voor het instellen van het bouwbeleid in:

    Schermopname van de buildbeleidinstellingen.

    • Selecteer de build-pijplijn.

    • U kunt desgewenst een padfilter instellen. Ontdek meer over padfilters in branch-beleid.

    • Selecteer onder Trigger Automatisch (wanneer de bronbranch wordt bijgewerkt) of Handmatig.

    • Selecteer Vereist of Optioneel onder Beleidsvereiste. Als u Vereist kiest, moeten builds succesvol worden voltooid om PR's af te ronden. Kies Optioneel om een melding van de buildfout te geven, maar toch toe te staan dat PR's worden voltooid.

    • Stel een vervaldatum van een build in om ervoor te zorgen dat updates aan uw beveiligde vertakking geen problemen veroorzaken voor openstaande PR's.

      • Onmiddellijk wanneer <de naam> van de vertakking wordt bijgewerkt: met deze optie wordt de status van het buildbeleid voor pull-aanvraag ingesteld op mislukt wanneer de vertakking wordt bijgewerkt en wordt een build opnieuw in de wachtrij weergegeven. Deze instelling zorgt ervoor dat de wijzigingen in de pull request succesvol worden gebouwd, zelfs als de beveiligde vertakking wordt gewijzigd.

        Deze optie is het beste voor teams waarvan de belangrijke vertakkingen weinig wijzigingen hebben. Teams die in drukke ontwikkeltakken werken, vinden het storend om te moeten wachten op een build bij elke update van de tak.

      • Na <n> uur als <de naam> van de vertakking is bijgewerkt: deze optie verloopt de huidige beleidsstatus wanneer de beveiligde vertakking wordt bijgewerkt als de doorgegeven build ouder is dan de drempelwaarde die u invoert. Deze optie is een compromis tussen altijd of nooit een build vereisen wanneer de beschermde branch wordt bijgewerkt. Deze keuze vermindert het aantal builds wanneer uw beveiligde vertakking regelmatig updates heeft.

      • Nooit: Updates voor de beveiligde vertakking wijzigen de beleidsstatus niet. Deze waarde vermindert het aantal builds, maar kan problemen veroorzaken bij het afronden van pull requests die onlangs niet zijn bijgewerkt.

    • Voer een optionele weergavenaam in voor dit buildbeleid. Deze naam identificeert het beleid op de pagina Vertakkingsbeleid . Als u geen weergavenaam opgeeft, gebruikt het beleid de naam van de buildpipeline.

  3. Selecteer Opslaan.

Wanneer de eigenaar van de pull request wijzigingen pusht die succesvol worden gebouwd, wordt de beleidsstatus bijgewerkt.

Als u een bouwbeleid heeft van Onmiddellijk wanneer <de vertakkingsnaam> is bijgewerkt of Na <n> uur als <de vertakkingsnaam> is bijgewerkt, wordt de beleidsstatus bijgewerkt wanneer de beveiligde vertakking wordt bijgewerkt, als de vorige build niet meer geldig is.

Statuscontroles

Externe diensten kunnen de PR Status API gebruiken om gedetailleerde status te posten op uw PR's. Het vertakkingsbeleid voor aanvullende services stelt deze externe services in staat om deel te nemen aan de pull-werkstroom en beleidsvereisten vast te stellen.

Schermopname van Externe services moeten goedkeuren.

Zie Een vertakkingsbeleid configureren voor een externe service voor instructies voor het configureren van dit beleid.

Coderevisoren automatisch opnemen

U kunt automatisch revisoren toevoegen aan pull-aanvragen die bestanden wijzigen in specifieke mappen en bestanden, of aan alle pull-aanvragen in een opslagplaats.

  1. Selecteer de + knop naast Automatisch opgenomen revisoren.

    Schermopname die 'Vereiste beoordelaars toevoegen' weergeeft.

  2. Vul het scherm Nieuw revisorbeleid toevoegen in.

    Schermopname van het scherm Nieuw revisorbeleid toevoegen.

    • Voeg personen en groepen toe aan revisoren.

    • Selecteer Optioneel als u revisoren automatisch wilt toevoegen, maar hun goedkeuring niet nodig hebt om de pull-aanvraag te voltooien.

      Of selecteer Vereist als pull-aanvragen pas kunnen worden voltooid:

      • Elke persoon die als revisor wordt toegevoegd, keurt de wijzigingen goed.
      • Ten minste één persoon in elke groep die als revisor is toegevoegd, keurt de wijzigingen goed.
      • Als er slechts één groep is vereist, keurt het minimale aantal leden dat u opgeeft de wijzigingen goed.

    • Geef de bestanden en mappen op waarvoor automatisch opgenomen revisoren vereist zijn. Laat dit veld leeg om de revisoren voor alle pull-aanvragen in de vertakking te vereisen.

    • Selecteer Toestaan dat aanvragers hun eigen wijzigingen goedkeuren als eigenaren van pull-aanvragen kunnen stemmen om hun eigen pull-aanvragen goed te keuren om aan dit beleid te voldoen.

    • U kunt een activiteitsfeedbericht opgeven dat wordt weergegeven in de pull-aanvraag.

  3. Selecteer Opslaan.

Branchregels overslaan

In sommige gevallen moet u mogelijk beleidsvereisten overslaan. Met bypass-machtigingen kunt u wijzigingen rechtstreeks naar een vertakking pushen of pull-aanvragen voltooien die niet voldoen aan vertakkingsbeleid. U kunt bypassmachtigingen verlenen aan een gebruiker of groep. U kunt machtigingen voor het overslaan van een hele project, een opslagplaats of één vertakking instellen.

Met twee machtigingen kunnen gebruikers vertakkingsbeleid op verschillende manieren omzeilen:

  • Het overslaan van beleidsregels bij het afronden van pull-aanvragen is alleen van toepassing op de voltooiing ervan. Gebruikers met deze machtiging kunnen pull-aanvragen voltooien, zelfs als de pull-aanvragen niet voldoen aan beleid.

  • Beleidsregels overslaan bij het pushen is van toepassing op pushes vanuit lokale opslagplaatsen en bewerkingen die op het web zijn aangebracht. Gebruikers met deze machtiging kunnen wijzigingen rechtstreeks naar beveiligde vertakkingen pushen zonder aan beleidsvereisten te voldoen.

Schermopname met machtigingen voor het omzeilen van beleidshandhaving.

Zie Git-machtigingen voor meer informatie over het beheren van deze machtigingen.

Belangrijk

Wees voorzichtig bij het verlenen van de mogelijkheid om beleid te omzeilen, met name op het repository- en projectniveau. Beleidsregels vormen een hoeksteen van veilig en compatibel broncodebeheer.

Padfilters

Verschillende branchespecifieke beleidsregels bieden routefilters. Als een padfilter is ingesteld, is het beleid alleen van toepassing op bestanden die overeenkomen met het padfilter. Als u dit veld leeg laat, betekent dit dat het beleid van toepassing is op alle bestanden in de branch.

U kunt absolute paden opgeven (pad moet beginnen met / of een jokerteken) en jokertekens. Voorbeelden:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

U kunt meerdere paden opgeven met behulp van ; een scheidingsteken. Voorbeeld:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Paden die beginnen met ! worden uitgesloten als ze anders zouden worden opgenomen. Voorbeeld:

  • /WebApp/*;!/WebApp/Tests/* bevat alle bestanden in /WebApp behalve bestanden in /WebApp/Tests
  • !/WebApp/Tests/* specificeert geen bestanden, aangezien er eerst niets is inbegrepen

De volgorde van filters is aanzienlijk. Filters worden van links naar rechts toegepast.

Vragen en antwoorden

Kan ik wijzigingen rechtstreeks pushen naar branches die vertakkingsbeleid hebben?

U kunt geen wijzigingen pushen naar branches met vereist branchebeleid, tenzij u toestemming hebt om het branchebeleid te omzeilen. Wijzigingen in deze takken kunnen alleen worden aangebracht via pull requests. U kunt wijzigingen direct pushen naar branches met optioneel vertakkingsbeleid, als ze geen verplicht vertakkingsbeleid hebben.

Wat is automatisch aanvullen?

Pull-aanvragen naar vertakkingen waarvoor vertakkingsbeleid is geconfigureerd, hebben de knop Automatisch aanvullen instellen. Selecteer deze optie om de pull-aanvraag automatisch te voltooien zodra deze voldoet aan alle beleidsregels. Automatisch aanvullen is handig wanneer u geen problemen met uw wijzigingen verwacht.

Wanneer worden voorwaarden voor vertakkingsbeleid gecontroleerd?

Takbeleid wordt opnieuw geëvalueerd op de server wanneer eigenaren van pull requests wijzigingen pushen en wanneer beoordelaars stemmen. Als een beleid een build activeert, wordt de buildstatus ingesteld op wachten totdat de build is voltooid.

Kan ik XAML-builddefinities gebruiken in vertakkingsbeleid?

Nee, u kunt geen XAML builddefinities gebruiken in vertakkingsbeleid.

Welke jokertekens kan ik gebruiken voor vereiste coderevisoren?

Enkele sterretjes * komen overeen met een willekeurig aantal tekens, inclusief zowel schuine strepen / als backslashes \. Vraagtekens ? komen overeen met één teken.

Voorbeelden:

  • *.sql komt overeen met alle bestanden met de extensie .sql .
  • /ConsoleApplication/*komt overeen met alle bestanden onder de map ConsoleApplication.
  • /.gitattributes komt overeen met het.gitattributes*-bestand in de hoofdmap van de opslagplaats.
  • */.gitignore komt overeen met elk .gitignore-bestand in de opslagplaats.

Zijn de vereiste coderevisorpaden hoofdlettergevoelig?

Nee, vertakkingsbeleid is niet hoofdlettergevoelig.

Hoe kan ik meerdere gebruikers configureren als vereiste revisoren, maar slechts één van hen moet goedkeuren?

U kunt de gebruikers toevoegen aan een groep en vervolgens de groep toevoegen als revisor. Elk lid van de groep kan vervolgens goedkeuren om te voldoen aan de beleidsvereiste.

Ik heb beleidstoestemmingen omzeild. Waarom zie ik nog steeds beleidsfouten in de status van de pull-aanvraag?

Geconfigureerde beleidsregels worden altijd geëvalueerd voor wijzigingen in pull-aanvragen. Voor gebruikers die beleidsmachtigingen omzeilen, is de gerapporteerde beleidsstatus alleen advies. Als de gebruiker met bypassmachtigingen goedkeurt, blokkeert de foutstatus de voltooiing van pull-aanvragen niet.

Waarom kan ik mijn eigen pull-aanvragen niet afronden wanneer 'Aanvragers toestaan hun eigen wijzigingen goed te keuren' is ingesteld?

Zowel het beleid voor het vereiste minimum aantal revisoren als het beleid voor automatisch opgenomen revisoren hebben opties om aanvragers toe te staan hun eigen wijzigingen goed te keuren. In elk beleid is de instelling alleen van toepassing op dat beleid. De instelling heeft geen invloed op het andere beleid.

Uw pull-aanvraag heeft bijvoorbeeld de volgende beleidsregels ingesteld:

  • Voor een minimum aantal revisoren is ten minste één revisor vereist.
  • Automatisch opgenomen reviewers vereisen dat u of een team waarin u zit als reviewer optreedt.
  • Revisoren die automatisch zijn opgenomen, hebben toestaan dat aanvragers hun eigen wijzigingen goedkeuren.
  • Het vereisen van een minimum aantal beoordelaars heeft niet de optie toestaan dat aanvragers hun eigen wijzigingen goedkeuren ingeschakeld.

In dit geval voldoet uw goedkeuring aan automatisch opgenomen beoordelaars, maar niet aan een minimum aantal beoordelaars, waardoor u de pull-aanvraag niet kunt voltooien.

Er kunnen ook andere beleidsregels zijn, zoals verbieden dat de meest recente pusher hun eigen wijzigingen goedkeurt, waardoor u uw eigen wijzigingen niet kunt goedkeuren, zelfs als aanvragers toestaan om hun eigen wijzigingen goed te keuren, is ingesteld.

Wat gebeurt er wanneer het pad in padfilters niet begint met / of met een jokerteken?

Het pad in padfilters die niet beginnen met / of met een jokerteken heeft geen effect en het padfilter evalueert alsof dat pad niet is opgegeven. Een dergelijk pad kan niet overeenkomen met het / absolute bestandspad dat begint met.