Вчера я писал о непрерывном измерении качества кода с помощью NDepend и TeamCity, где я смотрел на ночные сборки, которые оценивали качество кода с использованием превосходного NDepend. Эти отчеты хороши, и их легко настроить, но вам нужно сделать как долларовые инвестиции в программное обеспечение, так и образовательные инвестиции, чтобы действительно понять метрики и их отношение к качеству кода.
Что приятно в StatSVN, так это то, что он бесплатный и не требует много времени для его использования. Вместо того, чтобы анализировать вашу кодовую базу, как NDepend, StatSVN анализирует ваш репозиторий Subversion и сообщает о том, как ваше приложение изменилось с течением времени. В некотором смысле, это своего рода жевательная резинка для мозга (множество интересных показателей без большого количества вещества), но есть некоторая ценность в понимании того, как структурирован ваш проект. И эй, это бесплатно!
Как все установить
Есть несколько маленьких кусочков, необходимых для работы StatSVN. Каждый из них должен быть установлен на сервере сборки:
Для начала вам понадобится StatSVN. Мы пойдем, возьмем последнюю версию и распакуем zip в каталог программных файлов. Там нет установщика, и все это состоит из файла readme, и, поскольку все написано на Java, вы также получаете файл .jar.
Чтобы мы могли сделать что-то полезное с файлом .jar, нам также нужно установить Java .
Наконец, нам нужно выполнить запрос командной строки к Subversion, поэтому нам потребуется доступ к svn.exe. Поскольку у меня есть VisualSVN Server на моем демонстрационном сервере TeamCity, я просто добавлю путь к «C: \ Program Files \ VisualSVN Server \ bin» в переменных среды машины, но в противном случае вы всегда можете пойти и взять последний бинарный файл. установщик SVN .
Запуск StatSVN
Чтобы выполнить StatSVN, нам нужно выполнить три отдельных задания:
- Проверьте хранилище в рабочий каталог
- Запустите «svn log», чтобы экспортировать историю репозитория в файл журнала.
- Запустите инструмент StatSVN для файла журнала, чтобы сгенерировать отчет
Мы собираемся автоматизировать все это в новой сборке против проекта, который я создал в своей серии из пяти статей «Вы неправильно внедрили» . Начнем с новой сборки:
Единственная заметная достопримечательность здесь — путь артефакта. Как и вчера с NDepend , нам нужно сообщить TeamCity, где найти результаты этой конкретной сборки. Мы скоро вернемся на этот путь.
Переходя к настройкам VCS:
Корень VCS будет таким же, как и во всех других сборках (еще раз, не забудьте правило извлечения, если у вас есть транк), но режим извлечения будет немного другим. В каждой другой сборке, которую я создал до сих пор, использовалась опция «Автоматически на сервере» по умолчанию. Причина, по которой мы собираемся использовать «Автоматически на агенте», заключается в том, что это будет эффективно выполнять проверку svn, которая хранит файлы, связанные с хранилищем, а не экспорт svn, который извлекает их и нарушает связь. Как вы увидите из шага 1, StatSVN требует этого, прежде чем идти дальше.
Прежде чем мы перейдем к настройке бегуна сборки, нам нужно решить, как мы собираемся выполнить две другие команды. Я хочу сделать это как можно проще, а также хочу централизовать его, чтобы в будущем я мог использовать его в других сборках. Таким образом, я собираюсь обернуть две команды в один файл .bat, который мы можем вызвать из сборщика командной строки.
Давайте начнем с svn log :
svn log --xml --non-interactive -v > StatSvnLog.xml
Цель этой команды — сбросить каждую транзакцию VCS в файл XML. Ради интереса, они выглядят примерно так.
<logentry revision="9">
<author>troy</author>
<date>2010-11-19T10:07:53.824726Z</date>
<paths>
<path kind="file" action="M">/trunk/Web/Default.aspx</path>
</paths>
<msg>Updated text on the homepage.</msg>
</logentry>
Часто в этих журналах будет много записей пути, но это дает вам представление. Что говорят переключатели в заявлении:
- —xml: сохранить журнал в формате XML
- —non-interactive: отключает все интерактивные приглашения (подробнее об этом позже)
- -v: подробный режим включает информацию о путях, которые были изменены в каждой ревизии
- > StatSvnLog.xml: имя файла для сохранения журнала
Далее следует команда StatSVN, которая будет выглядеть следующим образом:
"C:\Program Files\Java\jre6\bin\java.exe" -jar "C:\Program Files\statsvn- 0.7.0\statsvn.jar" StatSvnLog.xml %1 -output-dir StatSvnOutput -disable-twitter-button
Вот что он делает:
- java.exe: выполняет исполняемый файл Java и передает файл .jar для StatSVN.
- StatSvnLog.xml: ссылается на файл журнала, который мы создали ранее
- % 1: мы собираемся передать это из TeamCity — это путь к рабочему каталогу
- -output-dir: где мы хотим разместить отчет (ранее на него ссылались как на артефакт)
- -disable-twitter-button: потому что я не хочу, чтобы люди автоматически писали в Твиттере о моей внутренней базе кода!
Я собираюсь поместить обе эти команды в файл с именем «RunStatSvn.bat» и поместить его в папку, в которую я установил StatSVN, в данном случае это «C: \ Program Files \ statsvn-0.7.0». Теперь мы можем вызвать его из сборщика:
Все это говорит само за себя: каталог извлечения, передаваемый через параметры команды, является нашим рабочим каталогом, который будет передан в StatSVN, чтобы он знал, где найти кодовую базу.
Теперь мне нужно немного отвлечься. важно, чтобы служба агента TeamCity Build работала под учетной записью, у которой есть права на чтение из репозитория VCS. Я настроил это обратно в пятой части моей предыдущей серии TeamCity, и причина здесь та же; мы не хотим хранить учетные данные в виде простого текста на сервере, поэтому давайте выполним команды под именем текущего пользователя, в данном случае, службы агента TeamCity Build.
Последнее, что мы хотим сделать, — это создать приятную вкладку на странице сборки, чтобы отобразить отчет, поэтому мы вернемся к вкладкам Администрирование -> Конфигурация сервера -> Отчеты и создадим новую запись следующим образом:
Давайте начнем и посмотрим, как это выглядит:
Статистика выглядит немного скучно для этого проекта, так как это всего лишь тестовый проект развертывания, над которым я работал, но вы поняли идею. Главное, чтобы процесс был правильным, и он готов к тому, чтобы запускаться каждую ночь вместе с NDepend.
Резюме (и драмы)
Ранее я упоминал, что вернусь к тому, почему команда svn log работает в неинтерактивном режиме. Если честно, у меня была куча драм, заставляющих это работать. Проблема была связана с тем, под какой командой выполнялась команда, и с тем, было ли доверено подключение к Subversion. Я отчаянно искал ответы на вопрос , почему именно тому , что я настроил выше, всегда было отказано в доступе, и одна из вещей, которая немного упростила поиск, заключалась в том, чтобы убедиться, что бегущий по команде не просто сидел в ожидании имени пользователя и пароля, следовательно, неинтерактивный режим, который в моем случае просто говорит вам, что вы облажались немедленно.
В конечном итоге, после многих дней разочарований и множества изменений в конфигурации, вышеприведенные настройки только начали работать. Это было на выделенной машине для сборки, и когда я отправился писать этот блог и заново настраивать все это в своем тестовом VPC, то же самое случилось снова! Я не знаю, почему это было проблемой, и я не знаю, что исправило это, кроме явного упрямства от моего имени. Что я знаю, так это то, что конфигурация выглядит хорошо, и она определенно работает. На двух разных машинах!
В любом случае, конечный результат довольно опрятен, и теперь есть хорошая статистика с показателями качества кода из NDepend, а также со встроенным FxCop и средством поиска дубликатов в TeamCity. Это действительно хороший набор метрик, который дает вам прекрасное представление о том, что происходит в вашем коде. Тот факт, что он делает это без каких-либо подсказок, каждый день и сидит там, ожидая вас каждое утро, — это именно то, что вы хотите от автоматизированных показателей кода. Не может быть проще, чем это!