Belangrijkste concepten voor nieuwe Azure Pipelines-gebruikers

Azure DevOps Services-

Meer informatie over de belangrijkste concepten en onderdelen waaruit Azure Pipelines bestaat. Als u de basistermen en onderdelen van een pijplijn begrijpt, kunt u uw code effectiever bouwen, testen en implementeren.

overzicht van belangrijkste concepten

• Een -trigger aangeeft dat een pijplijn moet worden uitgevoerd.
• Een pijplijn bestaat uit een of meer fasen. Een pijplijn kan worden geïmplementeerd in een of meer omgevingen.
• Een fase is een manier om taken in een pijplijn te organiseren en elke fase kan een of meer taken hebben.
• Elke taak wordt uitgevoerd op één agent. Een taak kan ook zonder agent zijn.
• Elke agent voert een taak uit die een of meer stappenbevat.
• Een stap kan een taak zijn of script en is de kleinste bouwsteen van een pijplijn.
• Een taak is een vooraf verpakt script waarmee een actie wordt uitgevoerd, zoals het aanroepen van een REST API of het publiceren van een build-artefact.
• Een artefact is een verzameling bestanden of pakketten die zijn gepubliceerd door de uitvoering van een .

Azure Pipelines-termen

Agent

Wanneer het systeem uw build of implementatie uitvoert, start het een of meer taken. Een agent is een computerinfrastructuur met geïnstalleerde agentsoftware die één taak tegelijk uitvoert. Uw taak kan bijvoorbeeld worden uitgevoerd op een door Microsoft gehoste Ubuntu-agent.

Zie Azure Pipelines Agentsvoor uitgebreidere informatie over de verschillende typen agents en hoe u deze kunt gebruiken.

Goedkeuringen

goedkeuringen een set validaties definiëren die vereist zijn voordat een implementatie wordt uitgevoerd. Handmatige goedkeuring is een algemene controle die wordt uitgevoerd om implementaties naar productieomgevingen te beheren. Wanneer controles zijn geconfigureerd in een omgeving, wordt een pijplijnuitvoering onderbroken totdat alle controles zijn voltooid.

Artefact

Een artefact is een verzameling bestanden of pakketten die zijn gepubliceerd door een run. Artefacten worden beschikbaar gesteld voor volgende taken, zoals distributie of implementatie. Zie Artifacts in Azure Pipelinesvoor meer informatie.

Continue levering

Continue levering (CD) is een proces waarmee code wordt gebouwd, getest en geïmplementeerd in een of meer test- en productiefasen. Het implementeren en testen in meerdere fasen helpt de kwaliteit te stimuleren. Continue integratiesystemen produceren implementeerbare artefacten, waaronder infrastructuur en apps. Geautomatiseerde releasepijplijnen gebruiken deze artefacten om nieuwe versies en oplossingen voor bestaande systemen vrij te geven. Monitoring- en waarschuwingssystemen draaien voortdurend om zichtbaarheid te bieden in het hele CD-proces. Dit proces zorgt ervoor dat fouten vaak en vroeg worden opgevangen.

Continue integratie

Continue integratie (CI) is de praktijk die wordt gebruikt door ontwikkelteams om het testen en bouwen van code te vereenvoudigen. CI helpt bij het opsporen van bugs of problemen vroeg in de ontwikkelingscyclus, waardoor ze gemakkelijker en sneller kunnen worden opgelost. Geautomatiseerde tests en builds worden uitgevoerd als onderdeel van het CI-proces. Het proces kan worden uitgevoerd volgens een ingestelde planning, wanneer code wordt gepusht of beide. Items die bekend staan als artefacten, worden geproduceerd uit CI-systemen. Ze worden gebruikt door de pijplijnen voor continue leveringsrelease om automatische implementaties te stimuleren.

Implementatie

Een klassieke pijplijnimplementatie is de actie van het uitvoeren van de taken voor één fase. De implementatie kan bestaan uit het uitvoeren van geautomatiseerde tests, het implementeren van buildartefacten en eventuele andere acties die voor die fase worden opgegeven.

Voor YAML-pijplijnen verwijst een implementatie naar een implementatietaak. Een implementatietaak is een verzameling stappen die opeenvolgend worden uitgevoerd voor een omgeving. U kunt strategieën zoals één keer uitvoeren, rollende en kanarie gebruiken voor implementatietaken.

Implementatiegroep

Een implementatiegroep is een set implementatiedoelmachines waarop agents zijn geïnstalleerd. Een implementatiegroep is slechts een andere groep agents, zoals een agentgroep. U kunt de implementatiedoelen instellen in een pijplijn voor een taak met behulp van een implementatiegroep. Meer informatie over het provisioneren van agents voor implementatiegroep.

Milieu

Een -omgeving is een verzameling resources waarin u uw toepassing implementeert. Eén omgeving kan een of meer virtuele machines, containers, web-apps of een service bevatten. Pijplijnen worden geïmplementeerd in een of meer omgevingen nadat een build is voltooid en tests worden uitgevoerd.

Baan

Een fase bevat een of meer taken. Elke taak wordt uitgevoerd op een agent. Een taak vertegenwoordigt een uitvoeringsgrens van een reeks stappen. Alle stappen worden op dezelfde agent uitgevoerd. Taken zijn het handigst wanneer u een reeks stappen in verschillende omgevingen wilt uitvoeren. U kunt bijvoorbeeld twee configuraties bouwen: x86 en x64. In dit geval hebt u één fase en twee taken. De ene taak is voor x86 en de andere taak is voor x64.

Taken zonder agent worden uitgevoerd in Azure DevOps en Azure DevOps Server zonder een agent te gebruiken. Een beperkt aantal taken ondersteunt agentloze taken.

Pijpleiding

Een pijplijn definieert het continue integratie- en implementatieproces voor uw app. Het bestaat uit een of meer fasen. Het kan worden beschouwd als een werkstroom die definieert hoe uw test-, build- en implementatiestappen worden uitgevoerd.

Voor klassieke pijplijnen kan een pijplijn ook wel een definitie worden genoemd.

Loslaten

Voor klassieke pijplijnen is een release- een versie van artefacten die in een pijplijn zijn vastgelegd. De release 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. U kunt handmatig een release maken, met een implementatietrigger of met de REST API.

Voor YAML-pijplijnen bevinden de build- en releasefasen zich in één, pijplijn met meerdere fasen.

Rennen

Een uitvoering vertegenwoordigt één uitvoering van een pijplijn. Hiermee worden de logboeken verzameld die zijn gekoppeld aan het uitvoeren van de stappen en de resultaten van het uitvoeren van tests. Tijdens een uitvoering verwerkt Azure Pipelines eerst de pijplijn en verzendt de uitvoering vervolgens naar een of meer agents. Elke agent voert taken uit. Meer informatie over de pijplijnuitvoeringsvolgorde.

Voor klassieke pijplijnen vertegenwoordigt een build één uitvoering van een pijplijn.

Script

Een script voert code uit als een stap in uw pijplijn met behulp van de opdrachtregel, PowerShell of Bash. U kunt platformoverschrijdende scripts schrijven voor macOS, Linux en Windows. In tegenstelling tot een taak, is een script aangepaste code die specifiek is voor uw pijplijn.

Podium

Een stap is een logische grens in de pijplijn. Het kan worden gebruikt om de scheiding van verantwoordelijkheden te markeren (bijvoorbeeld Bouw, QA en productie). Elke fase bevat een of meer taken. Wanneer u meerdere fasen in een pijplijn definieert, worden ze standaard één na de andere uitgevoerd. U kunt de voorwaarden opgeven voor wanneer een fase wordt uitgevoerd. Wanneer u nadenkt of u een fase nodig hebt, vraagt u zich het volgende af:

• Beheren afzonderlijke groepen verschillende onderdelen van deze pijplijn? U kunt bijvoorbeeld een testbeheerder hebben die de taken beheert die betrekking hebben op testen en een andere manager die taken beheert die betrekking hebben op productie-implementatie. In dit geval is het zinvol om afzonderlijke fasen te hebben voor testen en productie.
• Is er een set goedkeuringen die zijn verbonden met een specifieke taak of set taken? Zo ja, dan kunt u fasen gebruiken om uw taken op te splitsen in logische groepen waarvoor goedkeuringen zijn vereist.
• Zijn er taken die lang moeten worden uitgevoerd? Als een taak in uw pijplijn een lange uitvoeringstijd heeft, is het zinvol om die taak in een eigen fase te plaatsen.

Stap

Een stap is de kleinste bouwsteen van een pijplijn. Een pijplijn kan bijvoorbeeld bestaan uit bouw- en teststappen. Een stap kan een script of een taak zijn. Een taak is gewoon een vooraf gemaakt script dat u gemakkelijk kunt gebruiken. Als u de beschikbare taken wilt bekijken, raadpleegt u de Build- en releasetaken naslaginformatie. Zie Een aangepaste taak makenvoor meer informatie over het maken van aangepaste taken.

Taak

Een taak is de bouwsteen voor het definiëren van automatisering in een pijplijn. Een taak is een gebundeld script of een procedure die geabstraheerd is met een reeks invoerwaarden.

Trigger

Een trigger is iets dat is ingesteld om de pijplijn te laten weten wanneer deze moet worden uitgevoerd. U kunt een pijplijn zo configureren dat deze wordt uitgevoerd na een push naar een opslagplaats, op geplande tijden of na voltooiing van een andere build. Al deze acties worden triggers genoemd. Zie build-triggers en release-triggersvoor meer informatie.

Bibliotheek

De Library bevat beveiligde bestanden en variabelegroepen. Beveiligde bestanden zijn een manier om bestanden op te slaan en te delen in pijplijnen. U kunt bijvoorbeeld verwijzen naar hetzelfde bestand voor verschillende pijplijnen. In dat geval kunt u het bestand opslaan in Bibliotheek en dit gebruiken wanneer u het nodig hebt. Groepen variabelen, slaan waarden en geheimen op die u misschien wilt doorgeven aan een YAML-pijplijn of beschikbaar maken in meerdere pijplijnen.

Over de auteurs

• Dave Jarvis heeft bijgedragen aan de overzichtsafbeelding van de belangrijkste concepten.