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

Добрейшего.

Периодически читаю посты из командного блога 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 ;)

SCM SWEBOK от IEEE - перевод и оригинал от Сергея Орлика

Добрейшего.

Есть такая инициатива, называется она Software Engineering Body of Knowledge. На русский это переводится примерно как Свод Знаний по Программной Инженерии. Создается он под эгидой IEEE (Institute of Electrical and Electronics Engineers, читается "ай-трипл-и"). Целью сбора подобного Свода является приведение к общему знаменателю знаний в программной индустрии. Результатом является SWEBOK Guide, содержащий общепринятые стандартные термины, понятия и методы, прменимые к любым процессам разработки. Подробнее о том, что это и зачем всё это, можно почитать в FAQ.

Меня же интересовала глава 6, а именно "Конфигурационное управление". Читал её ещё давно на английском (оригинал лежит на сайте SWEBOK), много думал, как водится... А тут наткнулся на её перевод от Сергея Орлика. "Это повод!" - подумал я, и решил выложить сюда с парой комментариев.

Plastic SCM - распределение с человеческим лицом

Добрейшего.

Набрел намедни на систему контроля версий Plastic SCM от CodiceSoftware. Причем набрел случайно, рассматривая ещё пару относительно редких систем.
В целом система очень понравилась. Получается нечто среднее между Perforce, Mercurial и, как ни странно, ClearCase. Причем сильнее всего смахивает именно на Perforce. Ниже - обо всех основных возможностях и о личных впечатлениях.