I'm trying to set up a release pipeline in Azure DevOps Server 2020. I need to deploy my application files, which are contained in a zip file to a specific subfolder on a remote server. I'm having a hard time trying to figure out how to make sure my application files are extracted into the right folder. There isn't an option for this in the Web App Deploy task.
Here is my Web Deploy Task in YAML:
- task: IISWebAppDeploymentOnMachineGroup#0
displayName: 'Deploy to Dev'
inputs:
WebSiteName: 'DevServer'
Package: '$(System.DefaultWorkingDirectory)/_ProdBuild/finalbuild.zip'
TakeAppOfflineFlag: True
XmlVariableSubstitution: True
I also looked on the page where I set up the Deployment Group and there's no setting for deploying to a subfolder.
This is my first time setting up a release pipeline in Azure DevOps. Any help would be appreciated.
To set the deployment path in Pipeline, you need to add the IIS web app manage task(IISWebAppManagementOnMachineGroup#0) before the IISWebAppDeploymentOnMachineGroup task .
You could define the task input: WebsitePhysicalPath: 'localsubfolderpath'
Here is an example:
- task: IISWebAppManagementOnMachineGroup#0
displayName: 'IIS Web App Manage'
inputs:
WebsiteName: test
WebsitePhysicalPath: 'C:\inetpub\wwwroot1'
AddBinding: True
Bindings: '{"bindings":[{"protocol":"http","ipAddress":"All Unassigned","port":"88","hostname":"","sslThumbprint":"","sniFlag":false}]}'
CreateOrUpdateAppPoolForWebsite: true
AppPoolNameForWebsite: test
ParentWebsiteNameForVD: test
ParentWebsiteNameForApplication: test
Please refer to this doc about IIS Web App Manage task
I am being tasked to work on Azure DevOps implementation of an existing legacy application. Application has a QA team which uses 500+ automated test cases. This test cases have been developed using Protractor.
All test cases are developed using JavaScript.
With Existing setup, below are the steps taken:
a. release pipeline deploys an ASP.NET application to Azure app services
b. QA person manually logs on to the VM and initiates the protractor tests.
Can we use any tasks from Azure devOps pipeline to test the same deployed application?
Can we use any tasks from Azure devOps pipeline to test the same deployed application?
To run the test with Protractor, you can use the Command Line task with node tool to run the test.
If you want to use the Microsoft-hosted agent to run the test, you need to install the appropriate version of the node tool and protractor package before running the test.
Here is an example:
steps:
- task: NodeTool#0
displayName: 'Use Node 10.x'
inputs:
versionSpec: 10.x
- task: Npm#1
displayName: 'npm install'
inputs:
workingDir: EndToEndTests/EndToEndTests
verbose: false
- script: 'node $(build.sourcesdirectory)/EndToEndTests/EndToEndTests/node_modules/protractor/bin/webdriver-manager update --versions.chrome=xxxx.x.x.x'
displayName: 'Command Line Script'
- script: |
npm run e2e #Run the same script as you are on the VM
displayName: 'Command Line Script'
For more detaield info, you could refer to this blog or this ticket .
On the other hand, if your test cases requires more additional configuration, you can also install a self-hosted agent on the VM.
In this case, the QA person don't need to log on the VM. They could directly run the Pipeline tasks on the self-hosted agent(create on the VM). This is equivalent to testing on the VM.
I am having trouble understanding and getting the build/release pipelines setup for deploying a NestJS application to Azure DevOps (ADO).
I am deploying to a Linux Web App hosted in Azure.
As far as I understand, if I run the app locally using something like npm run start, it creates a dist folder under my root project directory.
So, when writing the YAML for the build and deployment. My thought process is to:
Run an NPM update.
Run npm run build to build the application and generate the dist folder.
Copy the contents of the application (or just the dist folder?) into the target folder (/home/site/wwwroot)
Run npm run start:prod to start the server.
Here is my YAML so far:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UseNode#1
inputs:
version: '14.x'
checkLatest: true
- task: Npm#0
displayName: Run NPM Update for NestJS
inputs:
cwd: '$(Build.SourcesDirectory)/ProjectName'
command: update
- task: Npm#0
displayName: Build NestJS
inputs:
cwd: '$(Build.SourcesDirectory)/ProjectName'
command: run
arguments: "build"
- task: CopyFiles#2
inputs:
Contents: 'dist/**'
TargetFolder: '$(Build.ArtifactStagingDirectory)'
The issue is after the build process completes, I do not see a dist folder in /home/site/wwwroot/ProjectName. Can someone help me out with what I am missing?
Also, a side noob-y question about Azure DevOps, what does $(Build.SourcesDirectory) and $(Build.ArtifactStagingDirectory) refer to and how and where are those environment variables set?
To deploy your app to the hosted in Azure. You need to use Azure App Service Deploy task or Azure Web App task.
Azure devops is the tool to build and deploy your app to your server(eg. the Linux Web App on Azure), it is not for hosting your app.
$(Build.ArtifactStagingDirectory) refer to the folder of the agent machine which runs your pipeline. (When your run your pipeline, it pick up a agent defined in pool to run your pipeline tasks)
The mapping to the folders in the agent machine is showing as below screenshot. Check the predefined variables for more information.
$(Agent.BuildDirectory) is mapped to c:\agent_work\1
$(Build.ArtifactStagingDirectory) is mapped to c:\agent_work\1\a
$(Build.BinariesDirectory) is mapped to c:\agent_work\1\b
$(Build.SourcesDirectory) is mapped to c:\agent_work\1\s
So back to the question how to deploying a NestJS application to Azure?
First you need to create a service connection in Azure devops to connect to your azure subscription. Check here for detailed steps.
Then add Azure App Service Deploy task/Azure Web App task to the end of your pipeline. See below example:
- task: AzureRmWebAppDeployment#4
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'SubscriptionServiceConnectionName'
appType: 'webAppLinux'
WebAppName: 'MyWebAppName'
Package: '$(Build.ArtifactStagingDirectory)/dist/'
StartupCommand: 'npm run start:prod'
You can check here for more information.
Today we experienced the following message in Azure Portal
WebJob cannot be added from portal if deployment form source control is configured.
We assume that this is a new feature hence the spelling is incorrect: 'deployment form source control' should be 'deployment from source control'.
I have no clue where to set a setting that solved this.
It has to be somewhere in DevOps we assume.
We solved it by not disconnecting a pipeline.
We solved it by implementing a seperate WebJob Build/Release Pipeline.
Here are the steps that worked for us:
In Azure Portal
Create a virtual application in your app service
In DevOps
In your build pipeline
Important Notice: add the following Argument: --output $(build.artifactstagingdirectory) to the build step.
In your release pipeline
This deploys the WebJob to the correct directory. In our case: $(System.DefaultWorkingDirectory)/_ms-reporting-webjob-dev-CI/drop
Having a look at the Kudo Console in our App Service the file location for our WebJob is:
Kudu Console
The workaround that worked for me was uploading the webjob directly via the Kudu Console.
Open the Kudu Console by selecting "Advanced Tool" --> "Go" in Your App Service on the Azure Portal.
Once on the Kudu portal open a "Debug Console" --> "CMD"
Go to the directory for your webjobs: "d:\home\site\wwwroot\app_data\jobs\continuous\{job name}" (https://github.com/projectkudu/kudu/wiki/WebJobs)
Then drag and drop the .zip file you prepared to upload your webjob (https://github.com/projectkudu/kudu/wiki/Kudu-console)
The job will now be listed on the Azure Portal and be started.
I used the following physical path in the Virtual Application and it solved it for us
site\wwwroot\App_Data\jobs\triggered\jobname
We had the same issue and noticed there was an old deployment pipeline connected to our web job in the Deployment Center blade. Disconnecting this solved the problem for us and we were able to manually deploy.
I used Kudu console to upload the webjobs
You can go to the path D:\home\site\wwwroot\App_Data\jobs\ and then upload the webjob folder here and then this shows up in your Webjobs portal as well
Don't go for the new CICD pipeline creation of this issue. Don't use chrome/safer while disconnecting the deployment center. Please use the latest IE or Microsoft Edge. it will allow the disconnect of the deployment center. I am able to do that in Microsoft Edge.
We had the same issue, and there was default configuration in deployment center for my web application, but we are not deploying the code from reposiotry, so we disabled that option. We are deploying web application from visual studio.
Currently the image showing disabled repository options in deployment center of the web application.
Probably because You set CI/CD for your web app deployment.
If you set your deployment with Azure Devops pipelines, and you are doing the yaml file approach, then maybe this is what you are looking for.
firstly you need to set the branch that you want to be triggred when a new commit has been pushed to it.
trigger:
branches:
include:
- refs/heads/staging
variables:
BuildConfiguration: 'Release'
pr: none # Disable pull request triggers.
To make our pipeline a little bit organized, We will work with stages, let's create our Build stage, here I am building a .Net app, you can replace the build task with the build you want.
stages:
- stage: 'Build'
jobs:
- job: 'Build'
pool:
vmImage: 'windows-latest' #The agent that will be used to start this stage
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: build
projects: 'MySuperApp/BackgroundService.csproj'
arguments: '--configuration $(BuildConfiguration)'
then I will run dotnet publish, that publishes the application and its dependencies to a folder for deployment to a hosting system.
and here comes the important part, when you create a webjob from azure portal, its files are stored under specific folder.
for Continuous webjobs, it will be stored under \site\wwwroot\app_data\Jobs\Continuous
and for Triggered webjobs it will be under \site\wwwroot\app_data\Jobs\Triggered
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: 'publish'
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
projects: 'MySuperApp/BackgroundService.csproj'
publishWebProjects: false
zipAfterPublish: false
modifyOutputPath: false
for me I need to deploy a continuous webjob, as you can see in the arguments within inputs:
--output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
the dotnet publish will put the generated files under $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS
then I will zip the content of $(Build.ArtifactStagingDirectory)/publish_output/ which is App_Data/jobs/continuous/MySuperAppBGS
- task: ArchiveFiles#2
displayName: 'Zip Published Files'
inputs:
rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/publish_output'
includeRootFolder: false
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/MySuperAppAPIBackgroundService.zip'
replaceExistingArchive: true
and publish the content of $(Build.ArtifactStagingDirectory) to drop artifact, which our zip file exist MySuperAppAPIBackgroundService.zip, in order to use it, in the next stage
- task: PublishBuildArtifacts#1
displayName: 'Publish Build artifacts'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
Here is the second stage, that will deploy our zip file to the web app service, then it will be unzipped leaving
App_Data/jobs/continuous/MySuperAppBGS/* under \site\wwwroot\
- stage: 'Deploy'
jobs:
- deployment: 'Deploy'
environment: 'MySuperAppAPI_BackGround_Staging_env' #just an env variable, that will be used later if you want, give it whatever name you like
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp#1
displayName: 'Deploy MySuperAppAPIBackgroundService.zip to MySuperAppAPI-Staging-BackgroundService'
inputs:
azureSubscription: 'Your Azure service connection'
appType: 'webApp'
appName: 'MySuperAppAPI-Staging-BackgroundService'
package: '$(Pipeline.Workspace)/drop/MySuperAppAPIBackgroundService.zip'
deploymentMethod: 'zipDeploy'
Note: in the second stage, I didn't call DownloadBuildArtifacts#0 task, because I used deploy: within - deployment: job that auto inject the Download artifact task, and to access the published Artifact from the previous stage, you use $(Pipeline.Workspace) following by the artifact name you provided, in my case it is $(Pipeline.Workspace)/drop
Hope I was clear, for any clarification don't hesitate to ask me.
I am getting the following error while developing node js app to app service using azure-dev
##[error]Error: EMFILE: too many open files, open 'C:\agent\_work\_temp\temp_web_package_05489241004778522\node_modules\tar-fs\test\fixtures\d\file1'
I am deploying using windows hosted agent
Please find the task YAML file
steps:
- task: AzureRmWebAppDeployment#3 displayName: 'Azure App Service Deploy: <>' inputs:
azureSubscription: <>
appType: api
WebAppName: 'DEV-BIZ-API'
DeployToSlotFlag: true
ResourceGroupName: '<>'
SlotName: temp
GenerateWebConfig: true
WebConfigParameters: '-Handler iisnode -NodeStartFile app.js -appType node'
AppSettings: '-NODE_ENV dev'
ConfigurationSettings: '-NODE_ENV dev'
TakeAppOfflineFlag: true
UseWebDeploy: true
RenameFilesFlag: true
too many open files azure DevOps pipeline
There is a known issue about this on Github.
For windows, this issue is resolved with 2.117.1 agent version.
If your agent version is higher than 2.117.1, but you still have this issue, you can try to the workaround:
Provide the extracted package path as input for App Service Deploy
task
Use Post Deployment script feature to install app dependencies.
Note:You can also add your detailed info on the thread on the github, and check the feedback there.
Hope this helps.