A few questions so I can better understand your use case:
- How often would this deployment/build of yours be run?
- Will there ever be any changes going into Master that do not come from develop?
If you plan to run this deploy/build which would create a PR to merge to Master for each change in develop, then I would recommend to delete the develop branch and instead develop directly against Master. Configure Master with Branch Policies enabled that would run a gated build (compile/unit test) before the PR can be merged. This is what my team has been doing for a while now with great success. This change in workflow would prevent the need for having a deploy/build which automatically creates a PR.
If you plan to run this deploy/build less frequently than every change, then I would recommend to use the VSTS APIs and a custom scripting task to automatically create a PR. I believe the scripting task would be fairly similar regardless of whether a deploy runs it or the build runs it. The documentation for VSTS APIs is fairly comprehensive, and I use several of them as part of our pipeline workflows (I use PowerShell). Here is documentation to Create a Pull Request. This would be run as the last task in the deploy/build.
If you plan to merge to Master from areas other than the develop branch, I just want to call out that the PR which will be automatically created by deploy/build could have conflicts and require manual intervention.