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:
