We have over a thousand old tickets in our Jira, most of which we'll never get to. What are the best ways to hide those from the backlog in a way that we can most easily get them back if we want to?
Ideas:
give them a label and then complete them as won't fix
create a special "archive" project and move them in there
Pros & cons to those? Other ideas?
Is this with GreenHopper, and probably using a Scrum board? In that case issues appear based on your board's JQL filter. You could change the filter to add a constraint by date such as "updated < -200d" to excluded issues that haven't been updated in 200 days.
I wouldn't bother moving them to an archive project. Labels can be useful for other things.
I suggest archive it somewhere if you never intend to reuse it.
You can use this project to do so: https://gitlab.com/kaszaq/jiratomkdocs/
Related
Using Visual Studio Team Services (Online version), I would like to have a simple display for my "Backlog" and "Board" :
Features
Tasks
Bugs
That's pretty much it. I don't want to do anything with, iterations, sprints, user stories, etc.
This is just a one man project and I'm just wanting to see all thing on the backlog/board so I can better manage the project.
EDIT:
Biggest issue I had with this...
My project was setup to use the "Agile" process. I decided to try Scrum process instead and found this to be the deciding factor.
Once a project is set as Agile/Scrum, it cannot be cahnged... So, I Made a copy of "Scrum" process, named it "Scrum_custom", created a new project using this method, then just git pushed my existing project code to the new one.
I marked Daniel Mann's answer as correct seeing as it's what I ended up doing after changing to Scrum and it seems to be working just as I'd hoped!
Just in case anyone else reads this and is looking to do something similar, I would recommend this route...
Under your team configuration, you can change the backlog levels you use. In your case, you want to turn off PBI/User Story.
https://www.visualstudio.com/en-us/docs/work/customize/select-backlog-navigation-levels
Alternately, you could just use PBI/user story instead of Feature. They're the same basic thing except with different names; it's purely a hierarchy thing:
Epic -1 to many-> Features -1 to many-> PBIs -1 to many-> Tasks
Bug behavior is configurable; they can either be treated as requirements (at the same level as a PBI) or as tasks.
If you link Task and Bug to Feature as child, you can manage them in Feature Backlog, but not Kanban board.
To link them as child, you can open a work item > Links> Add link>New Item>Select Child link type.
As in subject:
Go to "Find Changeset" option.
Find a changeset.
Double-click on changeset to open Changeset Details window.
It gives a list of all files that have been checked in within given changeset.
Why I cannot apply a label on those files from that level where I have them all in one place? Especially, that very often they are part of different solutions and projects, so normally I would have to create a label for one file and then search and add one by one to the existing one.
It is so inefficient!
Is it some bug or lack of functionality? If the second - it is hard to believe MS guys forgot about such handy function.
How do you deal guys with such situation?
EDIT - to clarify my reasoning:
If I use jessehouwing's method - yes, it works and it's simple.
But then when I search in the future for that label and want to see what code was included, it gives me a list of all solutions - even those totally unrelated (IWP and PDPRO are the unwanted ones):
If I use it my way - it gives me that:
I think it looks cleaner and gives directly the information of what solutions and files underneath where included at the time when I put stuff into Production environment and applied corresponding PROD label.
The feature you're looking for doesn't exist. generally a single file or group of files at a label doesn't make a lot of sense. While it's possible to "scope" labels in TFVC, it's only possible through the commandline.
generally you'd create a label at the repo or branch level at the specified changeset. That will include all files, including the ones you just checked in. Creatign such label is relatively easy from the source control explorer, though you need to copy the changeset number:
It's unclear to me why you'd only want the changed files to be included in the label, maybe you can elaborate a little more on that requirement.
Update: What you desire isn't possible from inside VS and isn't simple from the commandline either. I suppose that with a bit of Powershell Magic against the TFS Client Object Model you can do this from the commandline and it should also be possible to build this as a Visual Studio Extension (or maybe suggest it to the author of the TFS Source Control Explorer Extensions.
We are using TFS 2015 together with the CMMI process template and I have just found out that Issues do appear on the backlog if they are a child of a Feature or a Requirement work item type. If the Issue is standalone (has not link to one of the two mentioned work item types) it is not visible on the backlog.
I guess that someone has made some hacks here in order to make this possible. Originally, only Epics, Features, Requirements, Tasks, and Bugs should appear on the backlog.
I have checked the Issue work item type definition as well as the processconfiguration.xml and the categories.xml which look quite ok from my point of view.
Are there any another places where one could define which work item types should be visible on the backlog?
Thanks a lot for giving support.
To add a WIT on backlog, the three files below need to updated:
WIT Definition
Categories Definition
ProcessConfiguration Definition
You can check the required changes on this link: Add work item types to backlogs and boards to see if these changes had been applied on your project. If yes, revert these changes, then the Issue should disappear from the backlog.
You should not use the "child" link to associate with Issues.
The Parent/Child link is used for the backlog and I would think that the Issues are appearing because of this.
Try changing the Parent/Child link to Related.
I am trying to come up with best practices regarding use of TFS source control. Right now, anytime we do a build, we label the files that are checked into the TFS with the version number. Is this approach better or worse than simply checking the files in and having the version number in the comments?
Can you then use the changeset to go back if necessary or the labels are still more versatile?
Thanks!
They have two different purposes, ChangeSets are when the files have actually changed and you wish to keep a permanent record of that change. Labels mark a certain version of the files so that you can easily go back to that point. Unless your build actually changes files under source control and you wish to record these changes. You should be labeling.
Also, labeling is much less resource intensive. And you can have multiple labels on the same version of a file.
You should label the versions of source files that make up your build. If you're using TeamBuild, it does that for you automatically. It combines the name of your build definition, date, and the build number. So you don't need to do anything.
Your other option is not very conventional and requires a lot of unnecessary work. If I understand it correctly, you would check out your source files during the build process and then check them back in with a version number specified in the check-in comments. This is as Alex mentioned very resource intensive in terms of your build process and also your source control repository. Moreover, how would you get the source files for a particular version if the version information is embedded in the comments? It will be very hard and you would have to sit down and write your own application that uses TFS source control api to download the source files to a workspace by searching for the version number in the check-in comments. This creates unnecessary complexity and headaches.
If you use labels instead, you can do a get by label in VS IDE to download the source files that make up that label. You can even tell TeamBuild to use a label instead of downloading the latest source files during build automation. That way you can build previous versions of your application easily. With labels, you can also apply later changesets to an existing label if there were code changes by simply getting that label and then getting specific changesets and then doing a quick label or creating a brand new label.
Labeling is very powerful, convenient to use, and is a part of TFS. Rather than coming up with your custom solution that requires a lot of effort to make it work and maintain, just try to use what's already available.
Right now, anytime we do a build, we label the files that are checked into the TFS with the version number
You don't need to do this. TFS can refer to a state of the codebase in numerous ways, of which labels are indeed one - but so are builds and even changesets. You can see the available ways to reconstruct a particular point in time by doing a Get Specific Version... and examining the options in the Type dropdown:
Changeset
Date
Label
Latest Version
Workspace Version
Changeset allows you to get just after any changeset; Date is obvious; Label is too, except that builds automatically* create labels (choose Label from this dropdown then have a look in the Find Label dialog).
*I think it's automatic! Unless it's something we've set up specially where I am at the moment...
StackOverflow won't let me comment on the answers above, so I'm writing this as a new "answer". I want to clarify some of the misconceptions listed above.
First, using TFVC Labels is MORE resource intensive than using changesets. A lot more. Commands such as Branch, Merge, and Get by Label is slower. For enterprise servers with huge databases you do not want to be using labels.
Second, Builds don't automatically create labels, although the default build steps include a step to create a label.
Third, as others already mentioned, labels can be moved or deleted, so they are much less dependable than changesets which are immutable.
Overall I recommend you NOT use labels. The simplest alternative is to just remember the changeset number for your builds. Or if you want to isolate different release versions, you should create release branches.
Labels are OK for small systems, but are not good for large enterprises.
I have a requirement and I am not able to figure out the solution. Any kind of help is appreciated.
We have customised the process model.
Issue.
I have FactTable say Release, Release has Project, projects would internally have different states, development-production-QA. what i need to do is generate a query that would get me all the defects that are open for a particular project, for a selected stage and selected release.
Is this possible?
Can we write sub query in TFS?
I would appreciate any kind of help provided.
If I had to do it, I would make itrations for: development, production, and QA.
Then iterations shows everywhere from the simple query to the TFS Warehouse!
You can consider Release as team Project Collection, then Project as team Project. For development-production-QA stages you can either use Area or create a custom work item field "Stage" with reportable attribute as "dimension".
Now you can use wither TFS_Analysis i.e. Cube or TFS_Warehouse to get your data.