I have a team project that contains n number of branches, and each branch contains a Database folder in the root. The database folder is where developers check in views, stored procedures, etc. We have had some issues with developers checking in SQL Code that was poorly written, introduced performance bottlenecks, and so on. The DBA has asked me to prevent developers from checking in changes to the Database folder until he has had a chance to review them.
I know that I can add a 'Database Reviewer' as part of a required check-in note, but I don't need a database review every time a developer checks in; I only need the database review to be required if the changeset contains changes to the Database folder. I haven't been able to come up with anything worthwhile on Google, so I don't think that this is functionality that is built in to TFS. Could someone point in the direction of how to resolve this, or explain how they resolved a similar problem in the past?
Thanks!
There is no clear cut solution for this, but you have a few options.
Remove the check-in permissions to the Database folder for normal developers and have them send their changes as a Shelveset to the Database guy.
Ask the developers to become more professional and have them walk by the SQL guy to review their code with them, so that they will be more proficient in SQL later (would be my preferred choice is the SQL Guy isn't part of the team)
Ask the SQL guy to join the team and have him pair with the developers when writing complex SQL scripts (that's even better).
There is no option to make the check-in note optional for specific branches, folders or files right built into the product, but by developing a custom checkin policy you could require data to be entered in the Database Reviewed field. Combine this with the Custom path policy to limit this check-in policy to specific paths in source control.
That custom policy would look something like this:
public override PolicyFailure[] Evaluate()
{
if (
PendingCheckin.CheckinNotes.CheckinNotes.Values.Any(
note => note.Name == "Database Reviewed By" && string.IsNullOrWhiteSpace(note.Value)))
{
return new PolicyFailure[]{new PolicyFailure("Database Review Required", this) };
}
else
{
return new PolicyFailure[0];
}
}
Check out this small sample project to see how you can create a custom checkin policy. And the requirements if your Check-in policy needs to support multiple Visual Studio versions.
TFS 2012 adds a Code Review feature which can be made required using a 3rd party check-in policy (again, combine with the custom path Policy to make it required only for certain paths). There are a few projects on codeplex that provide similar features for older versions of TFS. These include Team Review and TFS Review Workflow.
There isn't anything built in to handle this. I think the best way to handle it would be to lock down those folders so developers can't check in there. Create a branch/folder where you can allow the developers to check in there. This would give the DBAs the ability to review the changes before they merge/migrate them.
TFS 2012 includes a code review workflow that could also be used if you could upgrade TFS. There is also a custom add-on called Team Review that works with TFS 2008. It provides a nice workflow but it would still be voluntary.
https://teamreview.codeplex.com/releases/view/40528
Thanks,
Mike
Related
How can I see who has accessed files in a team project in TFS? Normal View History only shows you check ins. And exporting the Audit Log from TFS doesn't show you this info. I am interested in knowing who has made a read/get latest access on a specific team project.
This needs to be documented for my QA department. Are there any TFS SQL scripts that can show this info?
Sorry, we do not have this kind record of User's each operation such as read/get latest on a specific team project.
As you have mentioned history command will only displays the revision history of one or more files or folders. It only related to each changeset(checked in files).
Audit logs basically display some modify operation in TFS will also not include any access info at present.
Dig into sql database to query such information maybe a solution. However, highly not recommend to do this, since it may cause some potential risks of your database. And it will also lose support from Microsoft.
This should be a feature quest, you could submit it here. Our PM will kindly review any suggestion.
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'm in the process of migrating some source code from an in-house system over to TFS 2015. I'm using the APIs via Microsoft.TeamFoundation.VersionControl.Client etc libraries.
Ideally I would like to also import the history of each item including who made the change and when.
The workspace.CheckIn method allows me to specify the "author" who made the change, but I don't think it's possible to supply the when.
Does anyone know if's it possible to "back-date" a checkin?
You can't change CreatedDate of a changeset. In fact you should not be doing this in the first place.
Even if you manage to change somehow then you will loose the track of when you really created/check in the changeset on TFS.
If you are upgrading older TFS to TFS2015. Which is a full data transfer. TFS sever will also include the back-date changeset. However you are using an in-house system, just the same as checking in code from local development.
So you may have to manually manage the source control history of your in-house system, such as import to a Excel.
So I've been trying to perform a migration (code only, no work items) of a medium sized project from an on-premises TFS2010 to VSTS using the OpsHub tool. My user is an administrator on both sides, and the migration runs and completes without tossing errors.
The problem is that it just doesn't do what it says it will. I spent a long time mapping the users from TFS to VSTS during the setup, but it completely ignored that mapping and assigned every single changeset to my VSTS account. The docs also say that it should preserve the original TFS check-in time in the comment of the new VSTS changeset, but it never does that to any of them -- the comments are just brought over exactly as they were.
It seems like there must be a setting set wrong in OpsHub to turn these features on, but I can't find any kind of options screen or anything in the tool. It looks like other users are able to successfully map the TFS users to the VSTS users and have it work like you would expect, but I can't make heads or tails of it.
Thanks for any help or advice on this.
If you are using the free version then this feature is not supported by it and same is mention on the visual studio gallery download page, only the commercial version of migration utility supports partial user impersonation, i.e. writing changes as per configured user mapping.
I'm asking this question because I haven't seen it documented anywhere.
We are using a combination of Team Foundation Server 2008 and Team Explorer 2005.
Is it possible to deploy a custom check-in policy that works in such an environment ?
Obviously, the custom check-in policy contains some code that must run on the client-side (in order to display help, etc.). So it should use the Microsoft.TeamFoundation.VersionControl.Client assembly that comes with Team Explorer 2005.
But, my sense tells me that, in order to be effective, a check-in policy should be enforced on the server itself (for example, to support checking-in changes from the command-line or using the raw Web Services API). So, there, it would have to run against the Microsoft.TeamFoundation.VersionControl.Client that comes with Team Foundation Server 2008.
So, is it possible to build a single custom check-in policy that takes the most recent version the Microsoft.TeamFoundation.VersionControl.Client assembly (2005 on the client and 2008 on the server)?
Or do I have to build two custom check-in policies, one for the client and one for the server ? Would that even work ?
Or do custom check-in policies only ever exist on the client side ?
The custom check-in policies only exist at client-side, and will only be evaluated client-side. If the DLL is missing on the client computer, TFS will complain, but provide a dialog that allows the user to override the error and check in anyways.
No, it's not required. However, it makes things much easier. Using the latest Power Tools you can store check-in policies in source control and have them deployed for "free."
A walkthru with screenshots is on Brian's blog:
....Since the day we introduced those features, customers have asked for a way to distribute custom components like these to clients rather than having to manually install them. Well, I'm happy to say that this new release of the Power Tools does just that!
Due to the fact that downloading custom components and running them on clients can be dangerous, there's a fair amount of care taken and some configuration necessary to enable it. Custom components for a Team Project are checked in to a new "special" folder called $//TeamProjectConfiguration. Let me show you a few screen shots and that will help walk you through how this works....