Личный опыт внедрения Redmine

Добрейшего.

Не так давно задумал совершить ряд движений и поменять СМ-процесс в своём проекте и, если получится, на проекте соседнем. Поводом было то, что меня перестал устраивать текущий инструмент отслеживания запросов на изменения. Начав думать над одним, огляделся и понял, что пора бы и всё остальное поменять, до чего давно не доходили руки.

В общем, перво-наперво задача стояла поменять систему отслеживания запросов на изменения, или попросту багтрекер. К моменту написания заметки на пробу использовал Jira, подумывал оценить её и предложить соседней команде в качестве альтернативы использовавшегося ими Eventum. Когда стали обсуждать переход в участниками команды, решили посмотреть на прайс Джиры... посмотрели и решили, что Redmine, обладающий тем же функционалом, но за бесплатно, вполне подойдет :) У меня был опыт его настройки и внедрения в процесс, так что переход обещал быть быстрым.

Кто такой релиз-инженер

Добрейшего.

В продолжение вопроса о том, кто такой СМ-инженер.

Анатоликс не так давно вывесил вакансию релиз-инженера для поиска Яндекса . Собственно, по ссылке - пример того, кто такой настоящий release engineer. Практически тем же самым (ну, с поправкой на количество серверов), мы занимались во времена работы с интеграционной команде Моторолы.


Стало быть, Яндекс решил выделить релиз-инженера в отдельную роль. Офигеть, что же у них раньше творилось и какой был геморой у тех людей, которым надо было совмещать основные обязанности техлидов и того, кто выпускал релизы. При интенсивной разработке большой командой это немалый труд. Ну, если найдут нужного человека - жизнь их станет значительно легче и приятнее :)

Кстати, вот обсуждение на RSDN. Для сравнения - обсуждение на sql.ru, прям небо и земля...

Развернуто об одной ветке на каждую задачу

Добрейшего.

Периодически читаю посты из командного блога Plastic SCM - продукта, обзор которого я не так давно делал. Продукт очень интересный, поэтому стараюсь быть в курсе того, что у них происходит.
И вот публикуется очередная статья, называется Branch per task workflow explained. Как следует из названия, описывает, почему же надо придерживаться политики ветвления "одна задача - одна ветка". Предполагаемый уровень читателя - новички в области контроля версий, применяющие простые практики.
Так понравилась, что решил перевести. Думаю, многим покажется интересной, несмотря на то, что объясняются, в общем-то, простые вещи.

Итак, текст.

О надежности систем контроля версий

Добрейшего.

И опять страничка юмора в бложике!

Взято из постоянно читаемого комикса Not Invented Here, очень рекомендую.

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

Добрейшего.

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

Git, Mercurial, Bazaar — работа с SVN и управление патчами

Добрейшего.

Через Хабр набрел на статью Сравнение DVCS - несколько задач. Рассматриваются популярные распределенные open source системы - Git, Hg, Bzr - с точки зрения работы через них с репозиториями SVN. Да, вот такая необычная постановка задачи.

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

Листал подшивки CM Journal

Добрейшего.

Не так давно решил пролистать все прошлые выпуски CM Journal, выпускаемые редколлегией сайта CM Crossroads. Узнать, так сказать, чем дышат корифеи и апологеты современного SCM. Итог - 3 интересные статьи.

В целом я ожидал много интересного. Но, увы, в сборнике за 2 (два) с лишним года ежемесячных выпусков мне лично показались интересными только 3 (три) статьи. Остальные говорили или о вещах очевидных, или нужных, но только тезисно, или о злободневных, но декларативно, без конкретики. Очень много "воды" и рассуждений о космических кораблях на просторах Большого театра. Модное нынче направление agile-разработки точно также очень часто упоминается, но, опять-таки, конкретики очень мало. Периодически встречаются опечатки, сбившиеся буллиты в перечислениях, хромающее оформление - в общем, "написано профессиональными программистами".

Из понравившегося.

Пианист в борделе

Добрейшего.

В пору моей работы SCM-инженером в Мотороле меня периодически спрашивали, кем я работаю. Немедленно вспоминался следующий анекдот.

В школе детей спрашивают - кем работают ваши папы?
Кто-то говорит - бизнесменом, кто-то - военным, кого-то - строителем.
Вовочка: "А у меня папа - пианист в борделе!"
Учительница негодует и требует отца в школу. Тот приходит и выслушивает гневные тирады - "Как вам не стыдно такое ребенку рассказывать!".
На что отвечает: "Понимаете, вообще я разработчик, пишу распределенные вычислительные системы под кластеры, но разве это объяснишь 10-летнему пацану?"

Собственно, SCM-инженер в большой команде - из того же разряда. Слишком долго от начала до конца объяснять, чем же он занимается :)

Google Wave // как не надо делать багтрекинг

Добрейшего.

Через старый уважаемый сайт набрел на статью на молодом гиковом сайте. В общем, на Хабре выложили пост про использование Google Wave в качестве багтрекера, а на RSDN выложили на него ссылку с комментариями.

Вкратце - есть команда 30 человек. Они использовали 5 лет Trac и заодно перепробовали кучу других тулов для управления задачами. Им нужен был инструмент, который позволил бы не только отслеживать задачу, но и как-то оперативно поддерживать весь поток сопутствующей информации - в первую очередь обсуждений в IM системы Jabber. В конце концов остановились на Google Wave - поскольку именно там они могут  теперь вволю трепаться о проекте и при этом там же вести информацию о задачах. Плюс ещё пару фишек разработали для Волны. Все жутко довольны, чего и всем советуют. Щастье всем даром и пусть никто не уйдет обиженным.

Что тут скажешь: разруха - она в головах, а не в клозетах. Если в команде бардак и никто не хочет взять на себя труд остановить его и взять всё под какое-то подобие контроля - жди беды. Люди будут упорно вариться в этом броуновском движении и не будут упорядочивать свою работу, даже когда проект разрастется до сотни человек и понадобятся совсем другие механизмы работы.

На RSDN автор высказался примерно в таком же ключе. Ну, и я его поддержал. Основные мысли:
- для оправдания бардака люди будут пробовать всё новые тулзы, которые будут как-то помогать поддерживать любимый уровень энтропии;
- делать из обсуждений задач полноценные артефакты процесса (т.е. присваивать обсуждению тикета статус отдельной самодостаточной единицы) - неправильно. Надо резюмировать результаты любых обсуждений и уже их аттачить в качестве комментариев к записям в системе трекинга;
- подобная система не способна нормально структурировать работу, а также получать статистику и числовые показатели.
Ну и не могу не процитировать камрада с RSDN:

Управление проектом — это чёткое понимание в каждый момент времени, где ты находишься. Из того что я вычитал, там даже близко нет "управления". Есть группа людей, которая "just for fun" занимается какой-то деятельностью. Всё это будет продолжаться, пока у кого-то хватит терпения оплачивать этот фан. Потом их разгонят, на форумах будут сообщения — "была классная контора, но потом прогнила".

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

Мой вывод: Google Wave (по крайней мере, предложенная реализация) не способен предоставить нужный уровень зрелости для отслеживания задач (багтрекинга) относительно большого проекта. Так что используйте что-то, что способствует применению правильных практик. Например, eTraxis ;)

UPDATE: Собственно, предмет споров самоустранился:
http://googleblog.blogspot.com/2010/08/update-on-google-wave.html

Если бы системы контроля версий были ...

Добрейшего. Страничка юмора в бложике!


Набрел через Хабр на заметку "If Version Control Systems were Airlines". Очень рекомендую, весьма забавно :)
Кому английский не помеха - лучше оригинал прочитать, остальным можно почитать народный перевод - "Если бы системы контроля версий были авиалиниями".

Немедленно вспомнился мой пост на RSDN - "Образное сравнение систем контроля версий", где разные системы контроля сравниваются с туалетами разных систем. Собсно, тоже рекомендую для посмеяться :)

Have fun ;)