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.
Related
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 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)
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.
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 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.