Пример выбора иструментов, или Как жить дальше?

Добрейшего.

На своем опыте убеждаюсь, что вопрос выбора инструментария может встать даже в устоявшихся проектах и коллективах. А всё потому, что на основном месте работы сложилась занятная ситуация с организацией и инструментами разработки.
Есть следующие команды разработчиков. Большая команда разработчиков - назовем её Команда Ф (так оригинальнее). Есть маленькая команда разработчиков (Команда Д). И есть я, пусть это будет Командой А (ничего общего с тупым сериалом 80-х).
Есть и другие команды - техподдержка, дизайнеры, верстальщики, менеджеры, редакторы - но они нас не интересуют в разрезе заметки.


Команда Ф использует множество инструментов и является наиболее продвинутой в тройке. Имеет централизованный контроль версий в SVN. Некоторые используют git. Для багтрекинга используется автралийская Altassian JIRA. Кроме того, есть развернутый инструментарий для юнит-тестирования и функционального тестирования. Конечно же, есть и автоматика для развертывания production-копий систем на рабочие площадки. Есть своя Wiki.

Команда Д - невелика по численности. Использует общий SVN для контроля версий. Для багтрекинга используется Eventum (ссылку не дам, ибо отстой). Также есть скрипты для деплоймента из SVN на production-сервера. Осознавая необходимость документирования, была запущена MediaWiki и в меру сил заполнена.

Команда А (то есть я) использует в работе SVN на локальной машине разработчика, автоматизации нет, отслеживание задач было сделано в Basecamp. Не спрашивайте, как я дошел до жизни такой... так уж получилось :)

Задача

Исторически так сложилось, что команды мало пересекались в работе. Команда А, та вообще находилась долгое время в другом офисе. Проекты разные, задачи абсолютно разные, так что повода делать что-то совместное особого не было.

Но вот (здесь фанфары!) состав Команды А изменился, а потом и территориально она стала находиться рядом с остальными командами (а с Командой Д - так вообще за соседними столами). Состав задач стал изменяться, стала появляться необходимость использовать что-то более сложное, чем просто продвинутый to-do list, коим является Basecamp. Появилась зависимость задач между собой. Возникла необходимость подробного документирования. Началась постепенная реорганизация кода приложений из-за его чрезмерного усложнения.

Как быть? Конечно, менять процесс и выбирать подходящие для него инструменты. Поскольку я являюсь старым активистом антиброуновского движения, вариант изобретать велосипеды отпал сам собой. Тратить время на создание того, что уже давно создано - это верх расточительности. Кроме того, я ещё и сторонник централизации, поэтому если какие-то инструменты выбирать, то делать это надо с учетом того, что уже используется другими двумя командами.

Что делать? Варианта два 1) взять используемые другими командами инструменты; 2) выбрать инструменты самому и перевести на них другие 2 команды.

Решение

Задача разбивается на подзадачи: контроль версий, отслеживание задач (АКА багтрекинг), документация, тестирование, развертывание.

Самой обособленной и простой задачей является ведение и отслеживание документации. В нашем случае её 2 вида - проектная документация и генерируемая на основе комментариев. С комментариями всё просто - их просто пишет по ходу написания кода, тут вопроса нет. Ну, разве что, надо озадачиться и настроить автоматическую генерацию тем же doxygen.
С проектной документацией тоже вопрос отпал сам собой - я просто создал свои разделы в вики Команды Д и активно их пополняю. Причем, как обычно, нет времени писать от начала и до конца, поэтому новые страницы создаю по ходу работы над разными частями проекта. Закончил большую фичу - описал. Затронул обособленную часть системы - написал про неё. Отправил инструкцию кому-то из пользователей - вставил её в Вику, чтоб не потерялась. Вот так и заполнил уже потихоньку половину от того, что планировал.

Контроль версий. Вариант только один - присоединиться к SVN одной из команд. Я не фанат Сабвершна, но ради централизации приходится бить себя по рукам, чтобы не перейти на что-то другое. В конце концов, типичные сценарии работ не очень сложны и SVN с ними отлично справляется. Лучшее - враг хорошего, так что остановился на хорошем решении. Вопрос только - к кому подключаться. Команда Д больше подходит, т.к. их проект более связан с моим и есть даже небольшие пересечения по общим данным. Так что в ближайшее время надо подключиться к их репозиторию.
Кроме того, раз возник повод, надо озадачиться структурой репозитория. Текущая структура изначально была простой - trunk и бранчи, по одной на новую фичу. В дальнейшем появился ряд больших проектов (у каждого - свой домен), поэтому просто ветки перестали устраивать, надо подойти к вопросу более централизованно. Например, на верхнем уровне репозитория обозначить директориями отдельные проекты, в нём - транк и его ветки.
От практики меток в том виде, в каком они используются в SVN, сознательно откажусь. Во-первых, у проектов-сайтов отсутствует четкое различие между релизами: доработали - обточили в "песочнице" - запустили для всех посетителей - доработали в реальном времени по мелочи - отслеживаем посещаемость и обратную связь. Текущая версия на trunk - это и есть baseline в его традиционном понимании, это то, что в данный момент видят посетители, метить тут особо нечего.
Во-вторых, меток в SVN попросту нет, а значит, пользоваться нечем. :) То, что там есть - это их имитация.
В общем, директории под разные проекты и в них - транк и ветки.

Отслеживание задач - это как раз вопрос, из-за которого всё и началось. От системы issue-tracking мне нужно не так уж много.
Во-первых, гибкая настройка жизненного цикла работы над записью. Ведь удобно для бага назначать свою цепочку состояний и перехода ответственности, для новой фичи - свою. А для обособленных задач типа прогона тестов - другую цепочку, включающую и свой набор полей. Не такая это сложная вещь, однако у большинства систем багтрекинга её нет, увы.
Вторая особенность, которая бывает нужна даже при одиночной разработке - связи между задачами. Нередки ситуации, когда новая фича не может быть запущена, если не будут пофиксаны несколько багов, назначенных на разных людей. При этом код активно дорабатывается и над ним работает другой человек. Другой вариант - исправленную ошибку надо протестировать перед выгрузкой, и задачу по тестированию заводят отдельной записью. Понятно, что код нельзя выгружать без тестов и надо обозначить, что задача по исправлению не может быть закрыта без тестов. В общем, надо обозначить зависимости и видеть текущие "showstoppers".
Третья особенность, которую хочется от любой системы - это простота и красота (которая зачастую кроется как раз в простоте). Что тут скажешь - простая в использовании и красивая система лучше тяжеловесной и страшной. GUI должен быть web-based.
Остальные фичи у большинства систем мало отличаются, на них останавливаться не буду.

Вообще, если бы мне с нуля понадобилось выбирать систему bugtracking с зачатками project management, я бы лично вместо Джиры поставил или Redmine, или eTraxis. Был у меня опыт выбора и пилотной эксплуатации системы трекинга с зачатками системы планирования на предыдущем месте работы - по итогу выбрал Рэдмайн, остался сильно доволен и в дальнейшем его продолжила использовать вся команда. Если же мне нужно было бы простое отслеживание ошибок или управление задачами - то тут однозначно выбор бы пал на eTraxis - его я не просто активно использовал на крупном проекте, но даже успел потоптаться в исходниках :)

Однако в наличии имеются Eventum и JIRA. Будем смотреть, что есть хорошего в них.
Eventum - отстреливается сразу. Пункт первых моих пожеланий тут не выполняется - нельзя там гибко настраивать жизненный цикл. Пункт два, про связи, также неосуществим. Касательно простоты и красоты - всё ужасно. К тому же сопровождением системы уже несколько лет её хозяева не занимаются (к слову, это та же компания, которая создала широко известную в узких кругах СУБД MySQL ;) ). Глубоко копать не стал - раз не подходит по функциональности, значит в топку.
Вот JIRA понравилась значительно больше. Гибкость настройки - прекрасная. Можно назначить разные жизненные циклы в любой конфигурации с указанием разных полей для разных состояний. Кроме того, каждый жизненный цикл имеет своё краткое название (Bug, Feature, Task) и для создания новой записи пользователю можно из панели инструментов одним кликом сразу попасть на форму подачи баги или другого запроса на изменения. Связь между задачами - в наличии, хотя и не без недочетов. К примеру, для создания child-записи предлагается только создать запись с каким-то усеченным жизненным циклом и для неё, в свою очередь, уже нельзя будет создать свою дочернюю запись. Т.е. у первичной записи будет дочка, но вот внуков она уже не увидит - и это плохо, как ни крути. Кроме того, начальную запись можно закрыть, не дожидаясь закрытия дочерних, что странно, ведь если на задаче висит внешняя зависимость, помимо самого выполнения, то это повод не выпускать её из вида (закрытые записи - это первое, что убирают пользователи, применяя фильтры). Помимо дочерних записей, можно задать связи между записями вида "зависит от - задает зависимость для", "следующий-предыдущий" и ещё несколько. Занятно, почему туда же не включили тип связи "родительский-дочерний" вместо создания ущербных подзаписей - было бы очень логично и единоообразно. В общем, пункт 2 моих хотелок выполняется, но с оговорками. Ну и третья составляющая, красота и простота, выполняется практически без оговорок. Интерфейс приятный, всё понятно без инструкций (а может это просто я уже насмотрелся на разное, вот и привык быстро вникать). Единственное замечание - просмотр текущих задач и установка фильтрации. Для просмотра задач, с которыми работаешь постоянно, требуется делать лишние движения, выбирать фильтр и т.п. А вот в том же eTraxis всё проще - логинишься и видишь текущий срез всех задач, которые касаются тебя (по предварительно установленным фильтрам, понятно). Но это не та проблема, из-за которой отказываются от продукта. Есть ещё один минус - система платная, в отличие от большинства аналогов, которые в большинстве своём open source. Странно, что это не остановило того, кто пилотировал систему для команды перед её окончательным принятием в работу :)
Итог - подключился для пробного использования к JIRA Команды Ф.

Развертывание. Здесь явных преференций нет, надо пробовать на практике подходы обеих команд. Для начала попробую самый простой - развертывание из SVN с помощью rsync. Use case простейший: всё, что надо залить на сервер, коммитится в SVN, а затем синхронизируется с онлайном с помощью rsync. На первых порах надо отучить себя работать с помощью привычного FTP (помогут скиллы Сила воли и Битиё себя по рукам). Потом всё пойдет проще.

Тестирование. Поскольку из трёх команд только команда Ф использует автоматизированное  тестирование в каком-либо виде, то перенимать инструментарий надо будет у них. Поскольку разработка во всех командах ведется преимущественно на PHP, то инструменты будут те же. Останется "самая малость" - тесты написать на существующие мегабайты кода :)

Выводы

Что же теперь надо сделать в ближайшее время, после предварительного анализа.
1. Перенести репозиторий проектов в SVN Команды Д с одновременной переработкой структуры.
2. Познакомиться с инструментарием развертывания от Команд Д и Ф и выбрать подходящий для проектов Команды А.
3. Продолжить использовать Вики Команды Д.
4. Ознакомиться с практиками тестирования Команды Ф. Выбрать то, что можно уже сейчас начать применять.
5. Продолжить использования JIRA от Команды Ф. Далее - два варианта.
5.1. Перейти на неё совсем. Убедить Команду Д перейти на неё же, потому что Eventum - это зло.
5.2. Пропилотировать внедрение eTraxis с привлечением Команды Д - с последующим уходом от Eventum. Да, снова получится 2 инструмента на 3 команды, но это меньшее зло и это на тот случай, если Джира себя не покажет наилучшим решением.

В общем, "Как будут развиваться события - покажет время" (с) Программа "Время"


P.S. Решили внедрить Redmine.