I have the following-ish setup in vsts release.
What I would like, is whenever the "hotfix" artifact build is triggered, the bottom pipeline ("Environment 1", "Environment 2") are triggered, whilst if the top one "master" is triggered the top 3 are.
How can I go about it?
I realise I could do them in seperate releases, but I already have a lot of them and grouping related ones this way should hopefully make it easier to maintain.
For now, the workaround is separate the environments into different release definition based on artifacts.
And if you need to trigger different environments based on different artifacts, you can create an user voice.
Related
This is how my colleague set up the stages
here the release of changes
The question is, how can i deploy to PROD (let say only project C - Release 194 and 196), without A, accidentally pushed together to PROD (because it hasnt approve to go to PROD)?
Thank you,
your helps really appreciated
In general, if you wish to take a release of anything to a specific environment, and you have the appropriate approval permissions, you can do the following:
Click the link for the Release-### you wish to deploy
The pipeline will appear, and in the ribbon above, click the Deploy dropdown. Depending on how your pipeline is configured, you'll have the ability to deploy to a single or to multiple environments. Choose where you'd like it to go.
Your question wasn't completely clear, so I've answered as best I can, but it seems from what I read that you might be using a single pipeline to manage deployment of multiple projects? Am I correct? If so, you might wish to look at creating a pipeline for each project - The only way I know what is deployed where in your question is to look at the annotations you added to the right. Separate release definitions would give you better clarity into that. Best of luck.
I'm running builds with AzureDevops piplines. When I'm creating new pipline I'm not queueing it and just saving. If CI trigger is selected pipline will run if anything is checked in.
But on the very first run/chack-in pipline will be liked (associated) to ALL check-ins (changesets/commits) that happened before the current one and to all workitems of those chack-ins.
This behaviour is not desired for me. Is there a way to disable it?
On all subsequent check-ins build will be associated only with the one that triggered the pipline. And this is what I want for the first build as well, for it to be associated only with the chack-in that triggered it.
Without seeing exactly what's happening, it's hard to provide advice. It could also behave differently if you're using Git or TFSVC variants. Here's a few things to try:
Disable the CI trigger, do your first check-in, then re-enable the trigger. That might skip the change-set and work item affiliation one time.
Delete the offending build after it runs or do the laborious task of manually deleting all links in it.
If you're using Git, you can also limit the CI trigger by using a Pull Request with Squash merge. This will consolidate the commits down to one.
There isn't the way to disable it. It would compare previous run, then include all changesets between them. So, for first run, it must includes all previous changesets.
You may create a new branch for a folder, then configure build for that branch. Learn about branching strategies for Team Foundation Version Control (TFVC) and how to select an effective strategy
I come from using Rally and Pivotal Tracker. In both I could assign work items to Releases as a planning tool, and to have a historical record of those work items that were deployed.
Even with all the highly-specific guidance from Microsoft about Azure DevOps, it is silent how to organize work against future Releases. I can't see a place to even associate a work item to a Release. Is there something I am missing in all the documentation, or is there some workaround strategy more robust than just using tags to pro-actively plan against releases? Or is Microsoft's expectation that I use some separate product management tool to manage work items against Releases?
There are multiple techniques employed to accomplish this, not "one way":
use a parent iteration path that groups the iterations you plan against a certain release. This works best when you completely finish one release before starting the next. Otherwise, it usually becomes a mess with multiple active iterations.
Backlog Iteration
+ Release 1.0
+ Sprint 1
+ Sprint 2
+ Sprint 3
+ Release 2.0
+ etc
-
use tags for releases. Add a tag [Release 1.0] top all work items that are included in that release, this is one of the most flexible options.
use Azure Pipelines to keep track of which Work Items were associated to which Git commits and thus was included in which Build artifact. Track the build artifacts across environments to see which work items were deployed to an environment by looking at the intermediate builds.
add a custom work item field to the work item types you want to track. You can change the work item process being used and you can add a field to the work items in which you can specify the release name/number. There are custom controls available that can scope the version numbers to a specific list or can fetch the allowed values from any REST API.
Azure DevOps is more flexible in the usage patterns as you can see, but it also means that sometimes you need to "figure out what works best" for your team.
Another extension you may be interested in is the Bravo Notes extension. Or one of the other extensions that can generate Release Notes based on you work item data, commits and/or pipeline artefacts.
I am using Build Pipeline: VSTS and Repo: VSTS
I am trying to create VSTS build pipelines for two branches Dev and UAT. I can achieve it by creating two different pipelines but since both has almost similar steps so I wanted to have only one pipeline and depending on condition I can omit some steps. But I am not able to figure out how to pass the variable value(branch which triggered the build) before queueing the build in VSTS.
Background: I tried to get both branch source, setted triggers on both branch and use Build.SourceBranchName variable but it is giving value the top level(Project) value instead of branch name. I have structure like below
Project
- Dev
- QA
The agenda is to trigger the build pipeline on checkin, sanity checks an publish the artifacts as per the environment(Dev,QA). I am not going for CD right now (will be handled manually because of some constraints).
The solution might sound very awkward but I am a newbie and I want to learn it.
I have checked some people have explained through API but any way to do through UI?
VSTS use API to set build parameters at queue time
Any help would be highly appreciated.

To add a variable that you can pass the value when you queue the build you need to go to variables tab, then add your variable and check the checkbox Settable at queue time.
Now when will queue a build you can change the default value.
I would like my builds to behave differently (a handling script needs to know) if a person requested the build through the UI "build now" button, or if it was triggered by SCM. I don't want to have to provide a checkbox in the UI that the users have to alter - I've already gotten blowback from them about such things. Trouble is, any parameter I set has the same default regardless of how the build is triggered.
You should not really have 1 job with different behaviour. If you need different behaviour set up a job per behaviour. Best bet in your case is to have 2 separate jobs, one for the SCM triggered builds, and one for the manually triggered builds.
There's a plugin to allow you to filter jobs into separate pages (can't remember the name at the moment). You could set all SCM builds on 1 page and manual builds on another, then set the manual build page as the default one on login. Users will only see the jobs you want triggered manually by default, but can still access the SCM triggered builds by selecting the other page.
Could you somehow check the SCM polling log during the pre-build (with a script), and then go from there?