TFS 2012 includes excellent support for code-reviewing changesets. However, we have some legacy projects that we want to code review. Once the quality has been brought up to spec, we will start using changeset reviews - however the code changes infrequently, so it's not practical to just review the changesets and improve quality through natural code-churn.
Is it possible to code-review a file or project in it's entirety, rather than just a changeset?
In TFS 2012 this is not an option. If the project is small enough there is a trick, you can right-click the folder in source control, do "checkout..." and then request the review. That allows you to review up to 4000 files at a time.
In TFS 2013 a new feature was added, Lightweight Code Commenting in Web Access. This allows you to annotate the code directly from the code tab in Web Access.
There are 3rd party code review options available on Codeplex, I haven't used them in quite a while, but they might add something more to your liking:
Team review
Team Code Review Workflow
Malevich
Related
I'm having trouble figuring out whether this exists.
I've got multiple projects in Visual Studio Online, and each one of these has its own dashboard where you can add widgets to see useful stuff like build progress.
I'm wondering whether I can use one central dashboard to see this information for all of my projects, but I can't find it. Anyone had any luck?
The short answer is no. In TFS (and VSTS) you have Collections (accessible in TFS but not accessible in VSTS), then Team Projects, then Projects/Repositories. In TFS OnPrem you can do some 'magic' to build queries that cross the Team Project boundaries but it's not supported or even recommended.
If you are looking for a way to have information about multiple Team Projects, for an OnPrem version of TFS you would use SQL Report Server. This option is not available with VSTS so your only option is Power BI.
This is exactly the use-case for Teams. Teams allow you to, within a single team project, manage and report on multiple simultaneous development efforts, including reporting across team boundaries and in aggregate. The current recommendation is to keep everything contained in a single team projects and use teams instead.
I work from a small IT department and I'm pushing to move from our current TFS implementation to Visual Studio Online. My boss who gets the final say is hesitant because "What if Microsoft decides to stop offering the service, without notice, or their servers fail how will we get our code". While I find such a scenario unlikely and the scenario of our TFS server crashing and burning with no backups/bad backups much more likely. I still need to address his concern.
Does anyone know of a way to "backup" a remote TFS implementation? So far the only thing I've come up with is doing a nightly pull of Visual Studio Online and submitting it to a local repo, feels hacky, feels wrong.
Take a look over at the discussion on this StackOverflow question: Is There A Way To Backup Visual Studio Team Services Projects?
Here is Richard's answer:
There's no out of the box backup ability.
Now, if you are only referring to source control, and not work items,
pull requests, builds, test plans or anything else that the service
offers, then I'd suggest you migrate your code over to git.
With git every developer will have a complete copy of the source
repository, including all history and commit comments. From there,
it's a simple task to push the git repository to a different git
hoster (such as bitbucket or github) and make them your new centrally
hosted git repository.
On a historical note, Visual Studio Online at one point offered a data
export for a period of time. You might want to add a vote or three to
this related UserVoice idea to help raise the importance of the
feature with Microsoft.
Side comment: The business risks in using Visual Studio Online will
come from either Microsoft shutting down the Visual Studio Online
service or that the underlying Azure infrastructure has such a
catastrophic failure that your Visual Studio Online account is
unrecoverable. Both of those are extremely low risk, and very likely
lower than the risks you'd have running TFS on-premises, in your own
data centre, unless of course, your infrastructure and staff are
better than Microsoft's :-)
I agree with Richard. Visual Studio Online is not going anywhere :) You can also use tools like OpsHub, TaskTop, and Kovair to setup a two-way synchronization or use the TFS Integration Platform to do the same thing if you really wanted an option. If you are using Git repositories, you can clone the repository into other locations to maintain multiple copies. All of those options take effort.
I posted the same answer to this stackoverflow question.
We developed our own VSO backup tool. We scheduled it as a scheduled task and it runs once a night. It then
just clones all our repositories to disk.
Taken from this blog:
We use the VSO Rest API to query our VSO account and get all the data
we need. Since in VSO you can only have one Team Project Collection,
we retrieve all the team projects of the default collection. Each of
these team projects can have multiple repositories that need to be
backed up. A folder is created for each team project and saved to a
location on disk that can be configured in the app.config. When the
team project folder is created, the task loops over each repository in
the team project and creates folders for each repository.
You can also fork it on GitHub here
Visual Studio and TFS have both tools to collect and report on code coverage for a project or solution. What we're interested in knowing, though, is how much of the changed code has been covered by tests. We'd like to be able to identify a baseline changeset in TFS and then get a report on what code was changed in the current build, what portion of it was covered by testing, and most importantly, what portion wasn't. As far as I can see, the code coverage reports and analysis in Visual Studio
don't take into consideration what code has changed--they only tell you about code coverage for the entire project or solution.
Unfortunately, there's no out of the box functionality from TFS or Visual Studio for getting what you want.
The Code Churn and Code Coverage perspectives from the TFS data warehouse won't help much as the code churn perspective only tracks lines of code that changed, not which methods were changed.
Looking at an alternate option, you might be able to get what you're after using SonarQube's differential views but they are date based, not changeset/commit based. Plus the SCM plugin needed hasn't been tested against TF Version Control so I don't know if it will work (I haven't tried it myself). If you're using git with TFS then it should work fine, you'll just have to go through the hassle of setting it all up.
If you are looking at alternatives, NDepend can provide this feature and it has pretty good integration with Visual Studio.
NDepend lets you compare two versions of a codebase. You are able to choose what the baseline is, for example a specific build from last release or just the previous build. You can then query against the diff.
Whats the right method of version controlling my product?
I am using TFS and visual studio 2010.
Currently I am working alone on my project, so its not a team management workflow.
I don't think that I should use an agile workflow because of the reason above.
But I do want to handle builds and know what has changed between each build.
Thanks.
I dont think that a one man project is a reason to not go the agile way, but it's up to you and your decision.
(I define all my projects which I am developing alone with the Scrum Template.)
If you want to know what changed between each build you need to checkin against your work items.
So select a project template which fits for you, define your work in the workitems (task, backlog or user story, wording depends on the project template).
To not checkin without assigning against a workitem you can activate a checkin policy, so TFS will throw a dialog as a reminder.
I've searched MSDN and this site (as well as a pile of web searches) and not found anything obvious ... I do see a similar question here about using an existing source control folder -- and the note that TFS apparently stores some project settings there (and thus needs one whether you use it or not).
We're using a non-TFS source control tool -- and I don't want newcomers "accidentally" storing source versions in TFS. So, I'd like to disable the creation of a TFS 2010 source control "tree" when I create a new Team Project in VS 2010.
There may be other solutions to this problem, though, and I'm open to suggestion. For example, if TFS really does need to store some internal data -- how about a way to simply prevent any source code checkins (that is, let TFS use the source control project as needed, but prevent users from adding files)?
TFS has extensive permissions settings.
You should be able restrict check in / access to source tree by permission.