✨ Question of the day ✨: Is it clearer now? Do you have any more questions? SUPPORT THE CHANNEL : Buy me a coffee: www.buymeacoffee.com/CoderDave Join my Patreon: www.patreon.com/CoderDave PayPal me donation: paypal.me/dabenveg

Hi, thanks for the video! I wonder how DevOps identifies "all work items that are involved into the CI/CD process"? sometimes it creates links to incorrect work items that are not involved and not linked to the build artifacts...

Great Explanation !!!

@CoderDave

2 жыл бұрын

Thanks! Happy to help 😊

Pretty neat, Dave. Cleared my doubts. Do you plan to make more videos on Azure DevOps? I'd suggest, how to best setup the CI-CD and the best practices to follow. If you could do it from the scratch, that'd be great.

@CoderDave

2 жыл бұрын

Thanks! Yes, I will have more videos on Azure DevOps coming. I'm focusing more on GitHub and other tools lately because there are not many new features coming out on Azure DevOps, but I will definitely have more content and tutorials on AzDO soon :) For setting up the CI CD from scratch, I do have something for you already. Check out this live I made in which I go through every single thing step-by-step: kzread.info/dash/bejne/ZoOVl6qnlbfbe9Y.html

Hey, Dave! This is a great job! As always! Could you please tell me if it is possible to add a specific tag to the work item when the release, associated with this release, is done?

@CoderDave

Жыл бұрын

Hey, thanks for the compliment ☺️ afaik that is not possible out of the box. Maybe with some custom task…

Great video! I was wondering if you knew of a way to use pre deployment guard (or any other mechanism) to prevent the deployment of a build to production that has any open work items? It seems a pretty common need, to prevent the elevation of code that is in the staging build, but has not been signed off.

@CoderDave

Жыл бұрын

I think the new Deployment Protection Rules can be used for that purpose too. I haven;t played with them just yet (they are very recent) but I will soon have a video about them ;) stay tuned

@marcziss7098

Жыл бұрын

Thx @@CoderDave! I wonder if that will be available on Devops Server 2022. We use and in house devops server and are still on 2020. You would think that would be something that would have been needed for a while. Thought about writing a predeployment gate using custom service api that checks this and fails if it finds any items that are not closed. Guess I just need to play around and figure out how to pass in the build # into the api call

Dave, thank you for this content, it has been most useful. Is there any reason that the 'Testing' Deployment type in the Deployment Group on the specific ADO ticket would not reflect the deployment to that section, even though the pipeline that released to that environment is reflecting as successful? For example, a task, linked to a branch and included in a build was successfully deployed to both the Development and CI environments, according to the pipeline status. The deployment only reflects in the "Development' section of the deployment group, not in the 'Testing' group.

@CoderDave

8 ай бұрын

I am not sure I understand the question. But the Work Item will only show the deployments for the "Environments" you define.

Thank you for responding to my questions. It looks like the difference between "report results to work" and "report results to board" is the place and and a moment when the results appear on a form of a single work item. No summaries for group of work items on board side, right?

@CoderDave

3 жыл бұрын

No problem. 😀 you’re right, no summary on Azure Boars. The only summary would be on the Environments section of the Pipelines

Nice Work! One Question - would it be possible to link work items with boards - through a release pipeline only? So the release pipeline's artifact would not be from a build pipeline - in our case from a branch. Thanks!

@CoderDave

Жыл бұрын

I'm not sure I follow the "So the release pipeline's artifact would not be from a build pipeline - in our case from a branch" part. But in general, no... you need to go through a CI pipeline first for connecting the work items.

Hi, just a question, after linking the Releases with the workitems, can it then be queried as external links? like I want to know which release this work item has been deployed to. Thank you

@CoderDave

Жыл бұрын

Yes you can! I don't have the query right now, but shouldn't be too hard to build because, as you pointed out, the connection is done via the links

how to differentiate if the item falls in release definition, release definition details, release deployments, release deployments task...as well as how can we identify the release name

@CoderDave

2 жыл бұрын

I'm not sure I got your question

Nice, Can any of this be achieved in Yaml pipelines?

@CoderDave

Жыл бұрын

Hey. Unfortunately no, this is a feaure only for Classi Release Pipelines

How to get work items through mail after deployment

@CoderDave

Жыл бұрын

AFAIK there is no out-of-the-box way to do it, you'd have to implement it as a step of the deployment

Hi. would be great if you also show how to link work-item with YML pipelines in Azure DevOps?

@CoderDave

Жыл бұрын

Hey, thanks for the suggestion but it is currently "not possible". What I mean is that the only way to associate work items to azure YAML pipelines is "automatic", the build pipeline will take all the commits to build, and see if they are associated to work items. If they are, it will show the work item list in the pipeline summary screen. This way, however, there won't be a link to the pipeline in the work item. as far as I know there is no way to have the link automatically added to the work items