Dela via

Skapa flera grenar i Azure Pipelines

  • Artikel

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

Med Hjälp av Azure Pipelines kan du skapa utlösare för att skapa projektet vid varje ny inchecknings- och pull-begäran till lagringsplatsen. 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. Följande kodfragment lägger till exempel till ett villkor för uppgiften 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 principer som kräver lyckade byggen innan du sammanfogar pull-begäranden. 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-utlösare i YAML-filen aktiveras pull-begärandeversioner som standard för alla grenar. Du har dock flexibiliteten att ange målgrenarna för dina pull-begärandeversioner. 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 Lagringsplatser och välj sedan Grenar.

  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 princip som körs just nu.

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

Kommentar

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