Dela via


Skapa och målmiljöer

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

Den här artikeln beskriver hur du skapar och riktar in dig på Azure Pipelines-miljöer. En miljö är en samling resurser som du kan rikta in dig på med distributioner från en pipeline.

En miljö representerar ett logiskt mål där din pipeline distribuerar programvara. Typiska miljönamn är Dev, Test, QA, Staging och Production.

Kommentar

Azure DevOps-miljöer är inte tillgängliga i klassiska pipelines. För klassiska pipelines erbjuder distributionsgrupper liknande funktioner.

Miljöer ger följande fördelar:

  • Distributionshistorik. Pipelinenamn och körningsinformation registreras för distributioner till en miljö och dess resurser. I samband med flera pipelines som riktar sig mot samma miljö eller resurs kan du använda distributionshistoriken för en miljö för att identifiera källan till ändringar.

  • Spårning av incheckningar och arbetsobjekt. Du kan visa jobb i pipelinekörningen som är riktad mot en miljö. Du kan också visa incheckningar och arbetsobjekt som nyligen har distribuerats till miljön. Med spårningsbarhet kan du också spåra om en kodändringsincheckning eller funktion/felkorrigering har nått en miljö.

  • Diagnostikresurshälsa. Du kan kontrollera om programmet fungerar i önskat tillstånd.

  • Säkerhet. Du kan skydda miljöer genom att ange vilka användare och pipelines som ska kunna riktas mot en miljö.

En miljö är en gruppering av resurser där själva resurserna representerar faktiska distributionsmål. Azure Pipelines-miljöer stöder för närvarande resurstyperna Kubernetes och virtuella datorer .

Om en YAML-pipeline refererar till en miljö som inte finns:

  • När användaren som utför åtgärden är känd och behörigheter kan tilldelas skapar Azure Pipelines automatiskt miljön.

  • När Azure Pipelines inte har information om användaren som utför åtgärden, till exempel i en YAML-uppdatering från en extern kodredigerare, misslyckas pipelinen.

Förutsättningar

För att lägga till en miljö behöver du följande krav:

  • En Azure DevOps-organisation och ett projekt.
  • Skaparrollen för miljöer i projektet.

Skapa en miljö

Så här skapar du din första miljö:

  1. Logga in på din Azure DevOps-organisation och https://dev.azure.com/{yourorganization} öppna projektet.

  2. Välj Pipelines-miljöer>>Skapa miljö.

    Skärmbild som visar Miljöer.

  3. Ange information för miljön och välj sedan Skapa. Du kan lägga till resurser i en befintlig miljö senare.

    Skärmbild av att skapa en ny miljö.

Dricks

Du kan skapa en tom miljö och referera till den från distributionsjobb så att du kan registrera distributionshistorik mot miljön.

Du kan använda Azure Pipelines för att distribuera till miljöer. Mer information finns i Skapa och distribuera till Azure Kubernetes Service med Azure Pipelines.

Rikta en miljö från ett distributionsjobb

Ett distributionsjobb är en samling steg som körs sekventiellt. Du kan använda ett distributionsjobb för att rikta in dig på en hel miljögrupp med resurser, enligt följande exempel yaml-kodfragment. Pipelinen körs på myVM datorn eftersom resursnamnet har angetts.

- 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

Rikta en specifik miljöresurs från ett distributionsjobb

Du kan begränsa distributionsmålet till en viss resurs i miljön, så att du kan registrera distributionshistorik för den specifika resursen. Stegen i distributionsjobbet ärver automatiskt tjänstanslutningsinformationen från resursen som distributionsjobbet riktar in sig på.

I följande exempel skickas värdet för automatiskt kubernetesServiceConnection ned till aktiviteten från environment.resource indata.

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)

Använda manuella godkännandekontroller

För att styra distributioner till produktionsmiljöer stöder Azure Pipelines manuella godkännandekontroller av miljöer. Godkännandekontroller är tillgängliga för resursägare att styra när en fas i en pipeline förbrukar resursen. Resursägare kan definiera godkännanden och kontroller som måste uppfyllas innan en fas som förbrukar resursen kan börja.

Miljörollerna Skapare, Administratör och Användare, men inte rollen Läsare, kan hantera godkännanden och kontroller. Som miljöägare kan du manuellt styra när en fas ska köras med hjälp av godkännandekontroller. Mer information finns i Definiera godkännanden och kontroller.

Se miljöerna i körningsinformation

Under fliken Miljöer i pipelinekörningsinformationen kan du se alla miljöer som var mål för distributionsjobb för en pipelinekörning.

Skärmbild som visar miljöerna i körningsinformation.

Kommentar

Om du använder ett privat Azure Kubernetes Service-kluster (AKS) är fliken Miljöer inte tillgänglig.

Visa distributionshistorik

Du kan välja fliken Distributioner i avsnittet Azure Pipelines Environments för att visa distributionshistoriken.

  • Visa jobb från alla pipelines som är inriktade på en specifik miljö. Två mikrotjänster som var och en har en egen pipeline kan till exempel distribueras till samma miljö. Distributionshistoriken hjälper till att identifiera alla pipelines som påverkar miljön och hjälper även till att visualisera distributionssekvensen för varje pipeline.

    Skärmbild som visar distributionshistoriklistan.

  • Om du vill öka detaljnivån i jobbinformationen väljer du flikarna Ändringar och Arbetsobjekt på en distributionssida. Flikarna visar listor över incheckningar och arbetsobjekt som distribuerats till miljön. Varje listobjekt representerar nya objekt i distributionen.

    På fliken Ändringar innehåller den första listan alla incheckningar till den punkten, och följande listor innehåller bara ändringarna för jobbet. Om flera incheckningar är knutna till samma jobb finns det flera resultat på fliken Ändringar .

    Skärmbild av incheckningar under distributionshistorik.

  • Om flera arbetsobjekt är knutna till samma jobb finns det flera resultat på fliken Arbetsobjekt .

    Skärmbild av arbetsobjekt under distributionshistorik.

Säkerhet

Du kan skydda dina miljöer genom att ange användarbehörigheter och pipelinebehörigheter.

Användarbehörigheter

Du kan styra vem som kan skapa, visa, använda och hantera miljöer med användarbehörighet. Det finns fyra roller: Skapare med ett omfång för alla miljöer, läsare, användare och administratör.

Om du vill lägga till en användare med hjälp av en miljös användarbehörighetspanel går du till den specifika miljö som du vill auktorisera, väljer ikonen Fler åtgärder och väljer Säkerhet.

I panelen Användarbehörigheter på sidan Säkerhet väljer du Lägg till och sedan en användare eller grupp och lämplig roll.

I panelen Användarbehörigheter kan du också ange de behörigheter som ärvs och åsidosätta rollerna för din miljö.

Roll beskrivning
Skapare Global roll, tillgänglig från miljöhubbens säkerhetsalternativ. Medlemmar i den här rollen kan skapa miljön i projektet. Deltagare läggs till som medlemmar som standard. Krävs för att utlösa en YAML-pipeline när miljön inte redan finns.
Läsare Medlemmar i den här rollen kan visa miljön.
Användare Medlemmar i den här rollen kan använda miljön när de skapar eller redigerar YAML-pipelines.
Administratör Medlemmar i den här rollen kan administrera behörigheter, skapa, hantera, visa och använda miljöer. För en viss miljö läggs dess skapare till som Admininistrator som standard. Administratörer kan också öppna åtkomsten till en miljö för alla pipelines.

Viktigt!

När du skapar en miljö är det bara skaparen som har administratörsrollen.

Roll beskrivning
Skapare Global roll, tillgänglig från miljöhubbens säkerhetsalternativ. Medlemmar i den här rollen kan skapa miljön i projektet. Deltagare läggs till som medlemmar som standard. Krävs för att utlösa en YAML-pipeline när miljön inte redan finns.
Läsare Medlemmar i den här rollen kan visa miljön.
Användare Medlemmar i den här rollen kan använda miljön när de skapar eller redigerar YAML-pipelines.
Administratör Förutom att använda miljön kan medlemmar i den här rollen hantera medlemskap i alla andra roller för miljön. Skapare läggs till som medlemmar som standard.

Pipeline-behörigheter

Använd panelen Pipelinebehörighetersidan Säkerhet för att auktorisera alla eller valda pipelines för distribution till miljön.

  • Om du vill ta bort öppen åtkomst för miljön eller resursen väljer du Begränsa behörighet i Pipeline-behörigheter.

  • När behörigheterna är begränsade kan du tillåta att specifika pipelines distribueras till miljön eller till en specifik resurs. Välj + och välj från listan över pipelines som ska tillåtas.

Vanliga frågor

Varför får jag ett felmeddelande när jag försöker skapa en miljö?

Om du ser meddelandet Åtkomst nekad: {User} behöver Skapa behörigheter för att utföra åtgärden går du till Organisationsinställningar>Användare för att kontrollera om du har rollen Intressent. Intressentrollen kan inte skapa miljöer eftersom intressenter inte har åtkomst till lagringsplatsen.

Ändra åtkomstnivån och kontrollera sedan om du kan skapa miljöer. Mer information finns i Vanliga frågor och svar om hantering av användare och behörigheter.

Varför får jag ett felmeddelande om att det inte går att hitta en miljö?

Det gick inte att hitta meddelandet Jobb XXXX: Miljö XXXX. Miljön finns inte eller har inte godkänts för användning. Det finns flera möjliga orsaker till felet.

  • Körningsparametrar fungerar inte när du skapar miljöer, eftersom parametrarna endast expanderas vid körning. Du kan använda variabler för att skapa en miljö eller använda templateContext för att skicka egenskaper till mallar.

  • Azure Pipelines kanske inte har information om användaren som skapar miljön.

    När du refererar till en miljö som inte finns i en YAML-pipelinefil skapar Azure Pipelines automatiskt miljön i följande fall:

    • Du använder guiden skapa YAML-pipeline i Azure Pipelines-webbmiljön och refererar till en miljö som inte har skapats ännu.
    • Du uppdaterar YAML-filen med hjälp av Azure Pipelines-webbredigeraren och sparar pipelinen när du har lagt till referensen till miljön.

    I följande fall har Azure Pipelines inte information om användaren som skapar miljön, så pipelinen misslyckas.

    • Du uppdaterar YAML-filen med hjälp av en annan extern kodredigerare.
    • Du lägger till en referens till en miljö som inte finns och sedan utlöses en manuell eller kontinuerlig integreringspipeline.

    Tidigare hanterade Azure Pipelines dessa fall genom att lägga till alla projektdeltagare i administratörsrollen för miljön. Alla medlemmar i projektet kunde sedan ändra dessa behörigheter och hindra andra från att komma åt miljön. För att förhindra det här resultatet misslyckas nu de här jobben i Azure Pipelines.