Klassieke release-pijplijnen

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

Klassieke releasepijplijnen bieden ontwikkelaars een framework voor het efficiënt en veilig implementeren van toepassingen in meerdere omgevingen. Met klassieke release-pijplijnen kunt u test- en implementatieprocessen automatiseren, flexibele implementatiestrategieën instellen, goedkeuringswerkstromen opnemen en ervoor zorgen dat de toepassing in verschillende fasen soepel verloopt.

Hoe werken release-pijplijnen?

Als onderdeel van elke implementatie voert Azure Pipelines de volgende stappen uit:

1. Goedkeuring vóór implementatie:

   Wanneer een nieuwe implementatieaanvraag wordt geactiveerd, controleert Azure Pipelines of een goedkeuring voor de implementatie noodzakelijk is voordat een release in een fase wordt geïmplementeerd. Als goedkeuring is vereist, worden e-mailmeldingen verzonden naar de relevante fiatteurs.

2. Wachtrijimplementatietaak:

   Azure Pipelines plant de implementatietaak op een beschikbare agent.

3. Agentselectie:

   Een beschikbare agent haalt de implementatietaak op. Een release-pijplijn kan worden geconfigureerd om tijdens runtime dynamisch een geschikte agent te selecteren.

4. Artefacten downloaden:

   De agent haalt alle artefacten op die zijn opgegeven in de release en downloadt deze.

5. Voer de implementatietaken uit:

   De agent voert alle taken in de implementatietaak uit.

6. Voortgangslogboeken genereren:

   De agent genereert uitgebreide logboeken voor elke implementatiestap en stuurt deze terug naar Azure Pipelines.

7. Goedkeuring na implementatie:

   Nadat de implementatie naar een fase is voltooid, controleert Azure Pipelines of een goedkeuring na de implementatie nodig is voor die specifieke fase. Als er geen goedkeuring nodig is of als een vereiste goedkeuring is verkregen, wordt de implementatie gestart in de volgende fase.

Implementatiemodel

Azure-releasepijplijnen ondersteunen een breed scala aan artefactbronnen , waaronder Jenkins, Azure Artifacts en Team City. In het volgende voorbeeld ziet u een implementatiemodel met behulp van Azure-releasepijplijnen:

In het volgende voorbeeld bestaat de pijplijn uit twee buildartefacten die afkomstig zijn van afzonderlijke build-pijplijnen. De toepassing wordt in eerste instantie geïmplementeerd in de dev-fase en vervolgens in twee afzonderlijke QA-fasen . Als de implementatie in beide QA-fasen is geslaagd, wordt de toepassing geïmplementeerd op Prod ring 1 en vervolgens op Prod ring 2. Elke productiering vertegenwoordigt meerdere exemplaren van dezelfde web-app, geïmplementeerd op verschillende locaties over de hele wereld.

Veelgestelde vragen

V: Hoe kan ik variabelen tijdens de release bewerken?

A: Schakel op het tabblad Variabelen van uw release-pijplijn het selectievakje Settable bij releasetijd in voor de variabelen die u wilt wijzigen wanneer een release in de wachtrij staat.

Bij het genereren van een nieuwe release hebt u vervolgens de mogelijkheid om de waarden van deze variabelen te wijzigen.

V: Wanneer is het geschikter om een release te wijzigen in plaats van de pijplijn die deze definieert?

A: U kunt de goedkeuringen, taken en variabelen van een release-exemplaar bewerken. Deze bewerkingen zijn echter alleen van toepassing op dat exemplaar. Als u wilt dat uw wijzigingen van toepassing zijn op alle toekomstige releases, bewerkt u in plaats daarvan de release-pijplijn.

V: Wat zijn de scenario's waarin de functie 'een release afbreken' nuttig is?

A: Als u niet van plan bent om de release opnieuw te gebruiken of wilt voorkomen dat deze wordt gebruikt, kunt u de release als volgt afbreken. (...) >>Verlaten. U kunt een release niet afbreken wanneer een implementatie wordt uitgevoerd. U moet de implementatie eerst annuleren.

V: Hoe kan ik de naamgeving van nieuwe releases beheren?

A: De standaardnaamconventie voor release-pijplijnen is sequentiële nummering, waarbij de releases de naam Release-1, Release-2 enzovoort hebben. U hebt echter de flexibiliteit om het naamgevingsschema aan te passen door het masker voor de releasenaamindeling te wijzigen. Ga op het tabblad Opties van uw release-pijplijn naar de pagina Algemeen en pas de eigenschap Release name format aan aan uw voorkeuren.

Wanneer u het opmaakmasker opgeeft, kunt u de volgende vooraf gedefinieerde variabelen gebruiken. Voorbeeld: De volgende releasenaamindeling: Release $(Rev:rrr) voor build $(Build.BuildNumber) $(Build.DefinitionName) maakt de volgende release: Release 002 voor build 20170213.2 MySampleAppBuild.

Variabele	Beschrijving
Rev: rr	Een automatisch gegenereerd getal met ten minste het opgegeven aantal cijfers.
Datum/datum: MMddyy	De huidige datum, met de standaardnotatie MMddyy. Alle combinaties van M/MM/MMM/MMMM, d/dd/ddd/dddd, y/jj/jjjj/jjjj/jjjj, h/hh/H/HH, m/mm, s/ss worden ondersteund.
System.TeamProject	De naam van het project waartoe deze build behoort.
Release.ReleaseId	De id van de release, die uniek is voor alle releases in het project.
Release.DefinitionName	De naam van de release-pijplijn waartoe de huidige release behoort.
Build.BuildNumber	Het nummer van de build in de release. Als een release meerdere builds heeft, is dit het nummer van de primaire build.
Build.DefinitionName	De naam van de pijplijn van de build in de release. Als een release meerdere builds heeft, is dit de naam van de pijplijn van de primaire build.
Artifact.ArtifactType	Het type artefactbron dat is gekoppeld aan de release. Dit kan bijvoorbeeld Azure Pipelines of Jenkins zijn.
Build.SourceBranch	De vertakking van de primaire artefactbron. Voor Git is dit van de hoofdvorm als de vertakking refs/heads/main is. Voor Team Foundation-versiebeheer is dit van de formulierbranch als het hoofdserverpad voor de werkruimte $/teamproject/branch is. Deze variabele is niet ingesteld voor Jenkins of andere artefactbronnen.
Aangepaste variabele	De waarde van een globale configuratie-eigenschap die is gedefinieerd in de release-pijplijn. U kunt de releasenaam bijwerken met aangepaste variabelen met behulp van de opdrachten voor releaselogboekregistratie

V: Hoe kan ik de bewaarperiode voor mijn releases definiëren?

A: Zie bewaarbeleid voor meer informatie over het instellen van bewaarbeleid voor uw release-pijplijnen.

Verwante artikelen:

• Artefacten voor pull-aanvragen implementeren
• Implementeren vanuit meerdere vertakkingen
• Een releasepijplijn met meerdere fasen instellen