Delete files from app service as part of Azure DevOps release pipeline - azure

We have an Azure DevOps release pipeline using the deploy azure app service task to deploy an application.
We would like to run a task prior to this deploy task to delete all files in the bin folder of the app service.
We do not want to delete all files on the target, just the ones in the bind folder.
I can't see any obvious task that will enable me to do this. Tasks seem to run in the context of the deployment server rather than the app service and so don't enable access to the app service file system.
What's the best way to do it?

If you are looking to avoid unwanted files then in the Azure App Service Deploy task there is an option "Remove additional files at destination" which while not explicitly deleting the bin folder content will ensure there is no residue from previous releases.

Related

Copy a file from build agent to App Service without using FTP

In my Azure DevOps release pipeline, I want to upload a file from the build agent to app service server. For security reason, FTP is disabled by my organization. Is there a way to achieve this without FTP?
You could try Azure App Service Deploy task to deploy the file to the app service. In this task, set Package or folder argument to the folder path where the file exists.

Copy file to Azure App Service During Release Pipeline

During the Azure Release pipeline, I would like to copy a file in a Git repo to the wwwroot directory in the app service. The output from the task says it copies the file but it is not there. I am thinking I am not specifying the target folder properly. I currently have it as d:\home\site\wwwroot. Thanks for any help.
Copy file to Azure App Service During Release Pipeline
You could not use the copy task to copy a local file to the Azure app service. This task only supports local replication.
When you set it as d:\home\site\wwwroot, the copy task will copy the file to the folder in the agent, which runs this task rather than the Azure app service.
To resolve this issue, you could use Azure App Service Deploy task to deploy this file to the app service. In this task, set "Package or folder" path to the folder where the file exists.
Or you can consider the advice of Leo Varghese, to use the FTP upload task to copy that file to the app service.
Hope this helps.
#Doug, You an make use of the FTP upload task to copy a file in your build artifact to the wwwroot folder. Assuming your file in gitlab is present inside the artifact after the execution of build pipeline.
Please refer this article -> https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/ftp-upload?view=azure-devops
For performing FTP upload you will need your FTP credentials available for your web-app. This can be obtained from the Deployment Center of your web app.
Hope the above answers your question. Please let me know if you have any queries on this.

Can I use VSTS Release Manager to deploy a single web job under my app service without deploying the entire app service?

I have an Azure App Service which contains 5 web jobs. I have VSTS Release Manager set up to deploy the entire app service, which successfully updates my web jobs as well.
However, I want to deploy only a single web job without deploying the entire app service. I have the build set up successfully for the web job. But I am struggling with the configuration of the release pipeline. I've tried two methods:
1. Copy Files
Using this method, I am using $(build.artifactstagingdirectory)/app_data/jobs/triggered/[my-web-job-name] as the target folder. But when I go to find the files in the production environment (using Kudu console), they are not there. Since this completes "successfully", I think the target folder might be set up incorrectly. What target can I specify to get the files in the production environment? (as a side-note, do I need to do something special to have it deploy the contents of the drop.zip file?)
2. Azure App Service Deploy
This method seems to target the entire app service, and not a single web job. I have not tried running it using this method, as I am concerned it might wipe out my entire app service and replace it with my single web job. My thought is that there may be a way to set up a "sub-folder" of the app service to deploy into. But I'm not seeing any setting like that in any of the options. Is there a way to set up the "Azure App Service Deploy" to deploy to a single web job folder?
Or, is there an entirely different way to deploy a single web job?
I think you need to make sure the structure of your artifact matches the subfolders exactly. See here: http://www.bravegeek.com/2016/12/03/Deploy-WebJobs-from-Team-Services/
Relevant part:
In your Build definition, add a Copy Files step after the build step.
Set these properties
Source Folder: src/WebJobTest/bin/$(BuildConfiguration)/
Contents: **
Target Folder: $(build.artifactstagingdirectory)\WebJobTest\App_Data\jobs\continuous\WebJobTest

Adding additional files to VSTS Release to azure web app

I have a release in VSTS to deploy my webapp to the azure app service. For this I use a Azure App Service deploy step. After the normal deploy of the webapp I want to add an additional zip artifact from another build result. I want to copy only those file to a specific path of the web application on azure. How can I do that?
If the zip file is the web deploy package, you can refer to Joy’s answer. (Need to check Application option)
Otherwise, the simple way is using Kudu REST API (remain folder structure), steps:
Uncheck Publish using Web Deploy option of Azure App Service Deploy task
(Optional) Add Unzip task to extract zip files to a folder in artifact folder (the folder that you want in app service, e.g. D:/1/a/mylib)
Specify folder (parent folder of step 2 to remain folder structure) or package (zip) in Package or folder input box
You could use Virtual applications and directories to do it.You could check my steps.
Go to azure portal -> APPLICATION -> APPLICATION SETTINGS->Virtual applications and directories
set virtual directory with virtual path : /YourApplication to site\YourApplicationorsite\wwwroot\YourApplication
Go to VSTS-> the release option-> the Deploy Azure App Service task
set virtual application to /myApplication
Hope it can help you.
If using Azure DevOps for your CI then an alternative solution is to zip your file(s) including directory structure from the web root and add them into DevOps as a 'secure file' (find this under library/secure files once you've configured an Azure KeyVault).
Then add a pipeline task to download the secure file (use "Download secure file" task) to your build server. Make sure you add a "Reference name" to this task so you can reference the downloaded file path in a later step.
Then add a stand-alone "Azure App Service Deploy" step to deploy just this zip file. Select deployment method of "Zip deploy" and reference your downloaded secure file in the "Package or folder" section, like $(secureFileReferenceName.secureFilePath).
This effectively downloads the zip file from secure storage to the build agent and unzips it to wwwroot in the App Service.

Best workflow to restart app service after a git push

Short version: How can I deploy a new version without first manually stopping the app-service?
Long version:
I'm using the following workflow to publish a new version of my ASP.NET Core app to an Azure App-Service.
The App-Service is running on a basic instance. I understand this is not intended for real use but I hope there is a good way to get this workflow running before we go into production(standard instance).
This works but how can I avoid step 4 to 7?
Publish the solution into a local folder.
Move the published content into a local git repo.
Commit all files and push to the app-service.
Stop the app-service from the portal
Enter the console and delete all files in the wwwroot folder
Redeploy the commit from the portal
Start the app-service
I was hoping that the push in step 3 would automatically trigger the remaining steps.
After step 3 I can see that the files have been updated, the new static files are served to the browser but the old binary is still running.
Similarly I can switch between deployment slots on the portal. I get the new static files served but the previous deployed binary is still answering all calls.
This doesn't work, the static files are changed but the old binary is still responding to calls.
Redeploy from portal
Restart app-service
The old binary is still served.
This works.
Stop app-service
Deploy from portal
Start app-service
It appears the running binary is blocking the deployment.
How can I automate deployment using git push or from the portal without manually having to stop the service?
Application settings:
You need to enable msdeploy flag MSDEPLOY_RENAME_LOCKED_FILES=1 in Azure App Service application settings. The option if set enables msdeploy to rename locked files that are locked during app deployment
Click application settings and scroll down until you see app settings.
set this key: MSDEPLOY_RENAME_LOCKED_FILES and for its value put 1
How can I deploy a new version without first manually stopping the app-service?
When I develop my .Net Core Web application via VS, I would leverage the publish wizard, check the option Remove additional files at destination and use the App offline support by setting EnableMSDeployAppOffline to true under the publish profile for publishing my application to Azure Web App.
Based on your current deployment workflow, I assume that you are using the Continuous Deployment to your Azure App Service with your local Git Repository. After I changed the source code, then commit the changes to the local repository, then push the source code to my web app remote repository, the source code would be built and copied to D:\home\site\wwwroot on Azure side. Details you could follow Local Git Deployment to Azure App Service.
For your step 1 to 3, I just push the code changes from the local repository to my app service remote repository. Azure would generate the deployment script for you to build your source code project and move the built content to D:\home\site\wwwroot. Moreover, you could Custom Deployment Script for your additional requirement.

Resources