Say you have a build and its corresponding release definition on Azure Devops.
Generally, the way it's used is like:
Repository "A" changes -> Build repo "A" -> Release to a given environment
Within this scenario (using only one build artifact), it's easy to trigger deployments (after successful build) for different branches.
But, say you also have a release definition with multiple build artifacts (from different repos), and you want to, changes coming from branch "dev" you want to deploy to environment "Development", but if changes come from branch "hotfix" you want to deploy to environment "Staging".
Something like this
You can play with branch filters on the specific environment and artifact filters on the artifact triggers.
The above scenario works very well for "dev" changes when you define your build artifacts to use "dev" as default branch.
But if you make changes on Repo A (branch hotfix), but not in Repo B, the build artifacts for that release will come from different branches, hence the "artifacts will not meet requirements", cause all changes must come from hotfix branch in order to trigger the deployment.
In my opinion, the "Default Version" of the Build Artifact itself, makes this confusion for the pipeline.
See this image example
That being said, how can we trigger a deployment into "Staging" environment if only one of the triggered changes come from the branch "hotfix" ?
The way I can see, when that happens, "Staging" environment never "meets the artifacts requirements", cause other artifacts will use version from "dev" as it's the default source branch.
Has anyone worked with a similar scenario ?
Thanks for reading my question.
Update:
According to your scenario, the best solution at present is to create two release pipelines to deploy separately, because Artifact A and Artifact B have no dependencies.
In the Continuous deployment trigger of the build artifact, you can set Build branch filters to include the dev and hotfix branches.
Then enable Artifact filters in the Pre-deployment conditions of the stage to set the build branch artifact conditions that trigger the deployment.
Artifact filters: Select artifact condition(s) to trigger a new deployment. A release will be deployed to this stage only if all artifact conditions match.
Related
I have a release pipeline that deploys multiple components using multiple stages. With the current setup i have if a release pipeline triggers then deployment happens in all stages even if new version of artifact is not generated.
My requirement is, deployment into stage should happen only if new version of artifact is generated i.e., out of 10 components if only one component got new version of artifact then the stage respective to that should only triggered and other components should be skipped.
FYI:
i don't want to create separate release pipelines for the components
I think the condition of the tasks should be able to achieve your requirements.
Just give an idea, for example, if you publish new artifact to DevOps feed, you can use this REST API to get the packages versions:
https://learn.microsoft.com/en-us/rest/api/azure/devops/artifacts/artifact-details/get-package-versions?view=azure-devops-rest-6.0
Then, you can compare the latest version that the REST API returned with the artifact version in your release pipeline.
condition: and(succeeded(), eq(<version in pipeline>, <latest version in feed>))
You can refer to this official document:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml
If you have continuous deployment triggers enabled for an artifact, the pipeline creates a new release (with all stages) every time. Since the build artifact trigger is abstracted away from the stages, you can't select a stage per artifact.
You said you didn't want to create a separate pipeline per artifact but that really sounds like the correct design. That way only the associated stage(s) will be deployed when the artifact is updated.
I have multiple artifacts for each branch. Continuous deployment trigger is enabled For Dev: _CI_Dev For QA: _CI_QA For Staging: _CI_RC
I want to setup a common stage (since the tasks are same across environments) which should identify the source branch and use corresponding artifacts.
How to add approval and gates only for QA and staging?
How do I identify the source branch which triggered the tasks (for a job)? Should I run a powershell script to setup source branch value in variable to be used in tasks?
How to add approval and gates only for QA and staging? How do I identify the source branch which triggered the tasks (for a job)? Should I run a powershell script to setup source branch value in variable to be used in tasks?
I am afraid we could not add approval and gates only for QA and staging, if we want enable Continuous deployment trigger for all artifact sources.
That because approval and gates currently do not have separate filters, they rely on the option Artifact filters:
However, if we set the Artifact filters for QA and staging, it will filter out builds from Dev: _CI_Dev. Obviously this is not in line with our expectations.
To resolve this issue, the easiest way is to clone the current stage (Although it can't exactly what you originally expected to use one stage, this is currently the best solution.), it will also clone all tasks in that stage. changing Select trigger from stage to release and set the Artifact filters for QA and staging:
Note: Do not forget to add Artifact filters for Dev: _CI_Dev to the previous stage.
I have 2 pipelines in 2 different repositories:
lib.yml in repo.git produces a re-usable library artifact A (needs multiple stages on different nodes for that) and also has a stage that runs autotests after A has been produced.
app.yml in app.git builds and tests an application that needs A to build.
In app.yml I want to integrate A without duplicating lib.yml. I was told that templates are a solution, but I am not so sure. Multiple stages of lib.yml must run before I can consume the desired artifact. Using job templates would only complicate both pipelines and create a dependency on pipeline internals. app.yml should not know how lib.yml builds A.
After consulting the docs I think that a pipeline resource is closer to what I need. But I do not fully understand how it works. Let us assume we want artifact A from lib.yml on branch B.
Will app.yml use the latest available artifact A of branch B or will it kick lib.yml on B?
Is there a way to tell app.yml: use the latest A of lib.yml for branch B if available, otherwise run lib.yml on B and wait for A to become ready?
You, you are right - resource pipelines should do a job for you.
And to run app.yml you should have sth like this:
resources:
pipelines:
- pipeline: hadar
source: kmadof.hadar
trigger:
branches:
- B
and use just:
- download: hadar
to get latest artifact from pipeline of branch B.
You can also select pipeline running your app.yaml manual and select artifact:
And - download: hadar also gets correct artifact.
So
app.yml will use latest available artifact A of branch B.
If you want to app.yaml trigger lib.yaml and then get artifact from lib.yaml it would be difficult and not possible using out of the box functionality. So there is no out fo the box way to have app.yaml trigger un lib.yaml and waiting for artifacts from lib.yaml. And if your app yaml will be triggered by an other trigger than resoure pipeline trigger it will use latest available artifact A of branch B.
A build pipeline can be tied to only 1 source branch.
In release pipeline, we configure an artifact by selecting the source build pipeline. So a release artifact can be tied to only 1 build pipeline.
What is the purpose of Build branch filters in Continuous deployment trigger?
Let say that your code base was updated. You want deploy only if build was made over specific branch (example develop).
In that scenario Build Branch Filter looks fairly redundant... but what if:
You want to trigger new deployment for every latest artifact, built from each feature branch to get them tested. You have to filter for feature/*.
You want to trigger new deployments if your release branches are updated, but some of them are deprecated and you need to filter them out. I that scenario specify one include filter release/* and second exclude filter release/old*.
Anyway.. in most of the cases the filter and the branch name (in artifact) will match each other. Still sometimes it can be heady to trigger deployment from multiple branches or filter something out.
In regards to your comment, I uploaded part of the yaml build. In fact one build can create artifacts from all branches in repository if you want.
trigger:
branches:
include:
- feature/*
- bugfix/*
- release/*
- develop
- master
exclude:
- experimental/*
A release can be triggered when the build artifact is available as shown in screenshot below.
So does this necessitate that for the release pipeline (configured for build artifact) to get triggered, the build pipeline must have the "publish artifact" task?
Agree with Shayki Abramczyk, the answer is No. But I think maybe you need more descriptions to help you understand ~
In your situation, you set build pipeline as release pipeline's artifact. If you've checked this document you would find these statements:
1.When authoring a release pipeline, you link the appropriate artifact sources to your release pipeline. For example, you might link an Azure Pipelines build pipeline or a Jenkins project to your release pipeline.
2.Note from here:
You must include a Publish Artifacts task in your build pipeline. For XAML build pipelines, an artifact with the name drop is published implicitly.
3.Auto-trigger releases feature(CD trigger in artifact): New releases can be created automatically when new builds (including XAML builds) are produced. See Continuous Deployment for details. You do not need to configure anything within the build pipeline. See the notes above for differences between version of TFS.
To sum up, the artifact source here represents a build pipeline instead of the outputs of a build pipeline. So when you enabled the CD trigger in artifact(in your situation a build pipeline), the release is triggered whenever a new build finishes. And this behavior won't be affected by whether the build pipeline has Publish Artifact task to publish the outputs from it.
For the 2.Note: It can be considered as we must include a Publish Artifacts task in build pipeline so that the release pipeline can access the outputs of build pipeline. And then we can deploy the outputs(.dll/.exe or what) to target machines/environments. (Actually we think the must in document should be replaced with It's recommended to/should)
Publish Artifacts task make the build+release process meaningful. Cause if our release pipeline can't access outputs of build pipeline, what should we use to deploy? But whether this task exists or not won't actually affect the CD trigger. (Just like the third statement:You do not need to configure anything within the build pipeline)
The answer is No, the release will be triggered when the build finished even he doesn't have Publish Artifacts step.