I would like to know if it is possible to customize the release management interface for on-premise TFS 2017? I would like to put some controls like combo boxes, pick lists, etc. on the UI to codify user selections rather than have free form text entered by the user.
I assume you mean tasks in release definition, you can custom build/release task through extension, more information, you can refer to Add a build task (apply to TFS2017).
If you mean the general boxes in release definition, no you can’t custom.
Related
In our organization we use TFS 2018 and Visual Studio 2017 Enterprise.
As far as I got until now, there is a way "client-side", configuring from Visual Studio, selecting Team\Team Project Settings\Source Control\Check-in Policy\Code Analysis and I should the custom ruleset defined.
I need two things:
Set a custom guideline that is mix of both default Microsoft ones and other tools' guidelines, like Roslynator or StyleCop.
Create a custom policy server side in order to prevent check-in from Visual Studio (or whatever client we can think of) if code is not compliant to those guidelines.
For the first point, I'll make a clear simple example.
There are the guidelines embedded in Visual Studio.
But they are not complete and I would like to extend them, taking stuff here and there or defining new ones from scratch.
I want to use e.g.:
CA1500: Variable names should not match field names (from default Visual Studio Managed Binary Analysis)
RCS1145: Remove redundant 'as' operator (from Roslynator)
RCS1204 Use EventArgs.Empty (from Roslynator)
SA1302: InterfaceNamesMustBeginWithI (from StyleCop)
SA1305: FieldNamesMustNotUseHungarianNotation (from StyleCop)
How can I do it? And can i do it without make me define it at project level (like incorporating stylecop file for every .csprj) but more at least at solution or Team Project level?
For the second point, I already defined the compulsory comment and compulsory work item attached.
And I can even define new policies, it's true, but they can all be overridden client side.
Is it possible to prevent that?
The best solution for this is two part:
Educate your users to configure the right policies and editor settings. Creating custom project templates and distributing those can help (or deploying a custom build target onto the machine which enforces good defaults.. Having a good local policy will help people do the right thing and people who are supported to do the right thing will likely not try to get around that.
Setup a CI build for your projects. VSTS and TFS have a nice feature which will run a build whenever code is changed. You can even set it up as a Gated Checkin build which will check the sources before they're checked in. This check happens on the server and is much harder to by-pass. You can also configure the build to always override the code analysis settings, even if they're not configured in the project. My MsBuild Helper tasks will help you setup the right MsBuild properties to do that.
As to your more specific questions:
You cannot setup Code Analysis Rules at the Team Project level without also configuring the ruleset for all Visual Studio Projects. Otherwise the checkin policy will cause the check-in to fail, but the developer will then still have to update all projects in the solution with the right ruleset.
You cannot prevent people from by-passing the local check-in policy. The best you can do is to use Reporting Services and Alerts to detect the breach of policy and take corrective action.
You could add the Rule Set into TFS source control and then select it from Code Analysis Policy Editor. Check the screenshot below:
Check-in policy is already applied to a team project, not a single project.
To edit check-in policy, you must have the Edit project-level information permission. You could deny this permission for the users to prevent them from editing the check-in policy.
I need to let users register bugs similar to how it is done in Bug tracking systems.
I'd like to create user friendly form with a layout which will guide user. Standard Create New Workitem interface is too overloaded for users.
Today we manually look through inbox and register bugs in TFS ourselves. This is really a pain. Users often do not mark the message in subject as a bug. You need to read it to understand user has a problem. Sometimes you need to ask them about the criticality level and what the deadlines for fixing it are.
It is easy to miss important message and this process distracts from main activity.
(Based on you having Visual Studio and having already connected to TFS in there)
In Visual Studio, via the menu, choose Tools > Process Editor > Work Item Types > Open WIT from server
EDIT: You will need to install the Microsoft Visual Studio Team Foundation Server 2015 Power Tools Extension in Visual Studio to gain access to that menu option above
You will then be presented with a popup box. At this point you will need to navigate to the Project Collection you wish to make changes in. Once selected you will then be presented with a list of forms you can edit. e.g. Task, Bug, Code Review etc.
If you select Task you will then be taken to a form where you will have 3 tabs. Fields, Layout and workflow. From here you have a certain level of customisation available.
I found a couple of articles (below) around customising templates. One is for TFS 2015, the other is for TFS 2013.
http://blogs.msdn.com/b/visualstudioalm/archive/2015/12/10/adding-a-custom-field-to-a-work-item.aspx (TFS 2015)
https://www.simple-talk.com/dotnet/visual-studio/customizing-team-foundation-server-2013/ (TFS 2013)
NOTE: Menu option Open WIT from server will make changes directly on the server. There are other option where you can make changes locally, then import those changes in. The above is just a way to get you to the screen to customise the forms so that you can take a look around.
My team is just now starting to use TFS 2015 Update 1 on premise to manage their development process. I have set up the server and defined some custom states and transitions for work items to better map to our process. To start with, we will only be taking advantage of the Kanban board and are not attempting to use iterations for a variety of reasons I won't get into here.
My problem currently is using TFS to plan releases. Specifically, I don't see any way to group Features and User Stories into a specific release. All of my googling has turned up many articles involving Microsoft Release Management, so I installed and configured it, but it is absolutely overkill for what my team is trying to do right now. I'm not trying to automate deployments to different environments at the moment, I just need a way to group work items into a something that encapsulates the concept of a release in TFS. Is there no way to do this? The best I can come up with right now is to further modify the work item templates to either provide a simple "Release" field with a pick list, or define another type of work item that I can group the others into. This seems like a glaring oversight by MS from my perspective, so I'm hoping I'm just missing something.
Grouping work into releases can be done in a couple of ways, just remember that the concept of a "Release Plan" doesn't explicitly exist in TFS. Release management covers the "Release to Production", but doesn't cover any planning.
Ways to plan releases:
One way is to create a Release Iteration, this works when you're not working on multiple releases in parallel and truly finish one release before working on the next. The Release iteration used to be default, but has been removed from the product in favor of teams delivering sprints and teams doing continuous delivery.
Project Root
+ Release 1.2
+ Sprint 1
+ Sprint 2
Another option is to use Tags. You could tag work items with a tag that signifies it's targeted for a specific sprint.
Use a Marker workitem, on the backlog place one work item which clearly stands out ### END OF RELEASE 1 ### Any workitem below it is not part of that release. This technique fits a more agile way of working and more clearly shows that the contents of a release are a floating thing.
Create a custom Release Workitem, link your other workitems to this work item to target it for that release.
And your option to create a picklist on a *Custom workitem field** is another option.
Alternatively you could also use the Area Path in much the same way as Iteration Path. By using the Area Path you have the benefit of not having a sprint tied to one specific release.
It is not the best solution but could be the solution in some cases.
Answering solely based on your question around planning releases, then:
Create a custom work item template, called 'Deployment'.
When planning of a release begins, create a new 'Deployment', let's say, called 'MyProduct v1.1'.
In your planning meeting, create Features and User Stories appropriately, and create a relation to the 'MyProduct v1.1' Deployment, by opening the User Story and adding a Link (using the Deployment Work Item number) as 'Related'.
To monitor Deployments, create a custom Work Item query targeting the new 'Deployment' Work Item template. You can configure this to display on your dashboard.
Follow whatever release procedure you like based on the 'Deployment' and its' relations.
You should follow a naming convention when creating 'Deployments' for consistency.
p.s. I recommend using the extension 'Work Item Visualization' in this instance. It'll nicely map out the 'Deployment' related Work Items.
If you want to use TFS to actually build an and create a Release, then Release Manager is worth considering.
TFS 2015 Update 2.1 now includes a built-in version of Release Manager. It's much more user-friendly and simple to configure when compared to Release Manager standalone installations.
To group work items into a 'release', you can do the following:
Create a build definition for the repository you're working with - see Build Def creation docs
Create a Release definition - see Release Def creation docs
Once you have these definitions created, the working process would be:
Developers work against work items
Commits are made against the WI number (or tasks)
When it's time to create a release, start a build on the definition you created. In doing so, WIs will then be associated with a Build Number.
When the build succeeds, start a new Release from the definition you created.
You have have a set of work items associated with a release, see screenshot:
Note: You can enable CI builds and releases, although the above is based on manual triggers.
You can also directly call the Release API to locate WIs associated with Releases, however you'll need to obtain the actual Id of the release first.
You are currently limited however to viewing these relationships based on knowing the Release. In a real world scenario, it's more realistic to look at a Work Item to see when it was release. To do that, there's no built-in functionality at present, however my own-answered question will guide you - see here.
Additional to the methods explained by jessehouwing there exists also several 3rd party tools which can integrate with TFS/VSTS and provide advanced planning features. See VSTS Marketplace for an overview.
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.
We do this using the Advanced button on the checkin dialog now (with Merant, nee PVCS) but the Advanced button is disabled when I set TFS as my SCC provider. Is there a switch we can flip on either side to enable this?
Or do we need to write some custom extension?
Or can I get the TFS changeset number to associate with the change in PB?
Or am I coming at doing selective builds entirely the wrong way?
We can achieve what we want by creating a Note field in TFS and making it required on check in. The SCC interface will make the TFS check-in dialog appear & force the developer to enter a value in the field. We can then use the Note to find the associated changeset & do extracts based on the changeset. Thanks to all who looked at this.