Все хорошие разработчики используют системы контроля версий. Но отнюдь не все используют их правильно. Это как в ситуации со столовыми приборами: да, можно есть руками; да, можно любую пищу съесть при помощи ложки; да, можно поделить кусок стейка на части при помощи исключительно вилки, но при этом вы измажетесь и потратите кучу времени, а окружающим людям будет крайне неприятно находиться рядом. В использовании систем контроля версий то же самое: можно делать commit неработающего кода, можно не до конца исправленные ошибки заливать в trunk, можно не писать комментарии к ревизиям - одним словом, можно вести себя как последняя свинья, вызывая всеобщее раздражение.
Решений здесь два: радикальное и правильное. Радикальное - покарать нерадивого разработчика физически (сделайте ему массаж почек и печени), морально (устроить публичную психологическую порку), финансово (лишите премии). Но вы же понимаете, что все это плохо и поселит в глубине “чуткой” души разработчика обиду на вас. Может он был уставшим и просто недоглядел - бывает такое? Конечно бывает! Поэтому, решение правильное - автоматизируйте проверку кода (и всего, что к нему прилагается: комментарии, unit-тесты), поступающего в репозиторий! Благо, все хорошие системы контроля версий это позволяют делать. Сегодня речь пойдет о Subversion. Не смотря на то, что я сам предпочитаю Mercurial (в нем, кстати говоря, так же существуют hook’и), очень часто приходится сталкиваться с svn-репозиториями.
Вкратце, hook’и - это специальные скрипты, которые выполняются во время фаз поступления кода в репозиторий. Наиболее часто используемые: start-commit, pre-commit, post-commit. Чуть реже применяются pre-revprop-change, post-revprop-change. Крайне редко используются post-lock, post-unlock, pre-lock, pre-unlock (они отвечают за блокировки). Когда commit поступает на одну из стадий обработки репозиторием, вызывается сценарий (скрипт), соответствующий этой стадии. В качестве входных параметров ему передается информация, достаточная для дальнейшего вычленения данных из поступившей ревизии. Сценарий может либо пропустить commit дальше, либо отвергнуть его. Более подробно о hook'ах вы можете почитать в статье на хабре.
Что мне не нравится в большинстве существующих решений для работы с hook’ами, которые можно найти в сети - это их громоздкость. Они абсолютно лишены элегантности. Задачу решают в лоб кустарными способами. Но на наше счастье, есть SVN-Hooks framework! И не нужно пугаться, что он написан на Perl! Реализован он очень хорошо с архитектурной точки зрения (да и с точки зрения качества кода). Пользователи Ubuntu могут порадоваться: фреймворк доступен в виде бинарного пакета из стандартного репозитория! Для лучшего понимания принципа работы взглянем на следующую схему:
Как вы видите из схемы, вам нужно создать perl-скрипт, подключить в нем нужны модули, а затем сделать symlink на него с тех стадий, в которых вы заинтересованы. Дальше проще: идем в файл конфигурации фреймворка (по одному файлу на каждый репозиторий), который нужно разместить в папке conf репозитория, и добавляем туда условия проверки. К примеру, если мы хотим проверять, что лог-сообщение commit’а содержит текст в формате “Fixs: #bug_number”, следует добавить страчку:
CHECK_LOG(qr/^Fixs:\s#d+$/ => "Wrong format of log message!");
Ну разве не красота?! Теперь вы можете не только настроить проверку логов, но и запускать unit-тесты для поступающего в репозиторий кода, проверять его покрытие, оценивать качество комментариев... список бесконечен, и ограничивается лишь вашей фантазией!
Комментариев нет:
Отправить комментарий