Klassiska versionspipelines

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

Klassiska versionspipelines ger utvecklare ett ramverk för att distribuera program till flera miljöer effektivt och säkert. Med hjälp av klassiska versionspipelines kan du automatisera testnings- och distributionsprocesser, konfigurera flexibla distributionsstrategier, införliva arbetsflöden för godkännande och säkerställa smidiga programövergångar i olika steg.

Så här fungerar versionspipelines

Som en del av varje distribution utför Azure Pipelines följande steg:

1. Godkännande före distribution:

   När en ny distributionsbegäran utlöses verifierar Azure Pipelines om ett förhandsdistributionsgodkännande krävs innan du distribuerar en version till en fas. Om godkännande krävs skickar det e-postaviseringar till relevanta godkännare.

2. Ködistributionsjobb:

   Azure Pipelines schemalägger distributionsjobbet på en tillgänglig agent.

3. Agentval:

   En tillgänglig agent hämtar distributionsjobbet. En versionspipeline kan konfigureras för att dynamiskt välja en lämplig agent under körningen.

4. Ladda ned artefakter:

   Agenten hämtar och laddar ned alla artefakter som anges i versionen.

5. Kör distributionsuppgifterna:

   Agenten kör alla uppgifter i distributionsjobbet.

6. Generera förloppsloggar:

   Agenten genererar omfattande loggar för varje distributionssteg och skickar tillbaka dem till Azure Pipelines.

7. Godkännande efter distributionen:

   När distributionen till en fas är klar verifierar Azure Pipelines om ett godkännande efter distributionen är nödvändigt för just den fasen. Om inget godkännande behövs, eller när ett obligatoriskt godkännande har erhållits, fortsätter det att initiera distributionen till nästa steg.

Distributionsmodell

Azure-versionspipelines stöder en mängd olika artefaktkällor , inklusive Jenkins, Azure Artifacts och Team City. I följande exempel visas en distributionsmodell med hjälp av Azure-versionspipelines:

I följande exempel består pipelinen av två byggartefakter som kommer från separata byggpipelines. Programmet distribueras först till Utvecklingssteget och sedan till två separata QA-steg. Om distributionen lyckas i båda QA-faserna distribueras programmet till Prod ring 1 och sedan till Prod ring 2. Varje produktionsring representerar flera instanser av samma webbapp som distribueras till olika platser över hela världen.

Vanliga frågor

F: Hur kan jag redigera variabler vid lanseringstillfället?

S: På fliken Variabler i versionspipelinen markerar du kryssrutan Settable at release time för de variabler som du vill ändra när en version placeras i kö.

När du genererar en ny version kan du sedan ändra värdena för dessa variabler.

F: När skulle det vara lämpligare att ändra en version i stället för den pipeline som definierar den?

S: Du kan redigera godkännanden, uppgifter och variabler för en versionsinstans. Dessa ändringar gäller dock endast för den instansen. Om du vill att ändringarna ska gälla för alla framtida versioner redigerar du versionspipelinen i stället.

F: Vilka är de scenarier där funktionen "överge en version" är användbar?

S: Om du inte planerar att återanvända versionen eller vill förhindra att den används kan du avbryta versionen enligt följande Pipelines> (...) >Överge. Du kan inte avbryta en version när en distribution pågår. Du måste avbryta distributionen först.

F: Hur gör jag för att hantera namngivning av nya versioner?

S: Standardnamngivningskonventionen för versionspipelines är sekventiell numrering, där versionerna heter Release-1, Release-2 och så vidare. Du har dock flexibiliteten att anpassa namngivningsschemat genom att ändra versionsnamnformatmasken. På fliken Alternativ i versionspipelinen går du till sidan Allmänt och justerar egenskapen Versionsnamnformat så att den passar dina inställningar.

När du anger formatmasken kan du använda följande fördefinierade variabler. Exempel: Följande versionsnamnsformat: Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName) skapar följande version: Release 002 for build 20170213.2 MySampleAppBuild.

Olika	beskrivning
Rev: rr	Ett autoinkrementerat tal med minst det angivna antalet siffror.
Datum/datum: MMddyy	Aktuellt datum, med standardformatet MMddyy. Alla kombinationer av M/MM/MMM/MMMM, d/dd/ddd/dddd, y/åå/å/å, h/hh/H/HH, m/mm, s/ss stöds.
System.TeamProject	Namnet på det projekt som den här versionen tillhör.
Release.ReleaseId	ID:t för versionen, som är unik för alla versioner i projektet.
Release.DefinitionName	Namnet på den versionspipeline som den aktuella versionen tillhör.
Build.BuildNumber	Antalet versioner som finns i versionen. Om en version har flera versioner är det antalet för den primära versionen.
Build.DefinitionName	Pipelinenamnet för bygget som finns i versionen. Om en version har flera versioner är det pipelinenamnet för den primära versionen.
Artifact.ArtifactType	Typen av artefaktkälla som är länkad till versionen. Det kan till exempel vara Azure Pipelines eller Jenkins.
Build.SourceBranch	Grenen av den primära artefaktkällan. För Git är detta av huvudformuläret om grenen är refs/heads/main. För Team Foundation Version Control är detta formulärgrenen om rotserversökvägen för arbetsytan är $/teamproject/branch. Den här variabeln har inte angetts för Jenkins eller andra artefaktkällor.
Anpassad variabel	Värdet för en global konfigurationsegenskap som definierats i versionspipelinen. Du kan uppdatera versionsnamnet med anpassade variabler med hjälp av versionsloggningskommandona

F: Hur definierar jag kvarhållningsperioden för mina versioner?

S: Se kvarhållningsprinciper för att lära dig hur du konfigurerar kvarhållningsprinciper för dina versionspipelines.

Relaterade artiklar

• Distribuera artefakter för pull-begäran
• Distribuera från flera grenar
• Konfigurera en versionspipeline i flera steg