We have a python application (Flask) that we develop with Visual Studio.
We push this to Azure DevOps as a git.
When I push it to our Azure App Service it only works when I only push the actual python files and not the .vs folder or the .pyproj, .pyproj.user files. This means I have a folder locally that I copy the files to and then push to app services. That is not the nicest solution as you can imagine.
My questions:
Why does app service not work with the "other" files?
How would this work nicely that every time I push directly to the app service as well as our Azure DevOps?
not sure I understand the question properly. but you dont need to push those to the webapp for it to work. you can use gitignore file to exclude those not needed files from commits.
you can configure you webapp to use local git deployment method and do a push "directly", but that is probably not what you want to do. you probably want to build on commit to git\vsts\whatever repo and push artifacts to the webapp
Related
I am deploying our NodeJS application to our Azure App service using Azure's local git. What I am basically doing is making our CICD pipeline git commit our changes and do a force push to Azure's Local Git. Then, Azure will build the application from the committed files, which seems to be working fine.
But today, I have made a shocking discovery, after couple of weeks of deployment, the files in the wwwroot folder does not match the files in the Local Git Repo. The files that do not exist anymore in the Local Git repo are still in the wwwroot folder
For example, the git repo contains the following files under prisma/migrations
But in the Azure App service wwwroot folder, the same directory contains more than that:
So, these files are actually from previous deployments that do not exist in the latest version of the master branch of the Local Git.
Upon looking at their deployment step, I learned that they are simply copying whatever files are created in their deployment "Oryx/Kudu" deployment step into the wwwroot folder without checking if there should be files needed to be deleted:
If this is the case with this approach, is there a proper way to do this?
Or is there a quick way to clean the existing wwwroot folder first before their deployer copy the files?
Hope somebody can help.
Thanks!
If you use the Azure App Service Deploy task in Azure DevOps Pipeline to deploy your application and select Web Deploy method option, there is an additional option to Remove Additional Files at Destination.
If you check this option, the deployment process will remove any files at the destination where there is no corresponding file in the package that is being deployed.
In other words, it'll remove any left-over files from a previous deployment that are no longer required.
Please refer to the similar ticket: How to clean up wwwroot folder on the target Azure Websites Windows Server before each deployment in VSTS.
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.
I know you can push from local git and deploy code is azure web app.
But i want
first Deploy complete arm template from scratch using local git push.
and in the same push i want to deploy website code.
Now question is if arm template is creating web app from scratch then which git repo to push .
i am confused in this can some body tell me proper way to achieve this.
well, you would need to create a hook, that would launch a script that would deploy your template. After the deployment is complete your script would get the git url from the webapp it deployed and push from local git to that repo.
That being said, it is 100 times easier to just place files on github and configure continuous delivery that would happen on its own. all you would need to do is to push to git from local repo.
Reference:
https://learn.microsoft.com/en-us/azure/app-service-web/app-service-deploy-local-git
https://learn.microsoft.com/en-us/azure/app-service-web/app-service-continuous-deployment
I have nodejs app. Can I deploy it to azure app service without VS or other big IDE?
So, I want an easy way to select branch what I need push it to azure and run default command for nodejs.
I'm stuck with it, because all of solution it is use VS.
You can deploy to azure app service by using Azure App Service Deployment step/task. For example:
Create a build definition
Add related step/task to build your project
Add Azure App Service Deployment step/task (Can publish using Web Deploy or upload files directly)
Select Triggers tab and enable Continuous Integration
Specify repository and branch filters
After that, the build will be triggered if you push changes to target branch.
Related article: Define a continuous integration build for your Node.js app
Regarding run command for nodejs, you can refer to this thread by using kudu API: Include node modules in azure deployment via VSTS.
This can be done. Take a look at the build and release functionality in Visual Studio Team Services.
With VSTS Build, you can trigger a build and push to an Azure Web App automatically on a Git check-in for a particular branch, or you can manually trigger the build and push.
Take a look at the Azure App Service Deploy task in VSTS build.
Note that since VSTS is pulling from your Git repo, it doesn't matter what IDE you use to actually develop your app with.
Also, VSTS is free for small teams and a single deployment pipeline.
I have an existing website that I would like to deploy on Azure, using Visual Studio Team Services. The website is made up of static files, there's no ASP.NET or anything else involved.
Within Visual Studio Team Services, I created a build which executes npm install and a gulp build. This results in a dist folder containing all the files for the website. In Azure, everything is set up correctly (subscription, web app,...).
However, I'm unsure on how to push my code to Azure. Exploring the options in the Release tab in VSTS, an 'artifact' always seems to be required, but I just have a bunch of files. I need to publish the files in the dist folder and make sure index.html is served.
How can I do that?
This question is related to this one, however, the answers all state to start from Azure, and do not mention how to deploy existing code using Visual Studio Team Services.
The trick is to create the artifact yourself, which can be as simple as a zip file containing the static website files. The zip file should be copied as an artifact to the $(build.artifactstagingdirectory) target directory. Next, you can use a simple Web App deployment task to publish the zip file to Azure. If index.html is in the root directory, Azure is smart enough to serve it.
Below is a working build and deploy flow. It assumes gulp is used to build the website and write the build output (i.e. the static files) to a dist folder.
The easiest way is to deploy from a source control, if you take a look under "Settings" for your Website in the Azure portal you will probably see "Continuous deployment".
From there you can deploy from Visual Studio Team Services, Github, etc.
Every check-in will be deployed, also wrong ones, so you may want a introduce a staging environment as a deployment slot as well, where you can swap staging with production whenever you feel your site is ready for production.
Without the need to create an artifact, another solution could be FTP deployment after creating an Service Endpoint in VSTS