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.
Related
I've got the following scenario:
updates branch develop -> triggers DEV-CI -> triggers Release X
updates branch master -> triggers QA-CI -> triggers Release X
updates branch release -> triggers Prod-CI -> triggers Release X
Inside "Release X" I added all 3 artifacts (dev, qa and prod) and 3 separate stages (dev, qa and prod). My goal was to publish to DEV if the branch develop is updated, to QA if master and so on, but release pipeline doesn't start because it requires all 3 artifacts to be available.
It only works if I only have 1-to-1, like this:
If I add the other artifacts, even after adding the artifact filters in the pre-deployment conditions for each specific artifact, the release won't start until all 3 are available.
Is it possible to do what I'm trying here or will I have to create one release per CI?
Thanks!
EDIT
After Li's answer I tried again, but it didn't work. Both environments were triggered, even though only QA CI had run.
This was the result:
Here the QA release is downloading both artifacts, even though there's a specific artifact filter:
Here's the setup that generated that result:
I had tested recently and these artifact filters are tightly coupled with a repository branch which means that if you have 2 artifacts from the same branch then it will trigger all stages where you have that branch reference in artifact filteration.
You must use GATES to do such artifact filteration.
I tested the following settings. Enable Continuous deployment trigger for each build artifact, and set artifact filter for each stage.
When the dev build runs successfully, the Dev stage is triggered normally.
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.
Last week, our team decided to move all separate .NET projects into a single solution. Because we were already using Azure DevOps with separate build pipelines for each project, we looked into the possibility to only trigger builds whenever there are changes to a specific project. This, to prevent the build agents from rebuilding the entire solution on every commit.
Because our source repository is a locally hosted Git one, we do not have the niceties of using path filters, so we resorted to using a Powershell task to determine if all upcoming tasks should be skipped, using a custom condition (explained in this SO question).
Now, on every commit, all builds are triggered, but the builds resolve for themselves if they should continue to build and (more importantly) if they should publish a build artifact at the end. An example of such a skipped build is below:
However, every time such a build 'succeeds', a new artifact is created, even though the publish artifact task is skipped. The problem is that all our release pipelines are triggered when a build pipeline creates an artifact. So every time a build is skipped like shown above, the release pipeline triggers and tries to deploy the artifact. But it fails, because the artifact it uses to deploy does not really exist (it seems like it is empty, and the build pipeline actually doesn't mention an artifact on the Summary tab), so any operations on the artifact fail in the release pipeline.
Our release pipelines are set to trigger on source type build artifact, for the corresponding build pipeline, with the default version parameter set to latest.
How is it possible that, even though the publish artifact task is skipped, the release pipeline still triggers and tries to deploy an empty artifact?
I assuming you enable the Continues Delivery in the Releases pipelines, this option is not related to build artifacts. this option means that Release will be triggered when the build succeeded (not matter if he has artifacts or no).
So this is the reason why after each build a new release started.
As workaround, you can add a task in the build that add "build tag" only when there is a artifacts, and in the release artifacts options, instead of choose Latest you can choose Latest from the build pipeline default branch with tags and specify the tag you put in the build.
Another option is in the "Stages" click on the triggers and then it's configured to "After release" so enable the "Artifact filters" and specify there the build tag.
How do you add a build tag? add a PowerShell task with this command:
Write-Host "##vso[build.addbuildtag]test-tag"
Microsoft have added ability to define a VSTS Release Trigger for a specific branch only. It's listed as "Release management orchestration improvements – branch conditions, multiple artifact triggers" on the Features Timeline.
We do use branches and PR builds too, but we only release code from Git master branch. In the past we even had to create a custom extension for this.
However it's still not working as expected in case of multiple builds taken to a Release. Consider this scenario:
We have component A and component B, both produce builds for master branch, as well as other branches and PRs.
We have a single Release definition with 2 triggers defined for both builds for master branch only.
On Artifacts tab we added both builds with the option "Latest", as two other options are manual and so won't conform to Continuous Deployment principle.
When component A is built for master, it triggers a Release which takes artifacts from this Latest master build of component A.
But the build taken for component B can be for any branch\PR, whatever is the latest.
Is there any way to ensure that only specific branch builds are taken into
Release (master builds in my case)?
See screenshot below.
1) Configuration of triggers for 2 builds.
2) Artifact source taken is the Latest version
3) Some releases are still triggered for other branches (not master in this case):
What you want is the ability for an artifact where the default version is "Latest from a specific branch"
This feature is currently under preview for a selected set of customers and will be released soon for a wider audience.
I am using VSTS build to run a CI build. This build definition is the same for all my git branches (master, develop, features, etc).
I am now trying to implement a deployment pipeline using VSTS release management. I plan to have two distinct release definitions. One for feature branches and one for the more important branches like develop and master. The release definition for feature branches would be more lightweight.
I think this is pretty basic and usual. In fact, that's pretty much what is documented in Microsoft's typical use case for Release Management.
For both of these pipelines, I want to configure them to start automatically using the 'Continuous Deployment' trigger. When I select this trigger, I must select an artifact source.
Unfortunately, an artifact source takes all artifacts (regardless of the branch) coming from a given build definition (my CI build). Since I use the same CI build definition for all my branches, it looks like I can't configure my two release pipelines in 'Continuous Deployment' and still use the same build definition as an artifact source.
Anybody knows how to share the same build definition for multiple release definitions but only start a release for a specific branch? Anybody knows of a way to filter by branch when we define an artifact source?
Configure branch specific release deployment
Go to release management in VSTS
Go to the definition of the release
Go to tab triggers
Add Continuous Deployment trigger
Here you can select a specific branch (for branch)
Availability of feature
This feature is available in VSTS
In the TFS on-premise version it was supposed to be available in version Server 2017.1 but it is still not available in version 2018.1
Currently there is no way in VSTS Release Management to do conditional deployment based on branch.
An alternate would be to create separate BDs for different branches and then configure them as artifact sources for the RDs.
This will also give users a clarity about the artifact from its name itself.