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:
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.
Wachtrijimplementatietaak:
Azure Pipelines plant de implementatietaak op een beschikbare agent.
Agentselectie:
Een beschikbare agent haalt de implementatietaak op. Een release-pijplijn kan worden geconfigureerd om tijdens runtime dynamisch een geschikte agent te selecteren.
Artefacten downloaden:
De agent haalt alle artefacten op die zijn opgegeven in de release en downloadt deze.
Voer de implementatietaken uit:
De agent voert alle taken in de implementatietaak uit.
Voortgangslogboeken genereren:
De agent genereert uitgebreide logboeken voor elke implementatiestap en stuurt deze terug naar Azure Pipelines.
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.
Releases versus implementaties
Een release is een constructie met een versie van een set artefacten die zijn opgegeven in een CI/CD-pijplijn. Het bevat een momentopname van alle informatie die nodig is voor het uitvoeren van alle taken en acties in de release-pijplijn, zoals fasen, taken, beleidsregels zoals triggers en goedkeurders en implementatieopties. Er kunnen meerdere releases van één release-pijplijn zijn en informatie over elke release wordt opgeslagen en weergegeven in Azure Pipelines voor de opgegeven bewaarperiode.
Een implementatie is de actie van het uitvoeren van de taken voor één fase, waaronder het uitvoeren van geautomatiseerde tests, het implementeren van buildartefacten en alle andere acties die voor die fase worden opgegeven. Als u een release start, wordt elke implementatie gestart op basis van de instellingen en beleidsregels die zijn gedefinieerd in de oorspronkelijke release-pijplijn. Er kunnen meerdere implementaties van elke release zijn, zelfs voor één fase. Wanneer een implementatie van een release mislukt voor een fase, kunt u dezelfde release opnieuw implementeren in die fase. Als u een release opnieuw wilt implementeren, gaat u naar de release die u wilt implementeren en selecteert u implementeren.
In het volgende diagram ziet u de relatie tussen release-, release-pijplijnen en implementaties.
Veelgestelde vragen
V: Waarom is mijn implementatie niet geactiveerd?
A: Het maken van een release-pijplijn start niet automatisch een implementatie. Hier volgen enkele redenen waarom dit kan gebeuren:
Implementatietriggers: gedefinieerde implementatietriggers kunnen ertoe leiden dat de implementatie wordt onderbroken. Dit kan gebeuren met geplande triggers of wanneer er een vertraging is totdat de implementatie naar een andere fase is voltooid.
Wachtrijbeleid: deze beleidsregels bepalen de volgorde van uitvoering en wanneer releases in de wachtrij worden geplaatst voor implementatie.
Goedkeuringen vóór de implementatie of poorten: voor specifieke fasen zijn mogelijk goedkeuringen of poorten voor de implementatie vereist, waardoor aan alle gedefinieerde voorwaarden wordt voldaan.
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.