Azure-devops-docs: Pull request preview deploys when there are multiple open PRs

[ceddlyburge]

Hi There, this pages gives instructions for Pull Request preview deploys, but it looks like you have to set up a specific Slot or App Service to deploy to. This means that if there is more than one open Pull Request then the last one will overwrite the previous one. Heroku and Netlify (and I'm sure others) create an entirely new deployment for each Pull Request preview. I think that this isn't possible in Azure Dev Ops, but please let me know if I'm mistaken. Thanks, Cedd.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 5cbb2877-5e10-4065-e3c6-7883e9df4b3c
• Version Independent ID: 58122a19-2258-3cf3-8335-74bb0dad892f
• Content: Deploy pull request builds - Azure Pipelines
• Content Source: docs/pipelines/release/deploy-pull-request-builds.md
• Product: devops
• Technology: devops-cicd
• GitHub Login: @raiyanalam
• Microsoft Alias: moala

[WilliamAntonRohm]

@ceddlyburge -- Cedd, here are a couple of options where you might consider asking your question:

• Azure DevOps on Stack Overflow

• Azure DevOps Support Bot

  @raiyanalam -- Raiyan, please look into this potential documentation issue 5986.

[blueelvis]

@WilliamAntonRohm -- Any update on this?

@ceddlyburge -- Did you get an answer to this? I am also interested in finding out the solution to this problem.

[ceddlyburge]

Hi There, I haven't got an answer, and it doesn't look possible from reading the docs, so I'm pretty sure it isn't possible. Hopefully it will be added in the future. In the meantime I can thoroughly recommend Netlify (which does this at the click of a button). Heroku can also do it without much setup.

[blueelvis]

@ceddlyburge - What we did is that we now have a separate Resource Group in Azure and then while the PR deployment is initialized, the PR number is appended to URL sensitive resources like Web App and then cleaned up once the PR is merged using service hooks. It is indeed a workaround but works.

[AdamChrimes]

👍 Hopefully this will be added in the future.

@blueelvis have you considered a write up for your approach to get this working? That would be super helpful if you had any guidance you could share.

[dazinator]

@blueelvis I was considering this same approach, I agree a write up on this would be very useful!

[balazsorban44]

After some investigation 🕵, I ended up here as I did not find an easy solution for this. I am forced to use Azure at work, so it is a much needed feature indeed!
To others, :+1: the first comment, so it may get a higher priority.

[ramiMSFT]

@ceddlyburge Thank you for your feedback. In order for you to deploy a WebApp for example, you will need to specify an existing app service to deploy to. As a suggestion to your issue you can create 2 deployment environments, pre-production and production. You will need to create a new app service and deploy your other branch to it.

Please checkout Azure DevOps Developer Community If you have any more questions, or you would like to suggest a feature.

[ceddlyburge]

Ok, thanks for letting me know.

Its better to know that pull request previews aren't fully supported, that way people won't waste time trying to make them work in the same way that they do on platforms like netlify and heroku.

[balazsorban44]

Agree with @ceddlyburge!

I have used a whole day at work on trying to get this work without success, while on other platforms it can be a flick of switch. We are bound to Azure, and really miss this feature to be able to give a link to other team members that contains only the changes of a particular PR. This eliminates potential bugs originating from unrelated code as well.

Commenting it back to the PR after it is actually deployed would be even more awesome.

Some external examples for reference:

https://vercel.com/github

https://www.netlify.com/blog/2016/07/20/introducing-deploy-previews-in-netlify/ (since 2016...!)

https://devcenter.heroku.com/articles/github-integration-review-apps#selecting-the-url-pattern

So I guess these are deployments that can be thrown away over time (eg. when the PR is meged, or a particular amount of time has passed). I guess it is also acceptable if this is bound to eg. max 5 or 10 deployments at the same time, but at least do not override urls that point to an unmerged PR.