In TFS (2010 and up at least), we have the concept of iteration, which seems to be supposed to help assigning work (what do we do in release 1.0, what is planned for 1.1 and what is left in the backlog). I have to mention I've been looking at the Scrumm template for TFS2012.
Now, how do you classify bugs by product version?
For example, imagine we have the a product with v1.0 and v2.0 in the wild and v3.0 in developpment.
Now, we discover a bug in v1.0, and it turns out v2.0 and v3.0 also contains the bug.
Code-wise, we'll correct the bug in dev, then merge it to v1.1 and v2.1 so that our current users are not left in the cold with their version (because we cannot always mandate upgrading to the latest version).
When creating a bug in TFS, we have the option of indicating an iteration path. But we can only use one iteration, whereas we need to be able to declare the bug as existing in all three version, and mark it as corrected independently as the merges happen.
Is there any way to support that way of working in TFS, or am I looking at it wrong?
One way to accomplish this would be to modify the default Work Item Type for Bug in TFS:
In VS 2010, open the editor by choosing Tools > Process Editor >
Types > Open WIT From Server from the main menu
In the Select Work Item Type dialog, expand the Team Project
that you would like this template to apply to, select Bug and
click OK.
When the editor opens, you'll see a list of all available fields for
the Bug work item. You should notice a Found In field
available in the list. By providing the version number(s) in this
field, it should be pretty easy to write queries that can find bugs
by version.
To display this field, choose the Layout tab to bring up the
form editor. It's basically just a big tree view. Expand the group
for Group - Classification (or wherever you think this field is
most appropriate), right-click Column and choose New Control
In the attributes panel, choose Found In for the Field Name, and
also update the label.
Choose Preview Form to test your changes, then save and close
the editor
There are a number of ways around this, depending on how you choose to approach it. One is to not use the standard Areas field (Mike C suggests a good alternative). Another is to create work items to more accurately reflect the state of the work you're doing. What I mean is this:
If you're releasing a fix across three different versions of your software, I'd assume that you'd want to test it against all three versions to assume the fix is consistent across all of the codebases. A fix that worked in V1.0 may not work the same in V3.0 because the surrounding/affected code may be different.
At some point in that process you could therefore have three separate (but linked) representations of the bug: maybe three copies of the bug itself, or three test cases (one per version that the bug should be tested on) all linked to the original bug. Then, if the bug is fixed in V1.0 but requires more work to be fixed in V3.0, your work items accurately reflect this.
Related
I'm using TFS 2013 Update 3 and Release Management 2013 with Update 3 (agent-based templates).
In the Release Management client, I'd find very useful the ability to add a comment for any action/component (or even a group of them) that is part of a deployment sequence. This is because often it's obvious what an action/component does (e.g. "Move File or Folder"), but it might be useful to know why that is done, also in the context of that particular deployment sequence.
I haven't found a way to achieve that, is it actually possible?
If not, do you have any alternative solution or do you know if a similar feature is available in newer
versions?
One thing you can try (but I am not sure if Agent-based Update 3 allows it) is to rename the action/component once dropped on the canvas. I know vNext templates allows it, and some earlier versions of Agent-based allowed it (but not the recent one... it seems to be broken).
Another less optimal option would be to add a parameter (which would be ignored during the actual deployment) - call it 'Notes' or similar - and just fill its value with the description of what this action/component does. It is less obvious and you may need to scroll to see it when you have many params, but it would be available. Also, this would only work with custom actions and components.
Last option would be to put your action/component (or group of) inside a 'Sequence'. You can rename those by clicking on the name. That would give some context on what that action(s) does.
We have recently transitioned from Gemini to TFS for application change control. There is one aspect of TFS I can't get my head around - the lack of a built-in concept of the application version that each work item will be addressed in.
In Gemini every feature request, enhancement, bug etc can be tagged with a version number. If the field was left blank, the item was "unscheduled", i.e. on the backlog. Each version could be flagged as either released or not. Reports could be then created listing the issues addressed in each released version, i.e. release notes, and the issues to be addressed in future versions, i.e. a roadmap. I was completely happy with this!
Now in TFS I can't find any built-in concept of version. It seems like there are 2 ways to represent version:
As a parent item in the iteration tree, e.g.
Version 1.0.0
Sprint 1
Sprint 2
etc
Version 1.1.0
Sprint 3
Sprint 4
etc
As a parent item in the work items tree, e.g.
Version 1.0.0
Requirement 1
Requirement 2
etc
Version 1.1.0
Requirement 3
Bug 4
etc
The latter approach looks better because it allows versions to be worked on simultaneously (e.g. a major release will be worked on at the same time as bug-fix release).
So what is the recommended approach to managing work by version?
Finally, with the version property not actually being present in the work item itself, is it possible to make reports on issues addressed in each version?
For now I am going to use iteration path to capture the version number. This doesn't lend itself so well to managing development on different versions concurrently, but we are trying to get away from that practise (i.e. be working on the next release while simultaneously working on multiple bug fixes to past releases) and adopt short release cycles, i.e. a more linear path, so maybe that is a good thing.
Earlier I though Area Path might be a good place to put Version, but its too valuable as a way to split up a huge application into parts to sacrifice for versioning.
1. Tags (TFS 2013+) are the easiest way to append metadata such as build#. (same as mentioned above.)
2. The CMMI Process Template > Requirement and Bug Work Item Types have an "Integrated In" field that links to TFS Builds for direct correlation from requirement to build# [to related code changes] [to related test cases [to related test results]]. Note you must select from retained TFS Build system builds (that have not been deleted). This hard reference drop-down limits this field significantly over time or if you use a different build system. (That and build versioning are entirely different discussions :-).) The Build CMMI template fields have been there since TFS2010.
3. Create a custom field in your User Story and Bug work items. BuildImplementedIn or similarly named field would do. Creating custom fields is not hard in TFS. You will need a Team Project Admin or possibly a TPC Admin to make the customization if you aren't already an admin.
p.s.: Sorry for the late reply. I posted this answer in case others still have the same or similar question.
You could use the area field.
We use that one for product name (we maintain multiple products) and then version goes into the description of the story, but you could use the area field for versions.
Another possibility is to use tags at the top of the Product Backlog Item.
Btw, I agree that TFS is lacking a few important fields (custom fields)
I'm evaluating TFS as a replacement source control option for company, and documenting how our current processes would change or stay the same if we start using it.
We use labels fairly heavily in our current product, not just for creating snapshots of a given build, but also for targetting specific modifications for future builds. Our standard is to always check-in each file with a label of the release version it's intended for.
Our current software has an option for "Label" right on the check-in screen, so checkin/label is a one-step process. Is there a way to do this with TFS? I see that you can open the source control explorer and label things after the fact, but if users are going to have to go clicking around to find the right changeset to label after the fact, I want to be sure to document that...
I'm not aware of a way of auto labelling every check in, but a couple of options spring to mind.
You can set up a list of text fields that must be filled in (in the check in notes section of the pending changes dialog), and even make these fields compulsory, so it would be easy to add a "for version" note to every check in. IIRC this is set up by right clicking on the team project in team explorer and going to the source control options.
TFS raises events for actions like check ins, so you can use the TFS api to handle the event on your server and add a label automatically. You could even pick up the check in notes to tell your code what the label should be.
This may be where you need to change your current processes. With TFS (or other version control systems), all the developers targetting a particular release should all be working with the same branch in TFS, i.e., you have a dedicated branch for each parallel development stream. Thus the need for labels is reduced. This is a much better approach than using labels, because you can look at a branch and see what will be in that release, without having to sift through labels to see if a particular change applies to the release.
I suggest having a look at the Visual Studio Team Foundation Server Branching And Merging Guide.
I'm using Axosoft Ontime for bug tracking, and have configured several 'release' items under my project.
'Default' (ie. bug) list has a field named 'Release' that displays on forms as a dropbox of all available 'release' items. Fine. I use it as a flag for target release for each bug.
What I'd like to do is add several fields of that type, that would allow me to define, for each bug, a "bug found on this release" and "bug was actually fixed in this release" on top of the original "bug has been scheduled for this release" field.
The bad news is that this 'Release' field comes by default (ie. is not a custom field) (or so I guess) and thus is not accessible through my Tools > Manage > Custom fields.
Do anyone know how I could add other fields of the same type?
(I'm using OnTime 11.0.1, winforms version; but could start using web version if needed)
Thanks in advance...
Official OnTime support team answers a radical no (as of v 11.2). Sad but clear.
OnTime currently supports only 1 release field. If you would need to
store an additional release field you can add a custom text field to
enter in the release, or use a custom picklist field. You however
would need to update the pick list with any additional releases in
order to update the values when you add a new release.
Since using text fields as they suggest seems a very bad idea (users are free to input incorrect data, release names are not sorted), I will probably have to maintain a gigantic pick list.
Has anyone a better idea?
There seems to be a way, not the kind I would like, though, as it requires hacking the database itself. I haven't tested it so you really should use it with caution.
OnTime supports pick lists that are dependent on a database stored procedure. The trick would be to build a request on Release table and bind a pick list to it.
A (very basic) documentation can be found as podcast on http://www.youtube.com/watch?v=bqg3GZlx6dc
I am still on the lookout for a Eclipse-like ROR IDE (at least it should have the functions that I am more or less used to having), and have decided to conduct a trial of RubyMine.
Unfortunately I quickly discovered two things:
Git log/history view: There isn't an equivalent for Link with Editor and Selection (it's the function that allows the history to be updated and limited to changes applicable to the active document at any point in time)
The closest is a per document history on separate tabs, there is no linking with editor or selection.
There is no way to reset to a particular commit (or branch from it) by right clicking on it. Is it really worse than gitk in this regard?!
Reset/branch at a particular commit is not possible at the Changes or the Version Control view (though possible via Checkout/Reset Head with ability to specify commit hashes). The context integration has room for improvement in this regard.
I would be very glad to be proven wrong on either/both counts.
Edit: Updated with input from CrazyCoder
There is no exactly this feature, but there is Show History from the file context menu. Multiple history tabs can be switched between in the Version Control panel.
Changes | Log panel has these actions in the context menu (New Branch, Checkout Revision).