We are migrating sets of WorkItems from an On-Prem Server (latest AzureDevops build 2022) to a new Azure DevOps org and team in the cloud. For the migrator we haven't done any User mapping or anything to map the Assigned To field.
Most work items come over with the Assigned To field showing the appropriate name.. however some work items end up showing as Assigned To as ME -- the person executing the migration. NONE of the actual work items we are migrating are assigned to me in the source system.
I've run a couple of Dry run work item migrations and it consistently seems to pick on the same work items (meaning if I ran it now, source work item 1234 is assigned to me, and if I re-run it later, that same work item would be assigned to me again).
The assigned to person in the Source for these work items, doesn't seem to matter, as other work items assigned to those people, do get properly assigned to
I guess I'm trying to understand what cases would be causing this behavior, I don't immediately see anything common or odd about the items in question.
Related
Could anyone provide any best practices about multiple migration runs? Moving from TFS 2017.3.1 to Azure DevOps Service. Dealing with a fair number of work items (32k). Of course, TSTU throttling is making the run take a long time, so I was thinking of pushing what I could up front, then a second pass to pick up the new work items since the first big push. So...enabling UpdateSourceReflectedId would set the ReflectedWorkItemId on the source items that have already been migrated. But what happens if someone changes a work item that has already been pushed? Would the history delta get picked up? How is that typically resolved...I was thinking maybe a Querybit like: ReflectedWorkItemId <> '' and ChangedDate > (last run time), but is that necessary? Those already exist on target...would ReplayRevisions pick up only the missing changes? TIA...
I usually do the following for large runs:
Open work items edited in last 90 days
Closed work items edited in last 90 days
open out to more days in chunks
The important thing to note is that links are created only when both ends of the link exist.
After a long run you can then rerun "edited in last month" to bring any changes a cross.
Changes to avoid in the Source:
changing work item type
moving work item between team project
We handle these, but loosly.
With our TFS 2015 source control we require developers to check-in changes against work items.
However, we've had a couple of instances where a developer has checked in against one work item within our development branch, but then when merging to our QA branch they've checked in the merged changes to a different work item. An example of this is where a bug has been created underneath a PBI, the changes in dev have been checked in against a task under the bug, but then merged to QA against the PBI itself. This causes us issues with traceability.
I've seen that it's possible to add a check-in policy of "Work Item Query Policy". I'm just wondering if there is a way to write a query that will determine if the work item of a check-in after a merge matches the work item of the source changesets? I'm not necessarily after the exact query (though it would be lovely if someone could provide one :) ), really I'm just wondering whether it's possible or not to have a query to do this - i.e. is the information available to queries in TFS?
You can't do this with the existing policies, you'd need to build a custom policy.
So, technically this is possible. You can access the VersionControlServer object through the PendingChanges object:
this.PendingCheckin.PendingChanges.Workspace.VersionControlServer
You can use that to query the history of the branch in question and grab the work items associated to the check-ins in that branch.
You can check the associated workitems to the current workitem:
this.PendingCheckin.WorkItems
You could probably even provide the option to auto-correct by adding the correct work items to the checkin upon validation.
One of my policies provides an example on using the VersionControlServer from a policy.
So, we have this one project which uses Cloud Storage and BigQuery as services. All has been well.
Then, I wanted to add Cloud SQL to this project to try it out. It asked for a unique Project ID so I gave it one. (The Project ID is different than the Project Number.)
Ever since then, I've been having a difficult time accessing my BigQuery tables. When I go to the BigQuery web interface, the URL contains the Project ID instead of the original Project Number. It shows the list of datasets, but now shows the Project Number before each dataset name and the datasets are greyed out and inaccessible. If I manually change the URL to contain the Project Number instead of the Project ID, it appears to work although it shows the list of datasets in the left nav twice, one set greyed out and inaccessible and the other set seemingly accessible.
At the same time, some code that I've been successfully using in Apps Script that accesses BigQuery is now regularly failing with a generic "We're sorry, a server error occurred. Please wait a bit and try again." I'm not sure if this is related to the Project ID/Project Number confusion, or if it's just a Red Herring.
Since we actively use the Cloud Storage service of this project, I am trying to be cautious with further experimentation with this project. I'm not sure if I should delete the Cloud SQL service in this project to get it back to the way it was, or if this is a known issue with some back-end solution. Please advise.
After setting the project id, there can be a delay where BigQuery picks up the change. It should happen within 15 minutes or so, but sometimes it takes longer.
If you send the project ID I can make sure it has been updated.
We've been using TFS since around 2009 when we installed TFS2008. We upgraded to TFS2010 at some point and we've been using it for source control, work item management, builds etc.
Our TFSVersionControl.mdf file is 287,120,000 KB (273GB). We ran some queries and found that our tbl_BuildInformationField table is massive. It has 1,358,430,452 rows which takes up 150,988,624 KB (143GB). We have multiple active products over multiple active builds which more than one solution per build and the solutions aren't free of warning messages.
My questions:
Is it possible to stop MSBuild from spamming the
tbl_BuildInformationField table so much? I.e. only write errors and
general build information and not all the warnings for every
project?
Is there a way to purge or clean up old data from this
table?
Is 273GB for 4 years of TFS use an average size?
Is 143GB for tbl_BuildInformationField a "normal" size?
The table holds the values and output of build process. Take note that build retention policy doesnt actualy delete the build object like everything else in TFS the object is marked deleted and only public visibility and drop location is cleared.
I would suggest if you have retainened same build definitions for very long time (when build definition is deleted the related objects get removed as well) you should query for build info including deleted ones using TFS api, the same api will also alow you to remove them for good. Deleting build definitions probably will not work and will fail with timeout error.
You can consult the following:
http://blogs.msdn.com/b/adamroot/archive/2009/06/12/working-with-deleted-build-data-in-team-foundation-server-2010-beta-1.aspx
I have come across an issue that looks like TFS has permanently deleted a branch and all of its history and is not giving me the ability to interact with any of the changesets that were in that branch. Here is what happened:
I created a new branch(A) off of an existing branch(B).
I used A for a few months.
I merged everything in A back to B.
I deleted A by right clicking on the branch in Source Control Explorer and clicking delete and checked in the change.
[At this point I didn't check to see if A could be undeleted, and didn't notice anything amiss]
2 weeks pass
Now I want to view the history of a file that was merged
I go to the visual studio settings and check the box that shows all deleted items
A is nowhere to be found
I check to see if some other branches that I had deleted in the past were visible, and they are still present.
I look in the change history of the parent directory and I can't even see the changeset from when I deleted A.
I have admin access to the TFS database, but don't understand the schema well enough to search for all "delete" changesets.
I've tried to use the API in Microsoft.TeamFoundation.Client to get more information, but it isn't providing any more records that the TFS history window did
Update
I just ran a a tf destroy command on a test branch to see what the symptoms are, and the symptoms are consistent with what I'm experiencing. I suspect that this branch was destroyed, now my goal is to find out if destroy leaves behind any information about who or when
Further investigation reveals that a team member on a different project had run a cleanup script during the two week period that had invoked the destroy command, accidentally destroying some of our deleted branches. The advice in How to find out who ran the TFS Destroy Command? revealed who it was, and how it had happened.