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 belangrijke concepten

afbeelding van de belangrijkste concepten

  • Een trigger geeft aan 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 ordenen 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 stappen bevat.
  • Een stap kan een taak of script zijn 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 een uitvoering.

Azure Pipelines-termen

Agent

Wanneer uw build of implementatie wordt uitgevoerd, begint het systeem 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-agents voor meer gedetailleerde 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 uitvoering. Artefacten worden beschikbaar gesteld voor volgende taken, zoals distributie of implementatie. Zie Artefacten in Azure Pipelines voor 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. Bewakings- en waarschuwingssystemen worden voortdurend uitgevoerd om inzicht te krijgen 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 eenmaal uitvoeren, rollend 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 inrichten van agents voor implementatiegroepen.

Omgeving

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.

Project

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 samen uitgevoerd op dezelfde agent. 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 biedt ondersteuning voor taken zonder agent.

Pijplijn

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.

Vrijgeven

Voor klassieke pijplijnen is een release een versieversie van artefacten die zijn opgegeven in een pijplijn. 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.

Uitvoeren

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 reeks pijplijnuitvoeringen.

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.

Fase

Een fase is een logische grens in de pijplijn. Het kan worden gebruikt om scheiding van problemen te markeren (bijvoorbeeld Build, 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 een bepaalde 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 build- 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 weergeven, raadpleegt u de naslaginformatie over build- en releasetaken . Zie Een aangepaste taak maken voor meer informatie over het maken van aangepaste taken.

Opdracht

Een taak is de bouwsteen voor het definiëren van automatisering in een pijplijn. Een taak is een verpakt script of een procedure die is geabstraheerd met een set invoer.

Activator

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-triggers voor meer informatie.

Bibliotheek

De bibliotheek bevat beveiligde bestanden en variabele groepen. Beveiligde bestanden zijn een manier om bestanden op te slaan en te delen via pijplijnen. U kunt bijvoorbeeld verwijzen naar hetzelfde bestand voor verschillende pijplijnen. In dat geval kunt u het bestand opslaan in de bibliotheek en dit gebruiken wanneer u het nodig hebt. In variabelengroepen worden waarden en geheimen opgeslagen die u mogelijk wilt doorgeven aan een YAML-pijplijn of die beschikbaar moeten worden gesteld in meerdere pijplijnen.

Over de auteurs

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