We have one build pipeline (Product1) that use multiple branches (dev, test, prod).
In release pipeline/artifacts settings, we use the following settings:
Default version: Latest from a specific branch with tags
Branch: $(Branch.name) --> this is settable at release time.
The scenario that we are having:
The latest successful build is using the dev branch.
There is another successful build using the test branch.
Create new release, and set Branch.name to test --> it does not use test branch, it uses the last successful one which is dev branch.
How can we use branch variables in release pipelines?
As you set the Default version: Latest from a specific branch with tags.
You need to add tags for builds, then specify the specific tag in artifacts settings, otherwise it will use the last successful builds generated from the build pipeline (will ignore the specified branch).
For example, in below screenshot I added a tag master for the successful build using the master branch, then specify the tag in Artifact settings. Thus when you create a release it will automatically select the latest build which has the tag master and using master branch.
Related
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.
I try to set up continuous delivery with VSTS and Azure with the following workflow:
Build on every commit to master (CI)
Create new release (and deploy) when a release tag is added (CD)
I have looked into:
This answer suggesting to check the box, which doesn't
work.
An other answer which configures the build, but I want to use a release.
And this one, which adds a custom build task, but does not use releases.
The build part works fine, and I can create a new release manually. But I can't get the release manager to create a new release when a new tag is created.
I have configured the deployment trigger like this, but it doesn't trigger on new tags even when the Create a release when tags are added to an existing build:
I have tried Build tags variations as refs/tags/v*, refs/tags/v\*, v*, v\*, and specific tags like prod.
My build only reports Tags set for release trigger did not match the tags in build branch, which isn't very helpful:
I think the confusion is about the type of Tags. Build tags are actually defined on the Build, not in Git. They're not the same thing as a Git tag.
You can set the Build Tags through the REST API or through the UI (add tags on the Build Details page).
For more information, see:
Controlling build quality using Build Tags and VSTS Release Management
Tags - Add Build Tag
In order to release based on tags, I think you may need to configure a CI build to trigger in the tag, then feed that into the release workflow. There is no way, without custom scripts, to promote the Build automatically by pushing a Git tag.
In VSTS online, I have in my Release process (Under Triggers) the Continuous Deployment checked. On the Set trigger on artifact source, I put a Tag condition (with tags) set to Automated.
I also have a tag in the Build Process. (Correctly adds the Tag to the build)
But my release is not triggered automatically? In the Deployments status (In my Build) it says "Tags set for release trigger did not match the tags in build branch". But they match (See pictures). What could be the issue?
This is because you added the tag Automated after the build is finished (by label source or manually). This can’t trigger CD release. Tags should be add during a build (not a build is finished). So you can add a power shell task with inline script in your build definition:
Write-Host "##vso[build.addbuildtag]Automatd"
Then the release will be trigger after build is finished.
I do this a different way very similar to:
How to trigger VSTS build and release when pushing tags?
In my Release Pipeline I add a branch filter to 'refs/tags/' or 'refs/tags/v' for the Continuous Deployment Trigger, or anywhere else where I want to filter action in my Release Pipeline. The good thing is that you can apply your Git Tag AFTER your build is complete, just like you prefer. This is optional, but I use Git in conjunction with GitVersion.
Also, please be aware that Git Tags and Build Tags are not the same. Git Tags are stored in the Git repository while Build Tags are associated with a VSTS/Azure build summary. Don't get confused with the two.
For future readers it looks like you can now trigger a release even when a tag is added to a build at any time (not just during a build).
Create a release when tags are added to an existing build. Upon enabling this option, a release gets created when tags are added to an existing build that has not been released. This could lead to deployment of an older build to the environments.
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.
We are using Bamboo 5.2 for continuous integration.
Source plan has several additional branches. Each branch is triggered by commits in git repo.
Deployment project is configured with separate environment for each branch, deployment happens automatically on successful build of source plan.
When default branch is deployed automatically - new release is created correctly with naming schema defined in "Release versioning" (we use source plan variables to create release version).
The problem appears when any other branch is deployed automatically - we get new release with default version. As bamboo states: "Releases from branches will default to using the branch name suffixed with the build number of the build result."
Is there any possibility to override this approach?
Target is to set release version from plan's variables (no matter default plan variables or branch plan variables), reason is that we have single plan with several stable branches configured.
In Bamboo 6.1.0 Atlassian has solved the problem!
Please see https://jira.atlassian.com/browse/BAM-14422.
Since now on naming for releases created on non-default branches follow defined naming rules.
There is an option to select which branch to use. Under Triggers:
Branch to trigger this deployment
Use the main plan branch