In past I was running my pipelines in Jenkins, where in branch discovery strategy was set to
Merging the pull request with the current target branch revision
This allowed for PR to be build as close to target branch as possible. I just noticed that azure devops pipeline seem to be not doing this, building the branch as is instead. Even thought I get notyfication when there are conflicts, etc so its testing it but not using it to validate the build, Is there some kind of property / configuration for that or would I have to implement it manually?
Related
We have a development branch that is fed from feature branches through pull requests. After merge a build occurs and the artifact created triggers the release pipeline with some deployments happening automatically and others happening after manual approval.
After the approval happens for production, and after successful deployment, we would like to merge the PR that was was merge to develop to our main branch. I was wondering if this could be achieved automatically from the pipeline.
Note that not all the PR are going to make its way to production and the latest may not be the one being deployed in production.
Assuming that you must complete the PR to trigger the CI build and release pipelines, you won't be able to re-use the existing PR to merge into another branch because PRs are specific to branches and once completed they can't be re-opened.
In theory, you could add logic to your release pipeline to create a new PR after successfully deploying into production but this is dangerous because PRs are based on branches and not individual commits. So if the develop branch changes while you're deploying into production the new PR would contain changes that haven't been deployed. If you have a small team and the number of PullRequests are low, this might not be a problem for you.
However, if you have a large team and dozens of pull-requests a day, you might benefit by adjusting your a gitflow branching strategy. In that model you would create a release branch and deploy that into other environments. Creating the pull request at the end of that pipeline flow makes total sense because you're deploying and merging a static branch.
For example, you could add a step in your release pipeline to create the PR using the Azure CLI:
$pr = az repos pr create `
--source-branch develop `
--target-branch main `
--title 'merge $(Build.BuildId) into main' |
ConvertFrom-Json
Write-Host 'Created PR $($pr.pullRequestId)'
There's another question where they're doing something similar.
Alternatively, look at the "Github flow" model. They use a trunk-based branching strategy where the PR is king and changes in the PR ultimately go to production or they don't get merged. The GitHub team had a model where they concentrated on a single PR at a time with a flow that looked like:
Designate a PR as a candidate for production
Automation would lock the target branch and create a temporary merge of the PR and the target branch
Automation would build this branch and deploy it to various environments.
Upon successful build into the environment, the automation would unlock the target branch and complete the PR.
It's worth pointing out that Azure DevOps does support triggering Releases from Pull Requests, and each PR-triggered build is a temporary merge of the target branch, so you could create a release and deploy it into your environments with your approval gates. You could add automation to your release to approve the PR:
az repos pr set-vote --id $pr.pullRequestId --vote approve
So, Azure DevOps UI now supports setting up cross-repo policies to protect the default (master) branch for all existing and future repositories - nice!
Up until now we have used the same policy for each repository, manually setting it up whenever a new repository is added (we're doing microservices with a repository for each service). One of the policies is build validation. This is the only policy that changes from repo to repo because each repo has its own build pipeline (currently classic since YAML are still missing some key features) with a Git-trigger for the given repository.
The question is; if I set up cross-repo policies and want to include build validation, how do I do that given that each repo has its own build pipeline? AFAIK build pipelines does not (yet) support multiple repositories as triggers (this should be coming soon for YAML pipelines) so I can't create a single build pipeline to use for all repositories.
Setting build validation in cross-repo policies does not apply to every repo . As you know, currently the build pipeline does not support multiple repositories as triggers.
So if you want to trigger the build when the specified branch in each repo creates the pr, you need to add the pipeline of each repository to build validation, but this will cause all the branch policies need to pass if you want the pr to complete , and your other build pipelines in build validation is for other repositories, which will prevent the pr from completing. As shown below:
Build validation set in cross-repo policies is required to be followed by each specified branch.
So, for now, if you want the build pipeline of each repository to be triggered , you need to set build validation separately in the branch policy of each repository.
I have a repo which has two branches:
develop (repo's default branch)
master
Code within the develop branch is known to be releasable as an "alpha" version, while code within master is known to be production ready.
Currently, the develop branch's policies requires that a CI build must successfully complete for the PR to merge. That build will create NuGet package artifacts with a prerelease tag (alpha-####).
A release pipeline is responsible for taking these packages and publishing them to an internal NuGet feed.
What I'm trying to achieve is to have the release pipeline triggered automatically when the PR is completed, not whenever the CI build succeeds.
I expected the "pull request trigger" to do just that, but much to my surprise the trigger won't acknowledge the PR's status and have the release pipeline start as soon as the CI build is completed.
This means that if the PR gets rejected for whatever reason, a NuGet may still be deployed to my feed!
What am I doing wrong here? How come the pull request trigger doesn't work any differently than the continuous deployment trigger? What's it's purpose then? :/
The continuous deployment trigger means, if you specify certain types of artifacts in a release pipeline, you can enable continuous deployment. This instructs Azure Pipeline to create new releases automatically when it detects new artifacts are available.
The Pull request trigger means, once a pull request release is configured, anytime a pull request is raised for the protected branch, a release is triggered automatically, deployed to the specified environments.
So these two triggers are different and more detailed information you can refer to here.
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/deploy-pull-request-builds?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops
And if you still want to deploy your Nuget after a PR completed, I recommend you to create a new build pipeline and enable the Continuous integration for it. Then set this build pipeline as the Release pipeline Artifact.
Because when a PR completed, it will create a new commit to the target branch and this new commit will trigger the build pipeline, and the build pipeline will trigger the release pipeline to deploy the Nuget as your expected.
Not sure if anyone's still looking for a solution to this over a year after the fact, but I was so I wrote an Azure Function app to receive pull request close webhooks from DevOps and translate those events into new releases.
You can find it here on my github: https://github.com/GravlLift/OnPullRequest
Feel free to fork it to fit whatever your individual needs are.
So I have a application split in 4 different repositories which all have their own Azure Pipeline build. But the artifacts of these 4 builds are deployed in one release (into one application).
On a check-in (pull request merge) on our development branch in one of the repos, a build for that repo is started. When this build completes, a release is triggered with the newly finished build artifact + 3 older artifacts based on the "Latest from the build pipeline default branch with tags" from the other repos. So always the latest builds from the development (dev) branch.
Now we want to also deploy an environment for every pull request that is created in the different repos, so our business can test a pull request.
I have the release pipeline done (the actual deploying of the environment), but not sure how to select the artifacts correctly. After a build on a pull request branch, I need to start a release with the pull request artifacts from that triggering build + the latest dev branch artifacts from the other 3 builds.
Manually I can start a new release, by default it selects all the dev artifacts, but by hand I can select the correct artifacts for the PR branch and start a correct deployment. But I want to automate (trigger) this.
How can I configure this automated trigger? Could I use tags? Or am I thinking about this in a wrong way?
Edit
I ended up setting this up by using 4 different stages which have different artifact filters. A stage for each artifact. For that artifact we allow dev_* and all other artifacts need to be from dev_. That way the correct stage is triggered for each artifact trigger, selecting the feature branch and dev branch for others.
It is not the ideal solution, because it does require some duplication of code, but by using Task Groups I have been able to minimize this. But for now I don't see a better solution.
Using the Delivery Pipeline service, I'd like to deploy my artifacts to staging/QA environments where QA/Product team members can test features/defect fixes before those changes get merged into Production branch.
How would I spin up these temporary testing environments when pull requests are created?
There is currently no way to build off of pull requests. One option would be to have a separate branch that people can merge code into. You can then have a build stage which builds that branch and a deploy stage to deploy to your staging/qa environment. You can then have another stage will does the merge into the production branch. (Note, this stage should only be triggered manually.)