Query delta's

Nov 8, 2011 at 9:01 AM

I just stumbled upon your project and I really like it. There's a few features I'd be very interested in from a QA perspective. 

We often are requested to ensure Code Coverage of new and changed code does not change or rises. We currently use NDepend to query two version of the same build, one that was released and the current build and report over those metrics. It would be great if we could somehow configure this to fetch the data from a previous build with a certain build quality associated to it.

And the second request would be to be able to publish the Complexity/Cohesion/Coupling metrics into the TFS warehouse so that we can report on those.

Coordinator
Nov 8, 2011 at 2:20 PM

Hi and thanks for your interest in this project !

Your suggestion is *very* interesting, using build qualities solves the problem ! I overlooked the possibility of comparing two builds because I thought it was too complicated to select the appropriate base build. Having to edit the build parameters, or even pass a new value at build trigger time is awkward in my opinion. Using build qualities is elegant and efficient.

Ideally, I should add on options like :

* Comparative build (bool)

* Name of the build quality to compare the build with (string) : the build will pick the latest of this quality...

 

For your second request, I have started modifications to publish more data from NDepend, including those you mention, they are not available at solution level, only at assembly level and below.

However, I do not plan to publish any data below assembly level (namespaces, types...). For such an inspection at the moment NDepend has to be used. I don't know yet where exactly to put the limit in this regard. I need field feedback.

The current philosophy is to make possible to historize global data, but going deeper in the details would make historization unstable (think of namespaces renames, types renames). Maybe some day I'll integrate data from namespaces and types, don't know if it would grow the databases too much...

 

 

Nov 8, 2011 at 2:33 PM

You're welcome on the idea :) I prefer that myself. Another option would be to be able to point to a specific drop folder.

As for the complexity and other statistics: We're mostly integrated in the distribution of items. So the number of methods with complexity x, y and z per assembly. The exact method isn't as interesting. We'd like to be able to report on the overall quality and if one category is growing too fast, a developer can zoom in to try and solve them by running NDepend locally.

Coordinator
Nov 8, 2011 at 2:47 PM

pointing on a specific drop folder : I don't especially like this since it would to change the build definition variables every time. Build quality is more flexible. If you want you may override the build quality name when triggering a build as well...

 

Thanks for the feedback regarding complexity.

I really need to store the numeric result for each CQL Query (number of found nodes), which is not the case yet. It should not be difficult to store those based on their full name :

Eg :

Code Quality \ Type Metrics \ Types with too many methods = 3

Code Quality \ Methods with too many parameters(NbParameters) - critical = 3

etc.

Nov 8, 2011 at 5:06 PM

I have been wishing for such complexity statistics from VS itself. The metrics are now available from the command-line and it isn't too hard to integrate that into a build, but it actually doesn't publish its data into the warehouse.

Coordinator
Nov 8, 2011 at 8:22 PM

I plan to extend the codemetrics activity afterwards to do exactly the same as for NDepend.

I'd also like to integrate Sonar for C# into TFS, it's so impressive...

These solutions overlap, but it's good to have choice...

Nov 27, 2011 at 7:06 PM
Edited Nov 27, 2011 at 7:10 PM

I discussed this BuildActivity during the ALM Summit in Redmond and the conclusion was that being able to use the 'last build with quality' would be a great way, but most MVP's present opted for the option to specify a specific build output, or even a specific folder as the reference project. The conclusion was that it would be best if the build administrator were able to select  which option to use. Just offer them all, let the admin pick one.

- Most wanted to be able to use the "last build with quality"
- All wanted the option to specify a reference folder/fileshare
- Some wanted to be able to specify a specific build + build number

Aug 7, 2012 at 5:21 PM
Edited Aug 7, 2012 at 5:22 PM

Jesse or Vincent,

I just purchased the Ndepend package but running into this error When I try to use the NdependBuildTemplate.xaml.  Here is the error I got:

 

"Activity could not be loaded becuase of errors in the XAML."

Any suggestions?  Thanks for your contribution in this project.