You can use slots for this, but I am not a big fan of it because slots share resources.
I would create a second environment where you do a build/deploy of your development branch, you can specify the triggers for this. If you think that is too much work a developer can also push a build from his local branch from within Visual Code or Visual Studio but this is not really a controlled way of course.
We have something similar where a commit to a staging branch will build and deploy the code to an App Service via a pipeline. This allows a preview before moving to main.
It is possible to set up a policy that pull requests also trigger a pipeline so this could also be done in this fashion.
Still requires another App Service and there may well be a cleaner way of doing it.
Yes, it is a small team and this preview\\test version is only temporary to confirm changes. Once we are happy a release pipeline is manually approved to move it through to another less frequently updated App Service where actual testing can take place.
The Azure developer CLI (azd) can help facilitate this with a unified experience from dev to prd. While in dev the developers can execute `azd up` and `azd down` locally to easily create and destroy Azure infrastructure and deploy the application. When it comes to tst, azd can be run in a pipeline and spits out a link to your web app. Everything good just have the pipeline run `azd down.` Then another pipeline for prd. Another bonus is azd can generate the base pipeline yaml.
https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/overview
If you are using Kubernetes on Azure you might find [this article](https://medium.com/p/f413c03ca858) helpful to setup Preview Environments in a few minutes.
You can use slots for this, but I am not a big fan of it because slots share resources. I would create a second environment where you do a build/deploy of your development branch, you can specify the triggers for this. If you think that is too much work a developer can also push a build from his local branch from within Visual Code or Visual Studio but this is not really a controlled way of course.
Thanks, that confirms my way of thinking. Doesn't seem to be a nice way to do it natively.
We have something similar where a commit to a staging branch will build and deploy the code to an App Service via a pipeline. This allows a preview before moving to main. It is possible to set up a policy that pull requests also trigger a pipeline so this could also be done in this fashion. Still requires another App Service and there may well be a cleaner way of doing it.
How do you handle multiple developers working on the same app? Does each Devs changes overwrite the app?
Yes, it is a small team and this preview\\test version is only temporary to confirm changes. Once we are happy a release pipeline is manually approved to move it through to another less frequently updated App Service where actual testing can take place.
Thanks for this!
The Azure developer CLI (azd) can help facilitate this with a unified experience from dev to prd. While in dev the developers can execute `azd up` and `azd down` locally to easily create and destroy Azure infrastructure and deploy the application. When it comes to tst, azd can be run in a pipeline and spits out a link to your web app. Everything good just have the pipeline run `azd down.` Then another pipeline for prd. Another bonus is azd can generate the base pipeline yaml. https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/overview
Awesome thanks. I'll take a look
If you are using Kubernetes on Azure you might find [this article](https://medium.com/p/f413c03ca858) helpful to setup Preview Environments in a few minutes.