Continue levering met Azure Pipelines
Gebruik Azure Pipelines om automatisch te implementeren in Azure Functions. 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 AzureFunctionApp
taak om te implementeren in Azure Functions. Er zijn nu twee versies van de AzureFunctionApp-taak (AzureFunctionApp@1, AzureFunctionApp@2). AzureFunctionApp@2
bevat verbeterde validatieondersteuning waardoor pijplijnen minder waarschijnlijk mislukken vanwege fouten.
Kies uw taakversie bovenaan het artikel. YAML-pijplijnen zijn niet beschikbaar voor Azure DevOps 2019 en eerder.
Vereisten
een Azure DevOps-organisatie. Als u geen account hebt, kunt u er gratis een maken. Als uw team er al een heeft, controleert u of u een beheerder bent van het Azure DevOps-project dat u wilt gebruiken.
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.
Als u Van plan bent GitHub te gebruiken in plaats van Azure-opslagplaatsen, hebt u ook een GitHub-opslagplaats nodig. Als u geen GitHub-account hebt, kunt u er gratis een maken.
Een bestaande functie-app in Azure met de broncode in een ondersteunde opslagplaats. Als u nog geen Azure Functions-codeproject hebt, kunt u er een maken door het volgende taalspecifieke artikel te voltooien:
Vergeet niet om het lokale codeproject te uploaden naar uw GitHub- of Azure-opslagplaats nadat u het naar uw functie-app hebt gepubliceerd.
Uw app compileren
- Meld u aan bij uw Azure DevOps-organisatie en navigeer naar uw project.
- Navigeer in het project naar de pagina Pijplijnen. Selecteer vervolgens Nieuwe pijplijn.
- Selecteer een van deze opties voor Waar is uw code?:
- GitHub: U wordt mogelijk omgeleid naar GitHub om u aan te melden. Voer in dat geval uw GitHub-referenties in. Wanneer deze verbinding uw eerste GitHub-verbinding is, begeleidt de wizard u ook bij het verbinden van DevOps met uw GitHub-accounts.
- Git voor Azure-opslagplaatsen: u kunt direct een opslagplaats kiezen in uw huidige DevOps-project.
- Wanneer de lijst met opslagplaatsen wordt weergegeven, selecteert u de voorbeeld-app-opslagplaats.
- Azure Pipelines analyseert uw opslagplaats en in Uw pijplijn configureren bevat een lijst met mogelijke sjablonen. Kies de juiste sjabloon voor de functie-app voor uw taal. Als u de juiste sjabloon niet ziet, selecteert u Meer weergeven.
- Selecteer Opslaan en uitvoeren, selecteer vervolgens Rechtstreeks doorvoeren naar de hoofdbranch, en kies ten slotte opnieuw Opslaan en uitvoeren.
- Er wordt een nieuwe run gestart. Wacht totdat de uitvoering is voltooid.
Voorbeelden van YAML-buildpijplijnen
De volgende taalspecifieke pijplijnen kunnen worden gebruikt voor het bouwen van apps.
U kunt het volgende voorbeeld gebruiken om een YAML-bestand te maken om een .NET-app te bouwen.
Als er fouten optreden bij het bouwen van uw app, controleert u of de versie van .NET die u gebruikt overeenkomt met uw Azure Functions-versie. Raadpleeg Overzicht van Azure Functions-runtime voor meer informatie.
pool:
vmImage: 'windows-latest'
steps:
- script: |
dotnet restore
dotnet build --configuration Release
- task: DotNetCoreCLI@2
inputs:
command: publish
arguments: '--configuration Release --output publish_output'
projects: '*.csproj'
publishWebProjects: false
modifyOutputPath: false
zipAfterPublish: false
- task: ArchiveFiles@2
displayName: "Archive files"
inputs:
rootFolderOrFile: "$(System.DefaultWorkingDirectory)/publish_output"
includeRootFolder: false
archiveFile: "$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip"
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip'
artifactName: 'drop'
Uw app implementeren
U implementeert met de taak Implementeren van de Azure-functie-app. Voor deze taak is een Azure-serviceverbinding als invoer vereist. Met een Azure-serviceverbinding worden de referenties opgeslagen om vanuit Azure Pipelines verbinding te maken met Azure.
Als u wilt implementeren in Azure Functions, voegt u het volgende codefragment toe aan het einde van het azure-pipelines.yml
bestand. De standaardwaarde appType
is Windows. U kunt Linux opgeven door het appType
in te stellen op functionAppLinux
. Implementeren in een Flex Consumption-app wordt niet ondersteund met @v1 de AzureFunctionApp-taak.
trigger:
- main
variables:
# Azure service connection established during pipeline creation
azureSubscription: <Name of your Azure subscription>
appName: <Name of the function app>
# Agent VM image name
vmImageName: 'ubuntu-latest'
- task: AzureFunctionApp@1 # Add this at the end of your file
inputs:
azureSubscription: <Azure service connection>
appType: functionAppLinux # default is functionApp
appName: $(appName)
package: $(System.ArtifactsDirectory)/**/*.zip
#Uncomment the next lines to deploy to a deployment slot
#Note that deployment slots is not supported for Linux Dynamic SKU
#deployToSlotOrASE: true
#resourceGroupName: '<Resource Group Name>'
#slotName: '<Slot name>'
In het fragment wordt ervan uitgegaan dat de buildstappen in uw YAML-bestand het zip-archief produceren in de $(System.ArtifactsDirectory)
map op uw agent.
Een container implementeren
U kunt uw code automatisch implementeren als een containerfunctie-app na elke geslaagde build. Zie Werken met containers en Azure Functions voor meer informatie over containers.
De eenvoudigste manier om te implementeren in een container is het gebruik van de Azure Function-app op containerimplementeertaak.
Als u wilt implementeren, voegt u het volgende fragment toe aan het einde van uw YAML-bestand:
trigger:
- main
variables:
# Container registry service connection established during pipeline creation
dockerRegistryServiceConnection: <Docker registry service connection>
imageRepository: <Name of your image repository>
containerRegistry: <Name of the Azure container registry>
dockerfilePath: '$(Build.SourcesDirectory)/Dockerfile'
tag: '$(Build.BuildId)'
# Agent VM image name
vmImageName: 'ubuntu-latest'
- task: AzureFunctionAppContainer@1 # Add this at the end of your file
inputs:
azureSubscription: '<Azure service connection>'
appName: '<Name of the function app>'
imageName: $(containerRegistry)/$(imageRepository):$(tag)
Het codefragment pusht de Docker-installatiekopieën naar uw Azure Container Registry. De Azure Function-app op containerimplementeertaak haalt de juiste Docker-installatiekopie op die overeenkomt met de BuildId
opgegeven opslagplaats en implementeert vervolgens de installatiekopie.
Zie dit voorbeeld van de implementatie van een Azure Pipelines-container voor een volledig voorbeeld van een end-to-end-pijplijn, waaronder het bouwen van de container en het publiceren naar het containerregister.
Implementeren in een site
U kunt uw functie-app zo configureren dat er meerdere sites zijn. Met sites kunt u uw app veilig implementeren en testen voordat u deze beschikbaar maakt voor uw klanten.
In het volgende YAML-fragment ziet u hoe u implementeert in een staging-site en vervolgens wisselt naar een productiesite:
- task: AzureFunctionApp@1
inputs:
azureSubscription: <Azure service connection>
appType: functionAppLinux
appName: <Name of the Function app>
package: $(System.ArtifactsDirectory)/**/*.zip
deployToSlotOrASE: true
resourceGroupName: <Name of the resource group>
slotName: staging
- task: AzureAppServiceManage@0
inputs:
azureSubscription: <Azure service connection>
WebAppName: <name of the Function app>
ResourceGroupName: <name of resource group>
SourceSlot: staging
SwapWithProduction: true
Een pijplijn maken met Azure CLI
Gebruik de az functionapp devops-pipeline create
opdracht om een build-pijplijn te maken in Azure. De build-pijplijn wordt gemaakt om codewijzigingen te bouwen en vrij te geven die in uw opslagplaats worden aangebracht. Met de opdracht wordt een nieuw YAML-bestand gegenereerd dat de build- en release-pijplijn definieert en het vervolgens doorvoert naar uw opslagplaats. De vereisten voor deze opdracht zijn afhankelijk van de locatie van uw code.
Als uw code zich in GitHub bevindt:
U moet schrijfmachtigingen hebben voor uw abonnement.
U moet de projectbeheerder zijn in Azure DevOps.
U moet beschikken over machtigingen om een persoonlijk GitHub-toegangstoken (PAT) te maken met voldoende machtigingen. Zie de machtigingsvereisten voor GitHub PAT voor meer informatie.
U moet machtigingen hebben om door te voeren naar de hoofdbranch in uw GitHub-opslagplaats, zodat u het automatisch gegenereerde YAML-bestand kunt doorvoeren.
Als uw code zich in Azure-opslagplaatsen bevindt:
U moet schrijfmachtigingen hebben voor uw abonnement.
U moet de projectbeheerder zijn in Azure DevOps.
Uw app compileren
- Meld u aan bij uw Azure DevOps-organisatie en navigeer naar uw project.
- Navigeer in het project naar de pagina Pijplijnen. Kies vervolgens de actie om een nieuwe pijplijn te maken.
- Doorloop de stappen van de wizard door eerst GitHub te selecteren als de locatie van de broncode.
- U wordt mogelijk omgeleid naar GitHub om u aan te melden. Voer in dat geval uw GitHub-referenties in.
- Wanneer de lijst met opslagplaatsen wordt weergegeven, selecteert u de voorbeeld-app-opslagplaats.
- Azure Pipelines analyseert uw opslagplaats en raadt een sjabloon aan. Selecteer Opslaan en uitvoeren, selecteer vervolgens Rechtstreeks doorvoeren naar de hoofdbranch, en kies ten slotte opnieuw Opslaan en uitvoeren.
- Er wordt een nieuwe run gestart. Wacht totdat de uitvoering is voltooid.
Voorbeelden van YAML-buildpijplijnen
De volgende taalspecifieke pijplijnen kunnen worden gebruikt voor het bouwen van apps.
U kunt het volgende voorbeeld gebruiken om een YAML-bestand te maken om een .NET-app te bouwen:
pool:
vmImage: 'windows-latest'
steps:
- script: |
dotnet restore
dotnet build --configuration Release
- task: DotNetCoreCLI@2
inputs:
command: publish
arguments: '--configuration Release --output publish_output'
projects: '*.csproj'
publishWebProjects: false
modifyOutputPath: false
zipAfterPublish: false
- task: ArchiveFiles@2
displayName: "Archive files"
inputs:
rootFolderOrFile: "$(System.DefaultWorkingDirectory)/publish_output"
includeRootFolder: false
archiveFile: "$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip"
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip'
artifactName: 'drop'
Uw app implementeren
U implementeert met de Azure Function App Deploy v2-taak . Voor deze taak is een Azure-serviceverbinding als invoer vereist. Met een Azure-serviceverbinding worden de referenties opgeslagen om vanuit Azure Pipelines verbinding te maken met Azure. U moet een verbinding maken die gebruikmaakt van federatie van workloadidentiteit.
De v2-versie van de taak bevat ondersteuning voor nieuwere toepassingenstacks voor .NET, Python en Node. De taak omvat controles voor vooraf implementeren van netwerken. Wanneer er problemen zijn met de implementatie, stopt de implementatie.
Als u wilt implementeren in Azure Functions, voegt u het volgende codefragment toe aan het einde van het azure-pipelines.yml
bestand. De standaardwaarde appType
is Windows. U kunt Linux opgeven door het appType
in te stellen op functionAppLinux
. Voor implementatie in een Flex Consumption-app moet u zowel als appType: functionAppLinux
isFlexConsumption: true
.
trigger:
- main
variables:
# Azure service connection established during pipeline creation
azureSubscription: <SUBSCRIPTION_NAME>
appName: <APP_NAME>
# Agent VM image name
vmImageName: 'windows-latest'
- task: AzureFunctionApp@2 # Add this at the end of your file
inputs:
azureSubscription: <AZURE_SERVICE_CONNECTION>
appType: functionApp # this specifies a Windows-based function app
appName: $(appName)
package: $(System.ArtifactsDirectory)/**/*.zip
deploymentMethod: 'auto' # 'auto' | 'zipDeploy' | 'runFromPackage'. Required. Deployment method. Default: auto.
#Uncomment the next lines to deploy to a deployment slot
#Note that deployment slots is not supported for Linux Dynamic SKU
#deployToSlotOrASE: true
#resourceGroupName: '<RESOURCE_GROUP>'
#slotName: '<SLOT_NAME>'