Implementeren naar App Service met behulp van Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019

Gebruik Azure Pipelines om uw web-app automatisch te implementeren in Azure-app Service bij elke geslaagde build. Met Azure Pipelines kunt u met behulp van Azure DevOps bouwen, testen en implementeren met continue integratie (CI) en continue levering (CD).

YAML-pijplijnen worden gedefinieerd met behulp van een YAML-bestand in uw opslagplaats. Een stap is de kleinste bouwsteen van een pijplijn en kan een script of taak (vooraf verpakt script) zijn. Meer informatie over de belangrijkste concepten en onderdelen waaruit een pijplijn bestaat.

U gebruikt de Azure-web-app-taak (AzureWebApp) om te implementeren in Azure-app Service in uw pijplijn. Voor complexere scenario's, zoals het gebruik van XML-parameters in uw implementatie, kunt u de Azure-app Service Deploy-taak (AzureRmWebAppDeployment) gebruiken.

Vereisten

• Een Azure-account met een actief abonnement. Gratis een account maken
• een Azure DevOps-organisatie. Maak gratis een account.
• Een mogelijkheid om pijplijnen uit te voeren op door Microsoft gehoste agents. U kunt een parallelle taak aanschaffen of u kunt een gratis laag aanvragen.
• Een werkende Azure-app Service-app met code die wordt gehost op GitHub of Azure-opslagplaatsen.
  • .NET: Een ASP.NET Core-web-app maken in Azure
  • ASP.NET: Een ASP.NET Framework-web-app maken in Azure
  • JavaScript: een Node.js-web-app maken in Azure-app Service
  • Java: Een Java-app maken in Azure-app Service
  • Python: Een Python-app maken in Azure-app Service

1. Een pijplijn voor uw stack maken

In de codevoorbeelden in deze sectie wordt ervan uitgegaan dat u een ASP.NET-web-app implementeert. U kunt de instructies voor andere frameworks aanpassen.

Meer informatie over azure Pipelines-ecosysteemondersteuning.

YAML

1. Meld u aan bij uw Azure DevOps-organisatie en navigeer naar uw project.

2. Ga naar Pijplijnen en selecteer vervolgens Nieuwe pijplijn.

3. Wanneer u hierom wordt gevraagd, selecteert u de locatie van uw broncode: Azure Repos Git of GitHub.

   U wordt mogelijk omgeleid naar GitHub om u aan te melden. Voer in dat geval uw GitHub-referenties in.

4. Wanneer de lijst met opslagplaatsen wordt weergegeven, selecteert u uw opslagplaats.

5. U wordt mogelijk omgeleid naar GitHub om de Azure Pipelines-app te installeren. Als dat het zo is, selecteert u Goedkeuren en installeren.

6. Wanneer het tabblad Configureren wordt weergegeven, selecteert u ASP.NET Core.

7. Wanneer uw nieuwe pijplijn wordt weergegeven, bekijkt u de YAML om te zien wat deze doet. Wanneer u klaar bent, selecteert u Opslaan en uitvoeren.

Klassiek

Ga als volgt aan de slag:

1. Maak een pijplijn en selecteer de ASP.NET Core-sjabloon . Met deze selectie worden automatisch de taken toegevoegd die nodig zijn om de code in de voorbeeldopslagplaats te bouwen.

2. Sla de pijplijn op en zet een build in de wachtrij om deze in actie te zien.

   De ASP.NET Core-pijplijnsjabloon publiceert het ZIP-implementatiebestand als een Azure-artefact voor de implementatietaak later.

2. De implementatietaak toevoegen

YAML

1. Klik op het einde van het YAML-bestand en selecteer Assistent weergeven.'

2. Gebruik de taakassistent om de Azure-web-app-taak toe te voegen.

   

   U kunt ook de taak Azure-app Service Deploy (AzureRmWebAppDeployment) toevoegen.

3. Kies uw Azure-abonnement. Zorg ervoor dat u uw verbinding autoriseert . De autorisatie maakt de vereiste serviceverbinding.

4. Selecteer het app-type, de app-naam en de runtimestack op basis van uw App Service-app. Uw volledige YAML moet er ongeveer uitzien als de volgende code.

   variables:
     buildConfiguration: 'Release'
   
   steps:
   - script: dotnet build --configuration $(buildConfiguration)
     displayName: 'dotnet build $(buildConfiguration)'
   - task: DotNetCoreCLI@2
     inputs:
       command: 'publish'
       publishWebProjects: true
   - task: AzureWebApp@1
     inputs:
       azureSubscription: '<service-connection-name>'
       appType: 'webAppLinux'
       appName: '<app-name>'
       package: '$(System.DefaultWorkingDirectory)/**/*.zip'
   

   • azureSubscription: naam van de geautoriseerde serviceverbinding met uw Azure-abonnement.
   • appName: naam van uw bestaande app.
   • pakket: Bestandspad naar het pakket of een map met de inhoud van uw app-service. Jokertekens worden ondersteund.

Klassiek

Ga als volgt aan de slag:

1. Maak een release-pijplijn door Releases te selecteren in het linkermenu en Nieuwe pijplijn te selecteren.

2. Selecteer de Azure-app Service-implementatiesjabloon voor uw fase. Hiermee worden automatisch de benodigde taken toegevoegd.

   Notitie

   Als u een Node.js-app implementeert in App Service in Windows, selecteert u de sjabloon Deploy Node.js App to Azure-app Service. Het enige verschil tussen deze sjablonen is dat Node.js sjabloon de taak configureert voor het genereren van een web.config-bestand met een parameter waarmee de iisnode-service wordt gestart.

3. Als u deze release-pijplijn wilt koppelen aan het Azure-artefact uit de vorige stap, selecteert u Een artefactbuild> toevoegen.

4. Selecteer in Bron (build-pijplijn) de build-pijplijn die u in de vorige sectie hebt gemaakt en selecteer vervolgens Toevoegen.

5. Sla de release-pijplijn op en maak een release om deze in actie te zien.

Voorbeeld: Een .NET-app implementeren

YAML

Als u een .zip-webpakket (bijvoorbeeld van een ASP.NET-web-app) naar een Azure-web-app wilt implementeren, gebruikt u het volgende codefragment om de build te implementeren in een app.

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: true
- task: AzureWebApp@1
  inputs:
    azureSubscription: '<service-connection-name>'
    appType: 'webAppLinux'
    appName: '<app-name>'
    package: '$(System.DefaultWorkingDirectory)/**/*.zip'

• azureSubscription: uw Azure-abonnement.
• appType: uw web-app-type.
• appName: de naam van uw bestaande app-service.
• pakket: het bestandspad naar het pakket of een map met de inhoud van uw app-service. Jokertekens worden ondersteund.

Klassiek

Voor klassieke pijplijnen is het het eenvoudigst om build- en releasefasen te definiëren op afzonderlijke pagina's (pijplijnen en releases). Over het algemeen gaat u het volgende doen:

• Bouw en test uw app op de pagina Pijplijnen met behulp van de sjabloon van uw keuze, zoals ASP.NET Core, Node.js met Grunt, Maven of anderen, en publiceer een artefact.
• Gebruik op de releasepagina de algemene Azure-app Service-implementatiesjabloon om het artefact te implementeren.

Er kunnen sjablonen zijn voor specifieke programmeertalen waaruit u kunt kiezen.

Voorbeeld: implementeren in een virtuele toepassing

YAML

Uw implementatie gebeurt standaard met de hoofdtoepassing in de Azure-web-app. U kunt implementeren in een specifieke virtuele toepassing met behulp van de VirtualApplication eigenschap van de taak Azure-app Service deploy (AzureRmWebAppDeployment):

- task: AzureRmWebAppDeployment@4
  inputs:
    VirtualApplication: '<name of virtual application>'

• VirtualApplication: de naam van de virtuele toepassing die is geconfigureerd in Azure Portal. Zie Een App Service-app configureren in Azure Portal voor meer informatie.

Klassiek

Uw implementatie gebeurt standaard met de hoofdtoepassing in de Azure-web-app. Als u wilt implementeren naar een specifieke virtuele toepassing, voert u de naam in de eigenschap Virtuele toepassing van de Azure-app Service-implementatietaak in.

Voorbeeld: Implementeren in een site

YAML

In het volgende voorbeeld ziet u hoe u implementeert in een staging-site en vervolgens overwisselt naar een productiesite:

- task: AzureWebApp@1
  inputs:
    azureSubscription: '<service-connection-name>'
    appType: webAppLinux
    appName: '<app-name>'
    deployToSlotOrASE: true
    resourceGroupName: '<name of resource group>'
    slotName: staging
    package: '$(Build.ArtifactStagingDirectory)/**/*.zip'

- task: AzureAppServiceManage@0
  inputs:
    azureSubscription: '<service-connection-name>'
    appType: webAppLinux
    WebAppName: '<app-name>'
    ResourceGroupName: '<name of resource group>'
    SourceSlot: staging
    SwapWithProduction: true

• azureSubscription: uw Azure-abonnement.
• appType: (optioneel) Gebruiken webAppLinux om te implementeren in een web-app in Linux.
• appName: de naam van uw bestaande app-service.
• deployToSlotOrASE: Booleaanse waarde. Implementeren naar een bestaande implementatiesite of Azure-app Service Environment.
• resourceGroupName: naam van de resourcegroep. Vereist als deployToSlotOrASE waar is.
• slotName: de naam van de site, die standaard wordt gebruikt production. Vereist als deployToSlotOrASE waar is.
• pakket: het bestandspad naar het pakket of een map met de inhoud van uw app-service. Jokertekens worden ondersteund.
• SourceSlot: Slot verzonden naar productie wanneer SwapWithProduction waar is.
• SwapWithProduction: Booleaanse waarde. Het verkeer van de bronsite wisselen met productie.

Klassiek

Gebruik de optie Implementeren in Site of App Service Environment in de Azure-web-app-taak om de site op te geven waarop moet worden geïmplementeerd. Als u de sites wilt wisselen, gebruikt u de taak Azure-app Service-beheer.

Voorbeeld: Implementeren in meerdere web-apps

YAML

U kunt taken in uw YAML-bestand gebruiken om een pijplijn met implementaties in te stellen. Met behulp van taken kunt u de volgorde van implementatie in meerdere web-apps beheren.

jobs:
- job: buildandtest
  pool:
    vmImage: ubuntu-latest
 
  steps:
  # publish an artifact called drop
  - task: PublishPipelineArtifact@1
    inputs:
      targetPath: '$(Build.ArtifactStagingDirectory)' 
      artifactName: drop
  
  # deploy to Azure Web App staging
  - task: AzureWebApp@1
    inputs:
      azureSubscription: '<service-connection-name>'
      appType: <app type>
      appName: '<staging-app-name>'
      deployToSlotOrASE: true
      resourceGroupName: <group-name>
      slotName: 'staging'
      package: '$(Build.ArtifactStagingDirectory)/**/*.zip'

- job: deploy
  dependsOn: buildandtest
  condition: succeeded()

  pool: 
    vmImage: ubuntu-latest  
  
  steps:
    # download the artifact drop from the previous job
  - task: DownloadPipelineArtifact@2
    inputs:
      source: 'current'
      artifact: 'drop'
      path: '$(Pipeline.Workspace)'

  - task: AzureWebApp@1
    inputs:
      azureSubscription: '<service-connection-name>'
      appType: <app type>
      appName: '<production-app-name>'
      resourceGroupName: <group-name>
      package: '$(Pipeline.Workspace)/**/*.zip'

Klassiek

Als u wilt implementeren in meerdere web-apps, voegt u fasen toe aan uw release-pijplijn. U kunt de volgorde van de implementatie beheren. Zie Fasen voor meer informatie.

Voorbeeld: Variabelen vervangen

Voor de meeste taalstacks kunnen app-instellingen en verbindingsreeks s tijdens runtime worden ingesteld als omgevingsvariabelen.

Maar er zijn andere redenen waarom u variabelen wilt vervangen door uw Web.config. In dit voorbeeld bevat uw Web.config-bestand een verbindingsreeks met de naam connectionString. U kunt de waarde ervan wijzigen voordat u implementeert in elke web-app. U kunt dit doen door een Web.config-transformatie toe te passen of door variabelen in uw Web.config-bestand te vervangen.

YAML

In het volgende fragment ziet u een voorbeeld van het vervangen van variabelen met behulp van de taak Azure-app Service Deploy (AzureRmWebAppDeployment):

jobs:
- job: test
  variables:
    connectionString: <test-stage connection string>
  steps:
  - task: AzureRmWebAppDeployment@4
    inputs:
      azureSubscription: '<Test stage Azure service connection>'
      WebAppName: '<name of test stage web app>'
      enableXmlVariableSubstitution: true

- job: prod
  dependsOn: test
  variables:
    connectionString: <prod-stage connection string>
  steps:
  - task: AzureRmWebAppDeployment@4
    inputs:
      azureSubscription: '<Prod stage Azure service connection>'
      WebAppName: '<name of prod stage web app>'
      enableXmlVariableSubstitution: true

Klassiek

Wijzigen connectionString met behulp van variabele vervanging:

1. Maak een release-pijplijn met twee fasen.
2. Koppel het artefact van de release aan de build die het webpakket produceert.
3. Definiëren connectionString als een variabele in elk van de fasen. Stel de juiste waarde in.
4. Selecteer de optie voor het vervangen van XML-variabelen onder Bestandstransformaties en Opties voor het vervangen van variabelen voor de taak Azure-app Service Deploy.

Voorbeeld: Voorwaardelijk implementeren

YAML

U kunt dit doen in YAML door een van de volgende technieken te gebruiken:

• Isoleer de implementatiestappen in een afzonderlijke taak en voeg een voorwaarde toe aan die taak.
• Voeg een voorwaarde toe aan de stap.

In het volgende voorbeeld ziet u hoe u stapvoorwaarden gebruikt om alleen builds te implementeren die afkomstig zijn van de hoofdbranch:

- task: AzureWebApp@1
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  inputs:
    azureSubscription: '<service-connection-name>'
    appName: '<app-name>'

Zie Voorwaarden opgeven voor meer informatie over voorwaarden.

Klassiek

In uw release-pijplijn kunt u verschillende controles en voorwaarden implementeren om de implementatie te beheren:

• Stel vertakkingsfilters in om de trigger voor continue implementatie te configureren op het artefact van de release-pijplijn.
• Goedkeuringen vóór de implementatie instellen als voorwaarde voor implementatie in een fase.
• Configureer poorten als voorwaarde voor implementatie naar een fase.
• Geef voorwaarden op voor het uitvoeren van een taak.

Zie Release-, vertakkings- en fasetriggers, Release-implementatiebeheer met behulp van goedkeuringen, Release-implementatiebeheer met behulp van poorten en Voorwaarden opgeven voor het uitvoeren van een taak voor meer informatie.

Voorbeeld: implementeren met behulp van Web Deploy

De taak Azure-app Service deploy (AzureRmWebAppDeployment) kan implementeren in App Service met behulp van Web Deploy.

YAML

trigger:
- main

pool:
  vmImage: windows-latest

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration $(buildConfiguration)'
    zipAfterPublish: true
- task: AzureRmWebAppDeployment@4
  inputs:
    ConnectionType: 'AzureRM'
    azureSubscription: '<service-connection-name>'
    appType: 'webApp'
    WebAppName: '<app-name>'
    packageForLinux: '$(System.DefaultWorkingDirectory)/**/*.zip'
    enableCustomDeployment: true
    DeploymentType: 'webDeploy'

Klassiek

In de release-pijplijn, ervan uitgaande dat u de Azure-app Service-implementatiesjabloon gebruikt:

1. Selecteer het tabblad Taken en selecteer vervolgens Implementeren Azure-app Service. Dit is de AzureRmWebAppDeployment taak.

2. Controleer in het dialoogvenster of Verbinding maken type is ingesteld op Azure Resource Manager.

3. Vouw in het dialoogvenster Aanvullende implementatieopties uit en selecteer Implementatiemethode selecteren. Zorg ervoor dat Web Deploy is geselecteerd als de implementatiemethode.

4. Sla de release-pijplijn op.

Notitie

Met de AzureRmWebAppDeployment@3 en AzureRmWebAppDeployment@4 taken moet u het verbindingstype Van Azure Resource Manager gebruiken, of AzureRM, wanneer u implementeert met Web Deploy. Het maakt gebruik van publicatieprofielen voor implementatie wanneer basisverificatie is ingeschakeld voor uw app, maar gebruikt de veiligere Entra ID-verificatie wanneer basisverificatie is uitgeschakeld.

Veelgestelde vragen

Wat is het verschil tussen de AzureWebApp en AzureRmWebAppDeployment taken?

De Azure Web App-taak (AzureWebApp) is de eenvoudigste manier om te implementeren in een Azure-web-app. Uw implementatie gebeurt standaard met de hoofdtoepassing in de Azure-web-app.

De Azure-app Service Deploy-taak (AzureRmWebAppDeployment) kan meer aangepaste scenario's verwerken, zoals:

• Wijzig de configuratie-instellingen in webpakketten en XML-parametersbestanden.
• Implementeren met Web Deploy, als u gewend bent aan het IIS-implementatieproces.
• Implementeren in virtuele toepassingen.
• Implementeren naar andere app-typen, zoals container-apps, functie-apps, webtaken of API- en mobiele apps.

Notitie

Bestandstransformaties en het vervangen van variabelen worden ook ondersteund door de afzonderlijke taak Bestandstransformatie voor gebruik in Azure Pipelines. U kunt de taak Bestandstransformatie gebruiken om bestandstransformaties en variabele vervangingen toe te passen op configuratie- en parameterbestanden.

Ik krijg het bericht 'Ongeldig App Service-pakket of mappad opgegeven'.

Afhankelijk van uw pijplijn komen er in YAML-pijplijnen mogelijk niet overeen tussen waar uw ingebouwde webpakket wordt opgeslagen en waar de implementatietaak ernaar op zoek is. De taak haalt bijvoorbeeld AzureWebApp het webpakket op voor implementatie. De AzureWebApp-taak zoekt bijvoorbeeld in $(System.DefaultWorkingDirectory)/**/*.zip. Als het webpakket ergens anders wordt neergezet, wijzigt u de waarde van package.

Ik krijg het bericht 'Publiceren met webdeploy-opties worden alleen ondersteund bij het gebruik van Windows-agent'.

Deze fout treedt op in de AzureRmWebAppDeployment-taak wanneer u de taak configureert voor implementatie met webimplementatie, maar uw agent wordt niet uitgevoerd op Windows. Controleer of uw YAML iets vergelijkbaars heeft met de volgende code:

pool:
  vmImage: windows-latest

Web Deploy werkt niet wanneer ik basisverificatie uitschakelt

Zie voor informatie over het oplossen van problemen met microsoft Entra ID-verificatie om met de AzureRmWebAppDeployment taak te werken, zie ik geen webimplementatie in mijn Azure-app-service met behulp van Microsoft Entra ID-verificatie van mijn Windows-agent

Volgende stappen

• Pas uw Azure DevOps-pijplijn aan.