One popular aspect of the tool NDepend is the integration of the tool into the Continuous Integration build process. Every morning the team leader gets an up-to-date report telling if some coding rules written with CQL have been violated within the last 24h.
With NDepend v3 integrated in Visual Studio 2010, 2008 and 2005, we wanted to provide a smoother answer to the critical scenario of when a developer violates a rule. We think that waiting till the day after to discover that a rules get violated is too long, it is not enough agile-oriented. We wanted CQL rules violation being obviously warned as soon as possible, right within Visual Studio.
The idea of what we’ve done with NDepend v3 is that all CQL rules get checked into Visual Studio as soon as one or several VS projects have been (re)compiled.
The developer gets permanently informed of CQL rules validation status thanks to a progress circle we added in the bottom-right corner of the Visual Studio window.
- green, means that all CQL rules are validated,
- yellow, means some activated CQL rules are violated,
- red, means some activated CQL rules don’t compile and (eventually) some activated CQL rules are violated,
- blue + progressing, means that the code is currently analyzed by NDepend,
- grey, means that no NDepend project is currently loaded in VisualStudio.
The CQL Explorer lists all rules grouped by categories…
Of course double clicking a culprit method or class lets jump to its source code declaration. And if the application analyzed by NDepend spawns several VS solutions, and these solutions are currently opened in several VS instances, the code element gets edited within the adequate VS instance, the one that contains the VS solution that contains the code element. This behavior at first glance might surprise and even look like a bug. But with the habits it becomes a powerful time-saver trick. And this multi-VS-instances communication trick is made possible thanks to the Application-Wide code analysis of NDepend.
CQL rules validation phase is fast. The performance challenge was to make this happens almost instantly to
avoid slowing the developer machine. Hopefully for a large 100K Lines of
Code application, code gets re-analyzed and 200 CQL rules can get checked, all within 3 seconds after
the (re)compilation of one or several .NET assemblies. These fast
performances were made possible thanks to the development of a new
technology of incremental code analysis. With incremental code analysis,
only modified code gets re-analyzed. I can attest that this was extremely challenging and complex development!
Finally, in the form shown on progress circle hovering with mouse, there are 2 links Analysis Execution and Analysis Refresh in VS.
- The option panel Analysis Refresh in VS let’s customize when an NDepend analysis should occurs.
- The option panel Analysis Execution let’s finally customize the analysis
process (incremental/full analysis, in/out process, report
Something that we are thinking of implementing for the future would be an option to forbid check-in if not all CQL rules are green. The development complexity comes from the multitude of Source File Management technologies (including TFS) to support. Any comment on this potential feature is welcomed dear reader.