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
Related
what I did;
I have my c# windows form application on Azure Repo and I created a build.
I assigned my physical test server to Azure DevOps under the Deployment groups page. And it is online.
I defined a release, I added an artifact that refers to the build pipeline from the Azure repo.
Now I want to transfer my windows form app release files to my physical test server (windows) under the Desktop folder and run. (also stop and delete previous app if it is already running)
For that, I tried to add a stage. But for the stage templates, I don't know which one to choose. There are deployment options for IIS and Azure services.
Bufre, I published my ASP.NET app using IIS website deployment. Worked fine. But how to do it for a desktop application? How to transfer and run?
I see a as a similar issue here, But I am new to YAML files and I could not produce.
Where to mention target physical path, which template to choose? Could you please advise on the steps?
You must install the DevOps agent on this server, then add it to the agent pool and then use any task that allows to install your app (depends on what kind of app you have). All tasks will be executed on the server directly, so you can use PowerShell, cmd or what ever.
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml%2Cbrowser
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.
We are deploying into azure using Octopus deploy. We are using it since more than a year, and suddenly we started (about 3 weeks ago) to get errors on few deployments.
Microsoft.Web.Deployment.DeploymentDetailedClientServerException: Web Deploy cannot modify the file 'msvcr120.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE
We have the webapp running and always on and we have the app setting 'MSDEPLOY_RENAME_LOCKED_FILES' to 1 that in theory prevents this.
Does anyone knows if something was changed in azure or octopus?
There are a number of reasons files may be locked during deployment. You should be able to get an idea of what may be locking files by using the kudu process explorer, which you can access using the url {yoursite}.scm.azurewebsites.net.
In order to avoid the locking issue altogether, you could make use of slots to achieve a zero downtime deployment if that's an option for you. In this case you could stop the site or enable App Offline which should unlock any files and allow the deployment to succeed after which a slot swap will make the deployment live. App Offline is preferred over using MSDEPLOY_RENAME_LOCKED_FILES, but will take the application offline during the deployment. Octopus also has support for this as an option on the Deploy an Azure Web App step itself, so may be worth a try even without slots.
You can use custom pre/post deployment scripts as part of your Deploy an Azure Web App to make use of the Stop-AzureRmWebAppSlot, Start-AzureRmWebAppSlot and Switch-AzureRmWebAppSlot Powershell commands Azure commandlets to achieve the above.
An alternative may be to use zip deployments, however, the Deploy an Azure Web App Octopus step doesn't have first class support for this quite yet. It can still be achieved using a Run an Azure PowerShell Script along with a package references if this is what you are wanting to do.
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.
Having never used Azure before I'm attempting to deploy a simple F# Suave app to Azure using FTP. Ultimately I want to deploy via github but I initially thought FTP'ing it would be the easy first step. According to https://suave.io/azure-app-service.html it should be straight forward.
These are the steps I followed
Created a new web app in Azure including a resource group
and app service plan. All on the Free Tier.
Downloaded the publishsettings XML file that Azure created.
Cloned this repo: https://github.com/isaacabraham/fsharp-demonstrator
Used FileZilla to connect via FTP using the creds
from step 2.
Uploaded the files (via FTP) from
fsharp-demonstrator/src/SuaveHost (which includes the necessary web.config file) from the repo cloned at step 3 to
the site\wwwroot on Azure.
Navigated to Azure site url.
Then I receive the error:
The specified CGI application encountered an error and the server terminated the process.
(When I look at the folders on Azure under site\wwwroot I don't see any obj or bin folders. I don't think any msbuild process occurred. That doesn't seem right.)
Anybody got any idea what the problem is?
I suspect the issue is that when you deploy via FTP, then Azure does not automatically run the deploy script specified in the .deployment file.
The build.fsx script uses Kudu service to deploy the built files, so it might be easier to just use Github deployment rather than FTP - this way, Azure will do the deployment for you.
If you want to deploy via FTP, you'll need to build the project locally and upload the output. I'm not sure how to best do this with Isaac's Kudu-based demo though (ultimately, you need web.config that points to your built executable like this)