I moved some work items from another project and my planned in the velocity dashboard item is showing nothing for the previous iterations in the planned but the completed are showing.
i was expecting to see how many were planned for the sprint in the past
Related
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.
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.
JIRA tracking issues by creating reports. It shows total estimate of the project, how many time have been taken by a project. What should be the outcome of the project?
Now my question is: What are the types of reports which have been generated in JIRA.
We can generate following reports in JIRA:
1) Average Age Report:
It shows that how many issues are pending or unsolved. Accordingly it will generate a report and give you the particular picture of the project about pending issues.
2) Issue Created vs. Resolved Issues Report:
By the name we can understand that it will create reports for created issues and resolved issues report which will display whole the scenario of the project and display the work done by the Team.
3) Pie chart Report:
It will display issues status with different colors so we can identify the project status or sprint status easily.
4) Project Pivot Report:
It shows that how much time has been taken by the users for verifying project for the specific period?
5) Recently Created issue Report:
It will display all the detail for recently created issues which shows that how many percentage of the project is completed and how many project is pending.
6) All the dead line of the project have been followed or not, all the issues are solved or it has in progress status this all can be verified by reports.
7) We can create sprint report, Epic Report, Version Report, velocity chart, control chart, cumulative flow diagram too.
Progress Report has been shown from here:
Blue line indicates ideal task remaining and red line indicates actual task remaining.
With the help of Pie chart we can see that different status have been displayed with different colors:
8) It also gives reports of Project status or Sprint status.
1) Average Age Report — Shows the average age (in days) of unresolved issues.
2) Created vs Resolved Issues Report — Shows the number of issues created vs the number of issues resolved over a given period of time.
3) Pie Chart Report — Shows the search results from a specified issue filter (or project) in a pie-chart, based on a statistic of your choice.
4) Resolution Time Report — Shows the average time taken to resolve issues.
5) Recently Created Issues Report — Shows the rate at which issues are being created.
6) Single Level Group By Report — Shows the search results from an issue filter, grouped by a field of your choice.
7) Time Since Issues Report — Shows the number of issues for which your chosen date field (e.g. 'Created') was set on a given date.
8) Time Tracking Report – Shows time to track information on issues for a particular version of a project.
9) User Workload Report * — Shows how much work a user has been allocated, and how long it should take.
10) Version Time Tracking Report * — Shows progress towards completing a given version, based on issues' work logs and time estimates.
11) Version Workload Report * — Shows how much outstanding work there is (per user and per issue) before a given version is complete.
12) Workload Pie Chart Report * — Shows the relative workload for assignees of all issues in a particular project or issue filter.
I just want to create report from Jira (Chart report showing total bugs of weekly report for 2 projects) I tried using time since report.Generated graph displayed total bugs for the 2 projects, But I want 2 projects name with each issues associated with project for each day.Is there any way to get the report?
I guess you are in search of a Dashboard. Dashboard will keep you update after regular interval about the status of the project. For creation of a dashboard you will need to create a filter first and then the Dashboard.
Create filter according to your requirements. i.e. search issues logged by QA in particular time period, in particular sprint etc.
This link will help you https://university.atlassian.com/uac/2.0/courses/end-user/jira/v60/search-and-filters/save-and-share-filter#/lesson-content-header
After creation of the Filter create a dashboard.
Follow steps mentioned in below link https://university.atlassian.com/uac/2.0/courses/end-user/jira/v60/dashboards/create-share-customize-a-dashboard
https://confluence.atlassian.com/display/JIRA/Customizing+the+Dashboard
Hope this helps you.
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.