We have around 200 applications/services build/release under TFS 2018. Under TFS release we have TEST/QA/PROD pipelines and pre and post approver setup for each environment. One of approver leaving organization and we have to replace his name with new personal name in all 200 release definitions. If we start updating them manually we have to open and edit all 200 release definitions and update one by one. Is there any way i can update all 200 release definition and change/replace approver name?
So in general I would aim for using Groups as approvers instead of having the names of the approvers directly in the release definition. With that approach, you can just create different groups and add/remove people in those groups, which will affect all the release definitions wihtout having them to edit manually.
In case you have completly different approvers for all of the 200 release definitions of course this does only shift the problem, as then you would need to update all the groups manually. But if we have mainly the same users I think that is your best option.
Now of course in order to update the release definitions initally from having the manually defined names to the groups you would still need to go through all of the 200 definitions and edit them, however this would be a one time thing, afterwards everything would be configured via the groups. You might even get the removal of a person for free, as they should be removed from a group automatically if the user is removed.
If you cannot use groups or you really have completly different approvers everywhere, it might be worth looking into the REST APIs (Azure DevOps Rest API) and create a custom script/tool that automates the job tailored to your needs.
Related
We have 6 people on the project team: 1 Tech-lead and 1 Assistant Tech-lead.
In our branch policy we want to require that only the Tech-lead or Assistant Tech-lead can approve the pull request. We only need approval from one of them to avoid a bottleneck if the other one is on leave.
The problem is there are only 2 choices in the branch policy settings:
Specifying the number of required approvers (which will not work since normal developers would be able to approve as well)
Specifying the actual person to approve (which will not work since both of them will be required and cause a bottleneck when one is on leave)
Can someone please point us in the right direction?
You can provide required reviewers that are automatically added to each PR. These reviewers can also be groups.
Do this:
Create a group that contains your tech lead and assistant tech lead and.
Make that group a required approver under Automatically include code reviewers
You should get something like this:
Your statement normal developers would be able to approve as well is only true if the group that is required contains your normal developers.
This way at least 1 person from provided group (in this case Developers) must approve a PR. If you want you can also provide a path filter to require only reviews on certain changes or assign a different group for files or folders.
for those who are on Bitbucket:
These are available under Repository Settings->Workflow->Branch Permissions
We are running TFS 2012. Our organization is currently creating new accounts for everyone as part of a migration.
What I know is that everyone will have two accounts listed in AD for a while:
OldDomain\DoeJ
NewDomain\DoeJ
This brings me to believe that SID will be different, among other things.
My question is, how would this affect our TFS environment? Will we lose any history associated with particular users? Will I have to go through each work item and reassign it to the new Windows account? Is there any way I can preserve this data?
Thanks
You could use Identities Command which lists or changes the security identifier (SID) of users and groups in your deployment of TFS. You might need to change or update the SID for users and groups in one of the following scenarios:
changing the domain of your deployment
changing from a workgroup to a domain or from a domain to a workgroup
migrating accounts across domains in Active Directory
Even though it's a powerful tool, but it has certain limitations. To help ensure a successful move, make sure that you understand the following requirements:
Once a user account is present in TFS, it cannot be removed or have another account mapped to it. For example, if you are moving
DomainA/UserA to DomainB/UserB, the Identities command would only
work to migrate the user if DomainB/UserB is not already present in
TFS.
Because the members of the local Administrators group are automatically added to TFS, make sure to remove any accounts that you
want migrated from that group before you change the domain or
environment.
Suggest you read up about this tutorial as part of planning your move. You could also take a look at this blog : Migrating TFS Server or Collection to another domain. Be careful do not add the user such as NewDomain\DoeJ to TFS first, after upgrade SID, the history will keep without any problem.
Moreover, TFS use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). You can force the job to run using any of these techniques.
I have two separate branches created for a project with two users - each user only has access to their branch.
I have created the project backlog items, however each user when logged into Visual Studio Online can see the backlog items - which is ok. However once one user completes an item in their branch, I don't want that item to affect the other user's ability to continue working on that item.
I want to test how each developer creates a new UI on their respective branches. Essentially the work is the same, but the way they implement would be different.
For example, an item may be "Update website front page".
Essentially I want them both to do the same thing but on their own branch. Can we separate backlog items by branch?
Sounds like you have some crazy Hunger Games development scenario going on and as Daniel said, better to develop in one branch and merge to the other.
However, if you want to restrict Work Items across Teams or TFS Groups then you can restrict the Area Path. So, either set up a team for each developer or simply create an Area Path for each branch and set security on it.
Have a look at Customize area and iteration paths and the section on "Set permissions to restrict access to work items"
We are using Atlassian Crucible for code reviews. Every time I create a review, it shows me a list of about 40 reviewers from the entire project. But only about 5 people in my group within the project need to review my code, so every time I have to manually remove about 35 people from the list of reviewers.
Is there any way to create a default list of reviewers for my code reviews?
Yes, you can create a project and define default reviewers for a project. For ex you can have a default review group for Java projects and a different one fr DB projects
PS:- You would need admin privileges to do this
Does anyone know if it is possible to prevent a work item from being assigned to a specific user account in TFS?
After migrating a TFS from one domain to another, some of my team members have two user accounts, the original one from the old domain, and a new one from the new domain. I'd like to stop work items from being assigned to the old account.
Most process templates restrict username fields with the rule. (If yours doesn't, you should do so.) Then all you need to do is remove the invalid accounts from TFS Valid Users group.
Unfortunately, you can't do this directly -- TFS manages this group automatically based on ACLs found throughout the rest of the system. You have to hunt them down. See these threads for more details:
http://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/6e5af2ab-1cbc-4d12-9078-454147926316
http://social.msdn.microsoft.com/forums/en-US/tfsadmin/thread/1ce8b5b0-9924-45ed-919b-49a6a61bb7c7
Once you find all instances where the old domain is being referenced, the general strategy for cleaning up orphans is to add a new ACL, wait for TFS to sync (or iisreset), then remove everything.
However, this may not be possible if you've taken the old domain offline, or there's no trust relationship between the two domains, etc etc. At some point it becomes easier to edit TfsIntegration manually. I usually don't recommend mucking in the TFS databases since it's unsupported and subject to change with every patch. For optimum safety, I'd still strongly suggest using stored procedures rather than trying to interpret the schema relationships (and make sure you hold the necessary locks, etc). prc_security_delete_identity is your best entry point: all you need to know is the old account's SID.