Непрерывное измерение качества кода с помощью NDepend и TeamCity

Мне нравится хороший набор автоматически генерируемых метрик кода. Есть кое-что о том, чтобы просто навести инструмент на базу кода и сказать «Вон там — иди и делай свое дело», что действительно привлекает ту часть меня, которая хочет измерить и измерить.

Я думаю, что частью этого является объективность автоматического анализа кода. Ручные обзоры кода — это замечательно, но, кроме проблемы ручного труда, всегда есть степень субъективности, которую приносит с собой человек. Конечно, проверки кода по-прежнему важны, но сгенерированные результаты и метрики всегда являются хорошим дополнением, и, поскольку они могут выполняться автоматически, вы можете делать их так часто, как захотите.

Одна вещь, которую я обнаружил в обзорах кода в прошлом — вручную или автоматически — это то, что если вы делаете их в конце проекта, будет слишком поздно ! Ты всегда оказываешься между молотом и наковальней, где, с одной стороны, ты чувствуешь, что у тебя куча мусора, а с другой стороны, у тебя есть крайние сроки и беспокойные клиенты.

То, что вы действительно хотите сделать, — это внести свои метрики качества кода в процесс разработки, чтобы они были доступны каждому каждый день . Вы запускаете их в первый день, когда есть пустой проект, и не останавливаетесь, пока все не будет доставлено. Это где сервер сборки вступает в игру.

Я писал о NDepend еще в апреле, где я был в восторге от его способности генерировать довольно мощные метрики на базе кода. Это фантастический инструмент для получения очень подробных показателей статического анализа в вашем коде. Даже если не все знакомы с такими показателями, как эфферентное связывание и цикломатическая сложность, по крайней мере, люди должны понимать смысл таких вещей, как сложные методы и типы со слишком большим количеством обязанностей.

О TeamCity

Я только что закончил серию из 5 статей о том, что «вы неправильно внедряете», которая была посвящена использованию TeamCity для непрерывных сборок и развертываний в Microsoft Web Deploy. Я расскажу о причинах, по которым я заинтересован в TeamCity в этой серии блогов, но вкратце, это в значительной степени лидер для непрерывных сборок .NET без перехода по пути Team Foundation Server. Это также очень легко интегрировать с инструментами качества кода, такими как NDepend.

Настройка сборки

Я начну с предположения, что в решении уже есть проект NDepend и проект TeamCity, настроенный на сервере CI. Посмотрите предыдущие посты, упомянутые выше, если вы еще не достигли этого момента.

В части 4: Непрерывные сборки с TeamCity я создал сборку, запускаемую каждым коммитом VCS, чтобы обеспечить успешное построение всего решения. Я хотел бы использовать выходные данные этой сборки, а именно скомпилированные библиотеки DLL, чтобы NDepend мог анализировать их, а не перестраивать решение снова.

Вот как выглядят общие настройки с добавлением нескольких путей к артефактам:

Очевидно, что это решение имеет как веб-проект, так и решение бизнес-логики, следовательно, две сборки в путях артефактов. Это означает, что предыдущие сборки будут производить некоторые артефакты, которые выглядят так:

Теперь давайте пойдем и создадим группу новой сборки. Вот как я настроил мой:

The artifact path is important as this needs to pick up the output of the NDepend analysis. I’ll skip any screen grabs of the VCS settings because they’re identical to what I’ve described in previous posts (don’t forget the checkout rule if you have a trunk). Even though we’re going to run against the artifacts from the previous build, we still need the NDepend project file and I’d also like to include the VCS revision number in the build number formatting.

The important bit is the build runner. What we’re going to do is use a command line runner to execute the NDepend console. You can always create a custom build file and run that as an MSBuild task (in fact this is the guidance given on the NDepend website), I just find this simpler and sufficient for my purposes here, particularly given we’ve already got an existing build to run against.

This is what my configuration looks like:

The executable path is where I’ve manually copied the files in lieu of there being no installer for NDepend. The command parameters look like this:

"%system.teamcity.build.checkoutDir%\AutoDeployProject.ndproj"
/OutDir "%system.teamcity.build.checkoutDir%\NDependOut"
/InDirs
  "%system.teamcity.build.checkoutDir%\Assemblies"

  "C:\Windows\Microsoft.NET\Framework\v4.0.30319"
  "C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF"

Note that there are a lot of references to the “%system.teamcity.build.checkoutDir%” variable. The NDepend console runner expects all the paths to be passed in as absolute so we need to get TeamCity to tell us what these are. Note also the first input directory ends in “Assemblies”. This is where we’ll put the artifacts from the first build. More on that shortly.

Next up we’ll move on to the dependencies section and add a snapshot dependency on the first build. This will ensure this build only ever runs against sources the other build has already run against:

To use the artifacts from the previous build, we’ll just add an artifact dependency that requests all the .dll files and drops them into an “Assemblies” path which this build can now refer to:

The last thing to do is to ensure the NDepend report is easily accessible via a report tab. Let’s head on over to Administration –> Server Configuration –> Reports tabs and create a new entry like so:

All that’s left to do is to run it. We’ll do this on demand for the moment but nightly is neat for once the project kicks off.

Browsing back over to the homepage of the new NDepend build, the latest build should now display an NDepend tab which will bring the report right into the build page:

Summary

Reports like NDepend are great for generating via a build server on a nightly basis so they’re sitting there first thing each morning. I don’t necessarily believe that every recommendation should be strictly adhered to, but I do believe they should be read on a regular basis and consciously not adhered to if necessary.

The only other thing that would be really nice to see is an indication of how many new findings there were since the last run. The TeamCity duplicates finder and FxCop builds do this and I find it extremely useful. Obviously NDepend would need a little more consciousness of the previous builds to do this but it seems like the sort of thing there should be an extensible model for from Jet Brains.

I’m going to write a little more about automated quality metrics from TeamCity shortly. Stay tuned for more quantitative goodness!