Dela via

Skapa flera grenar i Azure Pipelines

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Med hjälp av Azure Pipelines kan du skapa utlösare för att bygga ditt projekt vid varje ny commit och pull-förfrågan till arkivet. I den här artikeln får du lära dig hur du aktiverar kontinuerlig integrering och konfigurerar flera grenversioner för din lagringsplats.

Förutsättningar

Aktivera CI-utlösare för en ämnesgren

När du arbetar med Git är det vanligt att skapa tillfälliga grenar från huvudgrenen för att underlätta ett effektiviserat arbetsflöde. Dessa grenar, som ofta kallas ämnes- eller funktionsgrenar, tjänar syftet med att isolera ditt arbete. I det här arbetsflödet skapar du en gren som är dedikerad till en specifik funktion eller buggkorrigering, och när den är klar sammanfogar du koden tillbaka till huvudgrenen innan du tar bort ämnesgrenen.

Om ingen utlösare uttryckligen anges i YAML-filen utlöser alla ändringar som görs i en gren en körning. Om du vill lägga till utlösare för både huvudgrenen och alla funktioner/ grenar inkluderar du följande kodfragment i YAML-filen. Detta säkerställer att alla ändringar som görs i dessa grenar automatiskt utlöser en pipelinekörning.

trigger:
- main
- feature/*

YAML-versioner är ännu inte tillgängliga på TFS.

Anpassa bygguppgifter baserat på grenen som skapas

Huvudgrenen ansvarar vanligtvis för att generera distributionsbara artefakter, till exempel binärfiler. För kortlivade funktionsgrenar behöver du inte investera tid på att skapa och lagra dessa artefakter. I Azure Pipelines kan du implementera anpassade villkor för att säkerställa att specifika uppgifter endast körs på huvudgrenen.

Redigera azure-pipelines.yml-filen i huvudgrenen och lägg till ett villkor i önskad uppgift. Till exempel lägger följande kodfragment till ett villkor för aktiviteten publicera pipelineartefakter.

- task: PublishPipelineArtifact@1
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

YAML-versioner är ännu inte tillgängliga på TFS.

Verifiera pull-begäranden

För att säkerställa grenskydd kan du använda policyer som kräver lyckade byggen innan du slår samman pull-förfrågningar. Med Hjälp av Azure Pipelines har du flexibiliteten att konfigurera kravet på en ny lyckad version för sammanslagning av ändringar i viktiga grenar som huvudgrenen.

GitHub-lagringsplats

Om du inte uttryckligen definierar pr-trigger i YAML-filen aktiveras pull request-byggningar som standard för alla grenar. Du har dock flexibiliteten att ange målgrenarna för byggena av dina pull-begäranden. Om du till exempel vill köra bygget exklusivt för pull-begäranden som riktar sig till huvudgrenen och grenarna som börjar med funktionen/, kan du ange följande konfiguration:

pr:
- main
- feature/*

YAML-versioner är ännu inte tillgängliga på TFS.

Lagringsplats för Azure Repos

  1. Logga in på din Azure DevOps-organisation och navigera sedan till projektet.

  2. Välj Repo och välj sedan Brancher.

  3. Välj ellipsikonen till höger om grennamnet och välj sedan Grenprinciper.

  4. Under menyn Skapa validering väljer du +-tecknet för att lägga till en byggprincip.

  5. Välj din Build-pipeline på den nedrullningsbara menyn och se till att Utlösaren är inställd på automatisk och att principkravet är inställt på obligatoriskt.

  6. Ange ett beskrivande visningsnamn för att beskriva principen.

  7. Välj Spara för att skapa och aktivera principen. Välj Spara ändringar längst upp till vänster på skärmen för att spara ändringarna.

En skärmbild som visar hur du lägger till en ny byggprincip.

  1. Om du vill testa principen navigerar du till Repos>Pull-begäranden i Azure DevOps-portalen.

  2. Välj Ny pull-begäran och se till att ämnesgrenen är inställd på att sammanfogas till huvudgrenen och välj sedan Skapa.

  3. På skärmen kan du se den policy som körs just nu.

  4. Välj policynamnet för att undersöka kompileringen. Om bygget lyckas sammanfogas pull-begäran. Om bygget misslyckas blockeras sammanfogningen.

Anmärkning

Azure Pipelines stöder inte längre principer för kvarhållning per pipeline. Vi rekommenderar att du använder kvarhållningsregler på projektnivå.