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.
Related
We've been using environments for a while now for our dev and test instances. I like being able to go to the environment and seeing the commits and work items associated with the particular build/release but can't find a way to export them. Does anyone know of a way to export the workitems?
Using environments you also loose the ability to see which build/release a ticket went out in or have I missed something?
Your first and second question, kind of, have the same answer.
In short, you don't want to be using Environments to view which work items are associated with a release.
Azure DevOps has a built-in mechanism to view work items directly within the Release or Pipelines page (Depending on whether you're using classic or YAML).
Here is a great guide published by Microsoft regarding how work pipeline-based work item linking works, as well as how to retrieve work items associated with a release:
https://devblogs.microsoft.com/premier-developer/how-to-retrieve-all-work-items-associated-with-a-release-pipeline-using-azure-devops-api/
Update:
Specifically regarding how to view linked work items in Pipelines. You'll want to look under "Related":
Clicking on "x work items" will show you the full list of work items:
Goodnight. I have a CI / CD process in Azure Devops that was working normally. As it is all set up, I, after completing a PR, simply execute a Build from my master branch. After successfully completing the Build, I generated a Release and deployed it.
But now I can no longer generate Release. The option to generate a release no longer appears in my pipelines and the message below appears:
This build will be retained forever by master (Branch)
I've already researched it in every way and I don't know what it can be. Has anyone experienced anything like this in Azure Devops?
I've already researched it in every way and I don't know what it can be. Has anyone experienced anything like this in Azure Devops?
Yes, I noticed that this message is in several regions for some my organizations, like Central US.
But I did not see this change in other regions, like East Asia. I think this should be a newly released change and it has not been applied to all regions. This small change is used to remind us how long the current pipeline will be retained.
If we manually retain the pipeline, the message will updated to the "This build will be retained forever by YouName (user)":
And for the option to generate a release, I have not seen it in the most recent versions, and it can be traced back to the TFS2018 version. I think this feature should be removed for a long time.
At present, when we create a release, we will select the release tab:
In VSTS builds, is there a way I can know who have make changes in build steps?
Can I get history builds?
The reason for this is, we have a big team. Many time it happens that someone changes the build step for some reason and we never know who made the changes and why.
Like in git repo, we know which file is changed by who and why (in comments).
In VSTS builds, is there a way I can know who have make changes in build steps? Can I get history builds?
The answer is yes. You could check the History of the build definition:
Click on the three horizontal dots and we will get an option compare difference, through which we can know the details of the pipeline modification. If the modifier adds a note when saving the modification, we can also know the reason for the build pipeline modification.
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.
I'm trying to execute a bit different build steps in VSTS based on type how build was started: automatically or manually.
I'm especially interested in accessing that information from powershell script. But so far was not able to find suitable solution or workaround.
Did someone faced similar requirement before? How did you solved it? I would appreciate your help!
Seems you want to know whether the project build is happening through TFS triggered build or manually triggered build.
There is no such feature for vnext build for now. About this , you could submit your uservoice to this link, TFS Product Team is listening to your voice there.
As a workaround either to use two build definitions through different version patterns or manually add a specifical tag after a manually build finished. Through using tags to set some labels on the build to distinguish manual and automatic builds. But this is a manual action, it would be better if we can do this automatically.
It seems to be I've managed to find an option that allows to determine wherever build was triggered automatically or manually.
All builds started manually have actual user in $Env:BUILD_QUEUEDBY variable, while automatic builds have system account there. My value was [********]\Project Collection Service Accounts.
I don't know how reliable it is, but for me so far following code did the job:
# Identifying who triggered the build
$OwnerId = $Env:BUILD_QUEUEDBY;
$OwnerId = $OwnerId.ToUpper();
if ($OwnerId.EndsWith("PROJECT COLLECTION SERVICE ACCOUNTS"))
{
Write-Host "Build was triggered automatically. Resulting files considered 'BETA'"
}
else
{
Write-Host "Build was triggered manually. Resulting files considered 'STABLE'"
}