Een omgeving maken en als doel gebruiken

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Een omgeving is een verzameling resources die u kunt richten op implementaties vanuit een pijplijn. Typische voorbeelden van omgevingsnamen zijn Dev, Test, QA, Staging en Production. Een Azure DevOps-omgeving vertegenwoordigt een logisch doel waar uw pijplijn software implementeert.

Azure DevOps-omgevingen zijn niet beschikbaar in klassieke pijplijnen. Voor klassieke pijplijnen bieden implementatiegroepen vergelijkbare functionaliteit.

Omgevingen bieden de volgende voordelen.

Voordeel	Beschrijving
Implementatiegeschiedenis	Pijplijnnaam en uitvoeringsdetails worden vastgelegd voor implementaties in een omgeving en de bijbehorende resources. In de context van meerdere pijplijnen die gericht zijn op dezelfde omgeving of resource, is de implementatiegeschiedenis van een omgeving handig om de bron van wijzigingen te identificeren.
Traceerbaarheid van doorvoeringen en werkitems	Bekijk taken in de pijplijnuitvoering die gericht zijn op een omgeving. U kunt ook de doorvoeringen en werkitems bekijken die zojuist zijn geïmplementeerd in de omgeving. Met traceerbaarheid kunt u ook bijhouden of een codewijziging (doorvoer) of een functie/bug-fix (werkitems) een omgeving heeft bereikt.
Status van diagnostische resource	Controleer of de toepassing werkt met de gewenste status.
Beveiliging	Beveilig omgevingen door op te geven welke gebruikers en pijplijnen zich op een omgeving mogen richten.

Hoewel een omgeving een groepering van resources is, vertegenwoordigen de resources zelf de werkelijke implementatiedoelen. De Kubernetes-resource - en resourcetypen voor virtuele machines worden momenteel ondersteund.

Wanneer u een YAML-pijplijn maakt en verwijst naar een omgeving die niet bestaat, maakt Azure Pipelines automatisch de omgeving wanneer de gebruiker die de bewerking uitvoert bekend is en machtigingen kunnen worden toegewezen. Wanneer Azure Pipelines geen informatie heeft over de gebruiker die de omgeving maakt (bijvoorbeeld: een YAML-update vanuit een externe code-editor), mislukt de pijplijn als de omgeving nog niet bestaat.

Vereisten

• U moet de rol Maker voor omgevingen hebben om een omgeving toe te voegen.

Een omgeving maken

1. Meld u aan bij uw organisatie en https://dev.azure.com/{yourorganization} selecteer uw project.

2. Selecteer Pipelines>Environments>Create environment.

   

3. Voer gegevens in voor de omgeving en selecteer Vervolgens Maken. Resources kunnen later worden toegevoegd aan een bestaande omgeving.

   

Gebruik ook een pijplijn om omgevingen te maken en te implementeren. Zie de handleiding voor instructies voor meer informatie.

Tip

U kunt een lege omgeving maken en ernaar verwijzen vanuit implementatietaken. Hiermee kunt u de implementatiegeschiedenis vastleggen op basis van de omgeving.

Een omgeving targeten vanuit een implementatietaak

Een implementatietaak is een verzameling stappen die opeenvolgend moeten worden uitgevoerd. Een implementatietaak kan worden gebruikt om een hele omgeving (groep resources) te richten, zoals wordt weergegeven in het volgende YAML-fragment. De pijplijn wordt uitgevoerd op de myVM-machine omdat de resourcenaam is opgegeven.

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

Een specifieke resource in een omgeving targeten vanuit de implementatietaak

U kunt het doel van de implementatie instellen op een bepaalde resource in de omgeving. Vervolgens kunt u de implementatiegeschiedenis van een specifieke resource in de omgeving vastleggen. De stappen van de implementatietaak nemen automatisch de serviceverbindingsgegevens over van de resource waarop de implementatietaak is gericht.

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)
         # value for kubernetesServiceConnection input automatically passed down to task by environment.resource input

Omgeving in uitvoeringsdetails

Alle omgevingen waarop implementatietaken van een specifieke uitvoering van een pijplijn worden toegepast, vindt u op het tabblad Omgevingen met details van de pijplijnuitvoering.

Als u een privécluster van AKS gebruikt, is het tabblad Omgevingen niet beschikbaar.

Goedkeuringen

Beheer handmatig wanneer een fase moet worden uitgevoerd met behulp van goedkeuringscontroles. Gebruik goedkeuringscontroles om implementaties naar productieomgevingen te beheren. Controles zijn beschikbaar voor de eigenaar van de resource om te bepalen wanneer een fase in een pijplijn een resource verbruikt. Als eigenaar van een resource, zoals een omgeving, kunt u goedkeuringen en controles definiëren waaraan moet worden voldaan voordat een fase die die resource gebruikt, wordt gestart.

We ondersteunen handmatige goedkeuringscontroles op omgevingen. Zie Goedkeuringen voor meer informatie.

De maker, Beheer istrator en gebruikersrollen kunnen goedkeuringen en controles beheren. De rol Lezer kan geen goedkeuringen en controles beheren.

Implementatiegeschiedenis

De weergave implementatiegeschiedenis in omgevingen biedt de volgende voordelen.

• Bekijk taken uit alle pijplijnen die zijn gericht op een specifieke omgeving. Twee microservices, elk met een eigen pijplijn, worden bijvoorbeeld geïmplementeerd in dezelfde omgeving. De lijst met implementatiegeschiedenissen helpt bij het identificeren van alle pijplijnen die van invloed zijn op deze omgeving en helpt ook bij het visualiseren van de volgorde van implementaties per pijplijn.

  

• Zoom in op de taakdetails om de lijst met doorvoeringen en werkitems weer te geven die in de omgeving zijn geïmplementeerd. De lijst met doorvoeringen en werkitems zijn de nieuwe items tussen implementaties. Uw eerste vermelding bevat alle doorvoeringen en de volgende vermeldingen bevatten alleen wijzigingen. Als meerdere doorvoeringen zijn gekoppeld aan dezelfde pull-aanvraag, ziet u meerdere resultaten op de tabbladen werkitems en wijzigingen.

  

• Als meerdere werkitems zijn gekoppeld aan dezelfde pull-aanvraag, ziet u meerdere resultaten op het tabblad Werkitems.

  

Beveiliging

Gebruikersmachtigingen

Bepalen wie de omgevingen met gebruikersmachtigingen kan maken, weergeven, gebruiken en beheren. Er zijn vier rollen: Maker (bereik: alle omgevingen), Lezer, Gebruiker en Beheer istrator. In het deelvenster gebruikersmachtigingen van de specifieke omgeving kunt u de machtigingen instellen die worden overgenomen en kunt u de rollen voor elke omgeving overschrijven.

1. Ga naar de specifieke omgeving die u wilt autoriseren.
2. Selecteer >Beveiliging om de instellingen weer te geven.
3. Selecteer Gebruikersmachtigingen>+Gebruiker of groep toevoegen>en selecteer vervolgens een geschikte rol.

Rol	Beschrijving
Maker	Globale rol, beschikbaar via de optie voor beveiliging van omgevingen hubs. Leden van deze rol kunnen de omgeving in het project maken. Inzenders worden standaard toegevoegd als leden. Vereist om een YAML-pijplijn te activeren wanneer de omgeving nog niet bestaat.
Lezer	Leden van deze rol kunnen de omgeving bekijken.
Gebruiker	Leden van deze rol kunnen de omgeving gebruiken bij het maken of bewerken van YAML-pijplijnen.
Beheerder	Leden van deze rol kunnen machtigingen beheren, omgevingen maken, beheren, weergeven en gebruiken. Voor een bepaalde omgeving wordt de maker standaard toegevoegd als Beheer inistrator. Beheer istrators kunnen ook toegang tot een omgeving openen voor alle pijplijnen.

Pijplijnmachtigingen

Gebruik pijplijnmachtigingen om alle of geselecteerde pijplijnen voor implementatie naar de omgeving te autoriseren.

• Als u Open access voor de omgeving of resource wilt verwijderen, selecteert u Machtiging beperken in pijplijnmachtigingen.
• Als u wilt toestaan dat specifieke pijplijnen worden geïmplementeerd in een omgeving of specifieke resource, selecteert en kiest u + deze in de lijst met pijplijnen.

Volgende stappen

Goedkeuringen en controles definiëren

Veelgestelde vragen

V: Waarom krijg ik een foutbericht wanneer ik een omgeving probeer te maken?

A: Als u het bericht 'Toegang geweigerd: {Gebruiker} heeft machtigingen nodig om de actie uit te voeren', controleert u de machtigingen op organisatieniveau. Ga naar Organisatie-instellingen>Gebruikers en controleer of u de rol belanghebbende hebt. De rol belanghebbende kan geen omgevingen maken. Wijzig uw toegangsniveau en controleer vervolgens of u omgevingen kunt maken. Zie Veelgestelde vragen over gebruikers- en machtigingenbeheer voor meer informatie.

V: Waarom krijg ik de foutmelding 'Taak XXXX: Omgeving XXXX kan niet worden gevonden. De omgeving bestaat niet of is niet geautoriseerd voor gebruik'?

A: Dit zijn enkele van de mogelijke oorzaken van de fout:

• Wanneer u een YAML-pijplijn maakt en verwijst naar een omgeving die niet in het YAML-bestand bestaat, maakt Azure Pipelines in sommige gevallen automatisch de omgeving:

  • U gebruikt de wizard YAML-pijplijn maken in de webervaring van Azure Pipelines en verwijst naar een omgeving die nog niet is gemaakt.
  • U werkt het YAML-bestand bij met behulp van de Azure Pipelines-webeditor en slaat de pijplijn op nadat u een verwijzing hebt toegevoegd aan een omgeving die niet bestaat.

• In de volgende stromen bevat Azure Pipelines geen informatie over de gebruiker die de omgeving maakt: u werkt het YAML-bestand bij met behulp van een andere externe code-editor, voegt een verwijzing toe naar een omgeving die niet bestaat en zorgt ervoor dat een handmatige of continue integratiepijplijn wordt geactiveerd. In dit geval weten Azure Pipelines niet over de gebruiker. Eerder hebben we deze case afgehandeld door alle projectbijdragers toe te voegen aan de beheerdersrol van de omgeving. Elk lid van het project kan deze machtigingen vervolgens wijzigen en voorkomen dat anderen toegang krijgen tot de omgeving.

• U kunt variabelen gebruiken om de omgeving te maken of templateContext gebruiken om eigenschappen door te geven aan sjablonen. Runtimeparameters werken niet bij het maken van de omgeving, omdat ze tijdens runtime worden uitgebreid.

• Een gebruiker met toegangsniveau voor belanghebbenden kan de omgeving niet maken omdat belanghebbenden geen toegang hebben tot de opslagplaats.

Verwante artikelen:

• Variabelen definiëren
• Resources definiëren in YAML