Записки отставного сиэмщика

Интервью с техдиром VisualSVN и немного мыслей

2011-12-01T21:14:00.001-08:00

Добрейшего.

Набрёл в блоге Якова Сироткина на интервью с Иваном Жаковым, техническим директором VisualSVN, и по совместительству - контрибьютором Subversion.

Интересный пример того, как можно сделать прибыльный проект, используя в качестве базы open source продукты. Сабвершн открыт и бесплатен, однако, как и бОльшая часть оупенсорса - требует или доработки напильником, или хитрой настройки, или гуру, который бы объяснил как надо работать. Парни сделали плагин к Visual Studio, затем свою серверную надстройку над SVN. С них и живут, причём в клиентах у них значатся не последние компании из Fortune 500, а также куча американских госучреждений. В общем, люди определённо добились чего-то на непростом рынке систем контроля версий.

Ситуация, описанная в начале - большая контора, все сидят на Visual SourceSafe, одиночки-энтузиасты пытаются изменить мир к лучшему - была типичной для российских компаний конца XX - начала XXI века. Мантра "так уж здесь повелось" до сих пор успешно работает практически повсеместно. Не сказать, чтобы это было плохо, но во многих ситуациях бывает проще перейти на новый тул, затратить усилия, чем продолжать тратить время и нервы на поддержку тула старого. Особенно если это СорсСэйф... Брр...

Так и с контролем версий. Долгое время стандартом у нас был SourceSafe, просто потому, что шёл вместе со Студией (ибо она повсеместно была хакнутой). CVS, этот стандарт де-факто мира open source того времени, приживался не очень охотно (см. "Так уж здесь повелось"). На этом фоне Subversion стал тем продуктом, который вывел системы контроля версий на новый уровень и его применение стал нормальной практикой не только у нас в стране, но и вообще везде. Это же обстоятельство сыграло против него. Некоторая заторможенность в развитии вылилась в то, что нормальное слияние веток (merge) и его отслеживание ("стрелки мёржа") появилось буквально недавно даже по меркам софтварной индустрии. И если судить по интевью, переименование файлов и директорий будет сделано нормальным образом только в будущем.

Одним словом, появление третьего поколения систем контроля версий стало вопросом времени и оно таки случилось. Новые поколения разработчиков считают стандартом уже не SVN, а git или Mercurial и недоумевают: "как можно работать с *№;%: SVN-ом, когда у меня тут распределённый контроль версий, всё быстро, продвинуто и вообще - Сам Линус его написал!" Флейм комментариев к интервью очень оказателен в этом смысле. Да и спорность некоторых реплик Ивана подливает масла в огонь.

Что сказать - централизованные системы контроля ещё живы и никуда уходить не собираются, взгляните на тот же список клиентов VisualSVN - для них распределённость не является явным плюсом.

Дабы не начинать холивар distributed vs. centralized VCS, на этом и закончу заметку :)

Перевод // Dear Perforce: fuck you

2011-10-23T05:30:00.000-07:00

Добрейшего!

Кинули тут ссылочку на отличную заметку, буквально крик души человека, измученного ~~нарзаном~~ Перфорсом. Называется он "Dear Perfoce: fuck you", что цензурно можно перевести как "Дорогой Перфорс, иди нахрен", но сведущие в английском поймут, о чём название.

Решил перевести, поскольку сам с недавнего времени работаю с Перфорсом и наступил на некоторые грабли, которые малость испортили нервы. Да и продолжают портить, чего уж там. Замечу, что статья написана в 2007 году и прочитав её в 2011, я не увидел коренных отличий от ситуации на сегодня. Хотя я сам несколько терпимее отношусь к этому продукту :)

Так что ниже - мой перевод исходной заметки, отдельные комментарии показаны в скобочках.

/*
Начало перевода
*/

Дорогой Перфорс!

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

Я полностью согласн с Линусом, который считает, что CVS - это зло, и что любой, кто использует его при наличии альтернативы - "тупой и ужасный", но я переключился бы с Перфорса на CVS, не моргнув глазом. Я бы пал ниц и лобызал ноги создателей CVS, если бы только смог избежать использования твоего "инструмента" самобичевания.

В данный момент я единственный, кто работает с базой исходников.

Уже четыре раза я приходил на работу, садился кодировать, открывал файл, который редактировал и сабмитил буквально вчера, только для того, чтобы обнаружить, что он сейчас в какой-то предыдущей версии. Говорю Перфорсу взять последнюю версию, на что получаю ответ, что файл уже синхронизирован. В конечном счете, я вынужден вызвать "sync -f" (то есть принудительно перезаписать всё или рискнуть поломать мой репозиторий сначала отредактировав файл, а потом внеся то, что у меня откатилось безо всякого предупреждения). Нет, юнит-тесты не помогут поймать эту проблему, ведь они точно так же откатятся на предыдущую версию, а поскольку я никогда не вношу поломаный код, то и после загадочного откатывания тесты будут показывать зеленую полоску, а я как-то не запоминаю в конце дня точное количество тестов каждого проекта. Сегодня он меня заставил сделать слияние ("мёрдж") "их" изменений. Вот только я единственный, кто работает на этой чёртовой ветке, и у меня всего один клиент, который на неё ссылается. (Прим. пер.: у Перфорса во время слияния в окне с 3-хсторонним слиянием показаны "их" - "theirs", "ваши" - "yours" и измения "общего предка")

Когда вы попробуете "интегрировать" (везде оно известно как "смёрджить") файлы из директории А, где вы работали, в директорию Б, он скажет: в "их" файлах есть изменения, "ваши" файлы в порядке, и хотите ли принять "их" изменения? И вы видите, что "их" изменения - это то, что сделали ВЫ в директории А и "ваши" изменения - это те, что в директории, где вы вообще ничего не делали, и куда собираетесь смёрджить всё, что надо.

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

Он недостаточно умён, чтобы понять, что файл, который ты поменял - это... погоди-ка... именно тот файл, который ты поменял! Ну, конечно, можете сказать "Господин Перфорс, с вашего позволения, я бы хотел отредактировать вон тот файл." и после этого он будет знать, но просто так файл отредактировать нельзя. Разговор чокнутых в стране сложившихся обстоятельств. (Прим. пер.: тут игра слов: "perforce land" - "perforce" переводится как "необходимость", "в силу сложившихся обстоятельств", или попросту "припекло") Если попробуете откатывать наборы изменений, он начнёт скулить о том, что не хочет затрагивать файлы, которым были сделаны права на запись после очередного отката, и это несмотря на то, что вы с ними ничего не делали, а только лишь откатили несколько раз.

Он не умеет расширяться. Хотите положить в него терабайты данных? Он это позволит, но как только дерзнёте и вправду начнёте это делать, то при этом или вообще упадёт сервер, или больше никто не сможет нормально работать.

Он определяет права по правилу XVII века под названием "запирание" (Приме. пер.: "locking"). Возможно это из-за того, что он не может наверняка сказать, работали вы над файлом ли нет. Выставляя файлам атрибут "только для чтения", он вынуждает явно ему сказать, когда захотите поменять файл, тем самым явно дав ему узнать, что вы поменяли файл. Он смутится и начнёт скулить, что надо засабмитить файлы и вы скажете их засабмитить, но сабмитить нечего, поэтому создается пустой набор изменений который он отказывается сабмитить, потому что набор - пустой. Этот пустой набор будет мозолить глаза, пока не взорвется солнце или пока вы сами не возьмёте и не удалите его... удалите то, что Перфорс сказал создать, но после создания - отказался принимать. (Прим. пер.: да-да, именно так и бывает)

На это я каждую неделю убиваю по несколько часов.

Обновление: Вы не подумайте, я не просто скулю насчет Перфорса. Да, он мне не нравится, и я по этому поводу кое-что сделал. Я взял и написал инструмент, синхронизирующий Перфорс с самыми разными системами контроля версий, но потом пришёл к выводу, что Git слишком чертовски хорош, чтобы заморачиваться с остальными, так что перешёл на Git с его git-p4 для синхронизации с ~~Сатаной~~ Перфорсом. Если интересно, его можно найти в директории contrib в исходниках git. Просто куда-нибудь скопируйте в другую дирку - и можно работать (но нужен Python).

Что было дальше

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

- У Перфорса просто другой подход. Надо попробовать в него погрузиться, прежде чем так сильно ругать.
Знаете, я как-то бился над, казалось бы, простой проблемой, используя Perl 5 тем способом, который считал самым подходящим, и сделал ошибку, упомянув о нём на открытом форуме.
- Ну конечно, - последовал ответ - неопытных программистов всегда сбивает с толку то, как Перл дает то, что надо. Как только ты в него погрузишься, ты увидишь, что путь Перла - это правильно.
Я расширил описание ошибки и добавил, что между мной и моим напарником (с которым мы бились на проблемой) - десятилетия разницы в опыте.
- Ну конечно, опытные програмеры думают, что их проблему Перл решит тем способом, который они от него ожидают, но как только ты в него погрузишься, ты увидишь, что путь Перла - это правильно.
Примерно таков уровень обсуждений между програмерами касаемо инструментов.
Если что, я пользовался Perforce вполне успешно в нескольких местах (как например дома, как например в компании, раскиданной по нескольким континентам) и, да, тебе надо понять, что именно он думает насчёт контроля версий и конфигурационного управления - и это не обязательно будет совпадать с тем, что думаешь ты об этих же вещах. И, да, его реакция на неверные входные данные может быть совершенно аутичной. Всё, что он тебе говорит - верно, но редко бывает полезным.
Фактически Perforce - это то, что называется "система со своим взглядом на вещи", у него есть свой взгляд на то, что такое контроль версий и конфигурационное управление. Если у вас тот же взгляд на вещи - будете с ним летать. Если не тот - будете с ним бороться. Но в самом деле, как только вы в него погрузитесь, поймёте, что он довольно хорош в том, что делает. Гораздо более хорош, чем SVN, особенно когда вы с ума сходите по, ну, вы знаете... ветвлению и слиянию кода.
Лучше ли он, чем Mercurial/git/прочие - не знаю, я их не использовал. Для тех вещей, что делают они, тем способом контроля версий, который хотят их пользователи, - видимо нет. И это нормально.

Остальные комментарии:

Комментарии типа "Я работал с ним на протяжении N лет, и ни разу у меня Перфорс не: испортил файл/сработал нестабильно/упал"

- Я использую Перфорс 4 года на своём проекте, но никогда не сталкивался с проблемами, о которых вы упоминаете

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

Чтоб совсем понятно было: Перфорс всё записывал правильно (ну кроме случая с окончанием строк, и я понимаю, что там всё настраивается), но тем не менее, я считаю, что система контроля версий не должна додумывать за меня, что же я имел в виду сделать. Ни один файл не испортился и не потерялся, и я ожидаю подобного в будущем.

- Хочу сказать, что несмотря на странности, он делает то, что написано на коробке.
- Перфорс был непробиваем для нашей группы разработки ~10 человек и ~10000 файлов при использовании с Линукса, Виндов и МаксОСи.

Ни на минуту не сомневаюсь в указанных утверждениях. Уверен, именно так он себя и ведёт. У меня нет ни тени сомнения в том, что Перфорс - это стабильная и надёжная база для исходников. Я говорю только об инструментах конечного пользователя.

Коментарии типа "Да ты просто не умеешь им пользоваться/не дал ему ни единого шанса/ты специально его ломаешь"

Я без особых проблем ставил и начинал использовать Bazaar, CVS, Darcs, Git, Mercurial (Hg) и Subversion, всегда меньше часа требовалось для начала полноценной работы даже без того, чтобы начать что-то гуглить. Я дал Перфорсу 2 месяца. Я разговаривал с разработчиками, работавшими с ним годами.

Когда я говорю с опытными людьми, и на мои вопросы как правило отвечают тем, что или не знают как сделать с командной строки, только из GUI, или знают как сделать из комстроки или GUI, но понятия не имеют как оно так срабатывает. Вы правы, я возможно не знаю как его использовать, но обучение базовым операциям управления исходным кодом (включая ветвление и слияние) не должно занимать 2 месяца!

Нет прощения за то, что люди, использующие его годами, до сих пор не могут объяснить, почему что-то происходит именно так, а не иначе, и/или как сделать какие-то похожие штуки. Я полагаю, что что-то явно не так с тем, как Перфорс взаимодействует с пользователем. Так неинтуитивно, что даже годами используя его, всё равно не могут объяснить, как надо делать те или иные вещи.

- Проблемы есть только у тех, кто его не понимает и изучил "по верхам", вместо того, чтобы попросить о помощи.

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

- Похоже, вы используете его как распределённую систему контроля, хотя всё совсем наоборот. Подозреваю, большинство проблем - это результат того, что вы пытаетесь использовать его как svn, git или darcs. Надо использовать систему в том ключе, в котором она была спроектирована, а если архитектура вам не подходит, значит вообще не надо использовать эту систему.

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

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

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

- А я считаю, что инструменты командной строки - очень мощные и полезные.

Так и есть. Не могу отрицать, что они мощные и полезные. Блин, похоже GUI просто втихаря запускает те же самые команды почти на каждое действие. Я также верю, что истребитель F-16 такой же мощный и полезный, но он и близко не похож на что-то, что может быть полезным и мощным без предварительного серьёзного обучения. К сожалению, то же самое могу сказать и об инструментах командной строки Перфорса (хотя и не с таким временем обучения... я надеюсь).

- У Перфорса просто другой подход. Надо попробовать в него погрузиться, прежде чем так сильно ругать.

Ну почему мне кажется, что я один такой, кто видит постоянную проблему "мне он тоже показался странным, когда я начал его использовать". Нет, НЕТ, НЕТ, НЕТ. Такое ВООБЩЕ нельзя произносить. Перфорс существует уже больше десятилетия, и людям известен контроль версий ещё дольше. Не может быть никакого прощения за то, что на текущем этапе основые действия контроля версий могут чем-то непростым. У Перфорса было достаточно времени, чтобы переработать свои интерфейсы, сделать безумные вещи вроде команды "move" (дя, я знаю про команду "integrate", это не одно и то же). Говорить "странный" про совершенно новый инструмент, только что из "беты" - это нормально. Нормально говорить такое, про инструмент, использующий не ту парадигму, к которой вы привыкли. Ненормально говорить такое про такой старый инструмен, как Perforce, с такой старой парадигмой, как централизованный контроль версий.

Я согласен со всеми комментариями о том, что Перфорс - отстой.

Спасибо, приятно знать, что я такой не один.

/*
Конец перевода
*/

Осень - время релизов: IBM ClearCase 8.0, SVN 1.7, PlasticSCM 4.0

2011-10-12T16:47:00.000-07:00

Добрейшего.

Производители систем контроля версий собирают урожай.

IBM решила тряхнуть стариной и выпустила ClearCase версии 8.0 .
Вот список новых фич, кому интересно. Из заметного - сделали ещё более дружелюбный GUI - как десктопный, так и с веб-интерфейсом.

Ну и не остался в стороне Apache Subversion , он отрелизился до версии 1.7. Обещают ряд вкусностей. Например они таки избавились от папки .svn в каждой директории с подконтрольными файлами. Ну и общее ускорение работы обещают, как без него.

Кстати, очень показателен флейм на Хабре по поводу релиза:
http://habrahabr.ru/blogs/development_tools/130214/
SVN до сих пор вызывает эмоции, значит жив ещё, курилка :)

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

eTraxis вышел на новую орбиту

2011-09-29T23:04:00.000-07:00

Добрейшего!

За суетой чуть не забыл о важном. Как известно постоянным читателям бложика, я пристально слежу за развитием eTraxis - системы для управления задачами, отслеживания ошибок, да и вообще трекинга чего угодно. Так вот, он сделал ещё один шаг вперёд! Его онлайн-версия, etraxis.com, о которой я уже писал, теперь стала полноценным продуктом.

Что значит полноценным? Теперь для пользователей стали доступны расширенные возможности работы, а именно - больше шаблонов, больше активных пользователей, больше места под вложения. Что значит продуктом - да, теперь за неё можно заплатить деньги. :) Были добавлены тарифные планы, каждый из которых даёт расширенные возможности.

Конечно же, бесплатный онлайн-трекинг всё также доступен и в нём по-прежнему действует ограничение на 2 активных шаблона записей и 5 пользователей. Если заказчику нужно больше пространства для манёвра - достаточно заплатить, например через банковскую карту. Сейчас после регистрации в сервисе по умолчанию создается шаблон с типовым сценарием работы над проблемой и группы пользователей. Так что дополнительная настройка workflow - это уже шаг на усмотрение пользователя.

Open source версия всё также никуда не делась. Она по-прежнему доступна и активно поддерживается. Новые версии как выходили, так и будут продолжать выходить стабильно. Функциональность open source решения полностью поддерживается онлайн-сервисом и опробуются именно там.

Итак, заходим, пробуем, ну и конечно же покупаем :)

Впечатления от работы с Perforce

2011-09-29T00:41:00.000-07:00

Добрейшего.

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

До этого на Перфорс доводилось только глядеть через плечо коллег, работавших с ним на небольшом проекте. Так что, можно сказать, знакомство начал с чистого листа. Почитал материалы тренинга и по ходу дела смотрел доки на сайте самого Перфорса.

Общие основы

Perforce - типичная централизованная система контроля версий. Есть сервер, который хранит историю изменений подконтрольных сущностей в репозиториях, которые называются depot. Читается как "дипоу", но вообще - просто депо, типа как трамвайное. Клиент, подключаясь к серверу, берет нужную часть сущностей к себе на локальную машину. С этого момента программа-клиент П4 создает т.н. workspace, т.е. рабочее пространство.

Все изменения, вносимые в workspace, при желании отправляются на сервер, в соответствующее депо. Процесс отправки называется традиционно - submit. Отправляемые изменения - атомарны, и работа идет посредством change lists, т.е. списков изменений, отправляемых единой транзакцией. Изменил десяток файлов - посылаешь их через сабмит. Если что-то пошло не так - всё изменение откатывается.

Списки имеют каждый свой номер - примерно как в SVN есть сквозные номера ревизий. Создавая новый список, ему можно или самому присвоить очередной номер, или не присваивать и при сабмите это сделает сам Перфорс.

Если нет желания засабмитить изменения, но нужно показать результат работы кому-либо - используется механизм shelving. Нужные файлы выкладываются "на отдельную полку" всем причастным, их просматривают, делают правки и берут обратно. Похожий механизм используется в Microsoft TFS.

Работа ведется в основном в GUI-оболочке, P4V. Однако можно использовать и командную строку. Но P4V достаточно удобен, отторжения и неудобств он не вызывает.

Что касается обеспечения распределённости разработки и балансировки нагрузки, то несколько серверов могут быть реплицированы между собой. Можно спокойно работать с прокси-сервером и новые изменения будут доступны всем серверам по мере обмена данными между ними. В ClearCase аналогом является механизм MultiSite.

File mappings

Первая особенность Перфорса от большинства систем контроля версий - использование для связи структуры файлов в depot и их отображения на структуру директорий механизма file mapping. Т.е. это отображение файлов из депо на файловую систему пользователя.

Например, рабочее окружение под названием my_workspace настроено в директорию C:\workspaces\my_workspace\ . В настройках workspace пишется например такое:
//depot/... //my_workspace/...
Это означает, что структура будет отображена один-к-одному. Теперь достаточно взять последние версии файлов отдельной командой - и в директории на диске появится срез исходников.
Можно также комбинировать файлы из разных источников. Например, если есть депо с исходниками двух модулей - //depot1/module1 и //depot2/module2, а также приложение, которое их использует - //app_depot/main/, то соорудив вот такие правила
//depot1/module1/... //my_workspace/modules/module1/...
//depot2/module2/... //my_workspace/modules/module2/...
//app_depot/main/... //my_workspace/main/...
можно получать срез нужных исходников автоматически в нужной структуре директорий.
Есть ещё несколько возможностей, связанных с mapping, но общий смысл - именно такой.

Ветвление, слияние и метки

Модель ветвления похожа на модель Subversion. Как и в SVN, здесь ветка образуется копированием структуры нужной директории в любое место депо. Лично мне такой подход не нравится по принципиальным соображениям, однако - он вот такой. В работе столкнулся с тем, что хотя образование ветки процесс быстрый (работает cheap copy), получается всё равно довольно громоздко, т.к. для отстройки исходников файлы приходится всё равно доставать из депо в полном составе. При количестве файлов в ветке, исчисляемом тысячами, процесс растягивается на долгие минуты и даже, при плохой связи, на часы.

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

Для удобства интеграции механизм mapping, описанный выше, был расширен не только для взятия файлов из депо, но и для ветвления и выставления меток. Например, если часто делается интеграция с ветки для новой фичи на основную ветвь разработки, то создается mapping, где прописываются оба бранча, и дальнейшая интеграция сводится к паре кликов. Аналогично - с метками.

Что касается слияния, то как и SVN, Перфорс не блещет ни скоростью, ни сообразительностью. Да, оно успешно сливает вместе две ветки с общим предком. Даже использует для этого 3-хстороннее слияние, т.е. определяет общего предка. При этом скорость при работе с файлами размером в несколько десятков Кб и 2-3-хгодичной историей весьма низка, бывает до десятка секунд. Дефолтный инструмент сравнения и слияния, при всей и наглядности и удобстве, при сложных сравнениях просто начинает выдавать несуразицу, например совершенно не сращивает перемещение кода по файлу. Перемещение и переименование файлов отрабатывает иногда как перемещение, а иногда - как удаление и создание нового файла. Изменения между такими файлами, которые в одной ветке переименованы, а в другой - остались на месте, практически не отслеживаются вообще.
Допускаю, что у меня были сложные нетривиальные случаи - история у многих файлов очень большая и разветвлённая - но конкретно для меня слияние оказалось не очень предсказуемым и стабильным функционалом.

Управление доступом

Что откровенно порадовало - так это управление доступом.

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

Сами же права прописываются в виде текста, где перечисляются права на доступ, имя юзера или группы, IP-адрес или диапазон, для которого применимы права, и директория, на которые права прописываются (wildcards также применимы). Чем ниже правило, тем оно приоритетнее.

Простая схема, но она даёт все возможности для гибкого управления доступом.

Общее впечатление

Общее впечатление сейчас скорее положительное, несмотря на некоторые неудобства. Я бы сказал, что Perforce - это по сути сильно улучшенный Subversion с хорошим GUI. Но при этом платный.

По мере погружения в глубины Перфорса, наверное, что-то ещё напишу.

Второй раз в ту же реку

2011-08-08T22:54:00.000-07:00

Добрейшего.

Как-то за суетой забыл совсем - не так давно я вернулся на предыдущее место работы. Я теперь снова - СМ-инженер. Снова большая корпорация, снова embedded-системы, снова контрактор. Всё как я люблю, в общем. :) Как поется в шлягере гражданина Бадди Гая: "Back to the same old place..."

Основной инструмент теперь - Perforce, а также JIRA, не считая ещё нескольких инструментов. В ближайшее время будет пост про личные впечатления от Перфорса. Откровений, шокирующих подробностей и скриншотов не ждите, ибо NDA никто не отменял. Следите за RSS-лентой, что ещё сказать.

P.S. Теперь, спустя 2 года после заведения блога с записками отставного сиэмщика, впору его как-нибудь переименовать. Но не стану. Меня вот уже и в поиске по этому позывному находят.

Как закрыть задачу в Redmine

2011-08-04T01:05:00.000-07:00

Добрейшего.

Ко мне в бложик часто заходят люди по запросам, связанным с закрытием задачи в Рэдмайне. Им в Redmine надо отметить задачу, как выполненную. Видимо, при всей навороченности этой системы, простейшие операции по началу вызывают недоумение. Хотя всё довольно просто и проистекает из идеологии всей системы. Если вы прочитали предыдущие заметки про Redmine, всё должно быть понятно. Но читали их не все (хотя и стоило бы).

Чтоб, как говорится, два раза не вставать - пишу здесь отдельным постом.

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

Соответственно, чтобы в Redmine закрыть задачу, нужно поменять статус. Сделать это можно двумя способами.

Способ первый. Заходим с интересующую задачу. Нажимаем кнопку Update (Обновить). Появляется форма обновления задачи. Ищем поле Статус, выбираем подходящий пункт, жмём Submit - заслать, стало быть.

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

Всё.

Version Control by Example - свежая книжка про контроль версий

2011-07-26T02:59:00.000-07:00

Добрейшего!

Рад сообщить, что вышла книга Version Control by Example (Управление версиями в примерах). Поскольку я пристально слежу за книгами по SCM, появление новых трудов всегда интересно.

Автор книги - Eric Sink (Эрик Синк), человек и пароход, который живет именно системами контроля версий и другими девелоперскими инструментами уже не один десяток лет. Сейчас он вместе с командой создает Veracity, распределенную систему контроля версий.

Текст выложен в виде HTML и PDF, в скором времени будут доступны бумажные копии и версия для Kindle.

Труд целиком посвящен контролю версий, и только ему. Никаких отступлений в сторону общих практик SCM, например багтрекинга, контроля изменений, управления релизами или чего-то подобного. Нет, только чистый контроль версий с точки зрения его базовых функций и примеры работы с 4 выбранными системами. Написана живо, с юмором даже местами, читать приятно и не напряжно.

Что внутри?

Часть I - Centralized version control (Централизованный контроль версий) - целиком посвящена централизованным системам контроля версий (CVCS) на примере Subversion. Сначала перечисляются и описываются все базовые команды подобных систем, причем в качестве иллюстраций дается "Джоконда" Да Винчи. Над ней выполняют разные манипуляции - подрисовывают усы, шляпу или ещё как-нибудь издеваясь, тем самым показывая наглядно - что такое изменение, добавление, удаление, дельта и прочие термины. Далее эти команды рассматриваются на примере реальной системы - SVN. Пример взят доходчивый, и код, и текст читаются легко.

Часть II - Distributed Version Control (Распределенный контроль версий) - значительно более обширна. Даётся общее описание модели распределенных систем, приводятся плюсы и минусы, которые также честно описываются. После чего поочередно для всё того же примера, приведенного в главе про SVN, рассматриваются Mercurial, git и Veracity. Конечно, на последнем сосредоточено больше внимания, т.к. это детище самого Эрика, однако мне лично было интересно почитать, система и впрямь занятная получилась. Опять же, давно хотел попробовать в деле - после такого описания будет повод взяться.

Часть III - Beyond Basics (Когда основы уже пройдены) - рассказывает о более нетривиальных вещах. В первую очередь дает краткий обзор типовых способов работы (workflows). Ничего нового, но кому-то может быть полезным. Далее углубляется в устройство DVCS - довольно занимательное чтение. Ну и напоследок ряд советов по организации работы. Какие-то тривиальны, какое-то спорны, но в целом, полезны.

Итог. Если в вашей команде кому-то надо ознакомиться с контролем версий с нуля или же обновить свои знания в этой области - эта книжка как раз подойдёт, можно смело брать.

Контроль версий и SCM в Google

2011-05-26T00:48:00.000-07:00

Добрейшего.

Давно ищу разную информацию, касающуюся SCM в Google. Всегда ведь интересно знать, как работают крупные команды. Были разрозненные данные, и вот не так давно появился повод подытожить то, что известно. Нашелся хороший человек, который там работает, он не смог дать подробную инфу в силу NDA (что вполне понятно и ожидаемо), однако дал подсказки для раскопок общедоступных данных, за что ему спасибо.

Итак, Гугл использует Perforce. Использует практически на всех внутренних проектах. Есть сведения, что в Youtube его создатели использовали Subversion до покупки Гуглом, но наверняка сейчас их перевели на общую платформу.
Для "наружного применения" компания выдаёт все популярные open source системы. В первую очередь это git - через него идёт предоставление исходников платформы Android. Ну а Google Code предоставляет централизованный канонический Subversion и распределённые Mercurial и git (из DVCS сначала выбирали между Hg и git).

Над Perforce располагается широкая прослойка из инструментов, заточенных под работу именно на гугловыми проектами. Вплоть до того, что командой для работы с системой является не "p4", а "g4". Многие костыли или workarounds, сделанные из-за недостатка функционала, до сих пор работают, несмотря на то, что в самом Перфорсе это уже давно реализовано. Работает старый принцип "работает - не трогай", ведь переделывать инфраструктуру - дело непростое, и зачастую очень богатое на ошибки. Так что после выхода очередной версии P4 её сначала разворачивают на отдельном оборудовании, накатывают сверху все внутренние тулзы, а уж потом, когда всё настроится и заработает, выкатывают это всем остальным.

Сам Perforce работает на системе серверов в режиме 24/7. Оно и понятно, над исходниками проектов работают круглые сутки со всех точек мира. И конечно, его сопровождением занимается выделенная команда инженеров.

Работа ведется без использования веток. Уж не знаю, чем это вызвано - сложностями работы с Перфорсом или другими соображениями - однако оно вот так. Для того, чтобы на транке не появлялись глючные изменения, их необходимо проверять перед тем, как помещать под контроль версий. Долгое время это делалось посредством обмена email-ами и работой через NFS, где расшаривалось рабочее пространство всех пользователей. Потом в 2006 году в компанию пришёл Гвидо ван Россум, создатель языка Python, и сделал систему ревью кода под названием Mondrian. Она позволяет по-прежнему инспектировать изменения до их помещения под контроль версий, но сейчас до коммита вся информация о дельте и комментариях к ней лежит в BigTable (гугловая система ранения). Конечно, удобный веб-интерфейс (Python + JavaScript) сильно упрощает работу, но вот вводить лишнюю сущность для хранения просто потому, что не принято класть изменения на ветки - по меньшей мере странно. Но - им виднее.

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

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

Данные брались из разных материалов, однако основой служат 2 презентации:

Perforce Users Conference 2010: Developing and Maintaining an Ongoing Strategic Perforce Plan at Google by Geoff Mendal.
Google Tech Talk 2006: Mondrian Code Review On The Web by Guido Van Rossum.

Кстати, ван Россум сделал из Mondrian отдельное приложение, которые можно взгромоздить поверх Subversion и Google App Engine, называется Rietveld.

Если есть кому что добавить - велкам.

P.S. Для сравнения можно прочитать Немного об SCM в Microsoft и Windows. A Software Engineering Odyssey.

Git в картинках на RSDN

2011-05-24T05:38:00.000-07:00

Добрейшего.

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

Сегодня увидел как раз такую - Git в картинках за авторством Игоря Ткачёва, одного из родоначальников и апологетов сообщества RSDN. Название говорит само за себя - объясняется на картинках, как работать с git через git extentions (оконную надстройку над гитом). Объяснение простое и доходчивое, даже я понял что к чему.

В общем, кто давно хотел подружится с git, но боялся ч0рной командной строки и непонятного английского - это для вас.

10 заповедей хорошего контроля версий

2011-05-04T05:48:00.000-07:00

Добрейшего.

Подкинули ссылку на хорошую статью из серии "10 тут-написать-самое-важное". Не смог пройти мимо, т.к. речь - о контроле версий! Называется The 10 commandments of good source control management, или "10 заповедей хорошего контроля версий".

Надо бы её перевести, но пока - перечень Важных Вещей:

Если используете VSS - бросьте сейчас же. Прям щас!
Если что-то не лежит под контролем версий - этого не существует.
Делайте коммиты раньше, чаще и не откладывая.
Всегда проверяйте изменения перед коммитом.
Помните про психопата с топором перед написанием комментариев.
Делайте коммиты сами, не перекладывая на других.
Версионности БД избежать не получится.
Результаты компиляции не кладутся под контроль версий.
Никому не интересны ваши личные настройки.
Зависимости надо тоже пристроить.

Как-то так. Просто и понятно. Да ещё и написано с юмором, так что рекомендую.

gihub для совместной работы студентов

2011-04-20T21:52:00.000-07:00

Добрейшего!

На Хабре опубликовали интересную заметку - Системы управления версиями как инструмент совместной работы студентов. Ещё один интересный пример использования гитхаба не по прямому назначению :) про другой я недавно писал.

Мне, как преподавателю, решение представляется интересным. Повторю здесь то, что написал в комментариях.

Положительные стороны:
- Централизованное хранилище заданий и результатов. Во многих ВУЗах этого до сих пор нет, а тут - всё под рукой. И не будет типичных проблем накануне сессии из серии "у меня вчера вылетел жесткий диск, что смог, то восстановил, поставьте-хотя-бы-тройку!!!" :)
- Обучение системам контроля версий и багтрекингу. Очень правильно.
- Практика командного взаимодействия. Сначала - между преподом и студентом, потом обязательно начинается работа внутри группы. К тому же многие учебные программы имеют курсовые или лабораторные, прямо предназначенные для коллективной работы.

Отрицательные стороны:
- Необходимость наличия интернета. Да, для многих ВУЗов это до сих пор проблема. Кроме того, есть компьютерные классы, где выход в интернет запрещён или невозможен по техническим причинам.
- Привязка с конкретному инструменту. git и те тулзы, которые доступны на гитхабе - на них свет клином не сошелся. Есть, к примеру, ещё и централизованные VCS, они всё ещё имеют немалое право на существование, особенно коммерческие решения. В общем, получится очень однобоко, а это не есть правильно с точки зрения учебного процесса.
- Работа на стороннем сервисе. Пользователь не контролирует данные, находящиеся на сервисе. Но поскольку данные эти - не несут коммерческой инфы и их утрата не окажет большого влияния на учебу в целом (есть локальные копии), то минус это небольшой.
- Нет гарантии, что гитхаб не изменит свою политику и не ограничит подобные варианты использования.

А вообще - интересно.

Узелок на память: upgrade Mercurial 1.8 для Ubuntu 10.04

2011-04-13T15:56:00.000-07:00

Добрейшего.

Набрёл на относительно недавний свой коммент к статье, решил, что стоит запомнить исходную статью в бложике.

Вводная. В общем, не так давно я таки поставил себе Убунту и начал с энтузазизьмом её заселять и осваивать на предмет замены Виндоуз в кажестве десктопа. И поскольку с некоторых пор активно использую для личных нужд Mercurial (параллельно с Subversion, да) - поставил и его туда.

Проблема. С Убунтой 10.04 (на мой новый ноут встала только она, 10.10 залазить не хотела) идет Ртутный версии то ли 1.5, то ли 1.6. Я же использовал к тому времени 1.8 и, как выяснилось, старые версии с репами от более новых версий работать отказываются. Убунтовый тул для апгрейда показывал, что в Убунтовых репозиториях доступна только старая версия.

Решение. Немного погуглив, нашел отменный рецепт решения, и довольно простой, в убунтовом стиле, я бы даже сказал. Собственно, это 3 строчки

> sudo add-apt-repository ppa:mercurial-ppa/releases
> sudo apt-get update
> sudo apt-get install mercurial

Проверяем результат с помощью

> hg --version

Кому надо ещё проапгрейдить TortoiseHg - в статье и про это есть.

Пример описания процесса создания релизов

2011-04-12T05:26:00.000-07:00

Добрейшего!

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

Упоминавшаяся там команда Ф - достаточно обособленная, но самая крупная, и задачи решает самые разнообразные. Так вот, один из разработчиков нашел время и описал процесс построения билдов и всего, что с этим связано. Фактически, описан процесс выпуска релизов от получения исходников до начала развёртывания. Применяется много практик из continuous integration, но ими не ограничивается, а сам процесс описывается для Java.

Рекомендую ознакомиться для общего развития. Даже если ваш процесс отличается или вы только собираетесь что-то внедрять, заметка и названия тулов дадут направление, куда смотреть.

eTraxis теперь доступен в облаке

2011-03-10T05:40:00.000-08:00

Добрейшего

Постоянные читатели бложика наверное заметили, что я часто упоминаю систему отслеживания запросов на изменения eTraxis. Как я уже упоминал, я принимал небольшое участие в этом проекте и до сих пор активно слежу за его развитием.

Собственно, хотелось поделиться радостной новостью - eTraxis теперь доступен не только в виде исходников для самостоятельного развертывания у себя в команде. Теперь это ещё и сервис, работающий по модели SaaS - https://www.etraxis.com/.

Любой желающий может зарегистрироваться и получить свой поддомен (т.е. проект), где он получит возможность создавать до двух шаблонов своего workflow и до 5 пользователей. Специально для сервиса была переработана документация - теперь это несколько онлайн-презентаций с рассказами о том, как надо работать с системой. Можно заимпортировать готовый шаблон и начать работу.

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

Да, кстати, регистрация и использование - бесплатны. Что, конечно же, не мешает ткнуть благодарным пользователям на кнопочку Donate и перечислить малую толику :)

В общем - не сидим, регаемся и начинаем работу. :)

SCM - в массы, или Книжка, которую пишут в github

2011-03-01T04:23:00.000-08:00

Добрейшего.

На Хабре сегодня зацепил взгляд заголовок, содержащий слова "литературное произведение, создаваемое с помощью GitHub". В мозгу сработало ключевое слово - и вот я уже читаю о том, как на github энтузиаст начал писать книжку научно-фантастического уклона.

По итогу порадовал сам факт, что контроль версий начал выходить за рамки традиционного применения. Фраза "разветвление сюжета" заиграла новыми красками :)

Конечно, инициатору ещё предстоит столкнуться с массой проблем, порождённых таким демократическим подходом. Чего будут стоить "форки" сюжета, заe которыми будет трудно уследить даже дотошному читателю. Однако - может получиться занятно.

Начинаю ждать кино, выложенное в Mercurial на Google Code через YouTube ;)

P.S. И почему мне упорно вспоминается "t" Пелевина? :)

Управление изменениями и кессонная болезнь проектов

2011-02-13T15:57:00.000-08:00

Добрейшего!

Давно зрела мысль написать что-нибудь разумное, доброе, вечное. Бойся своих желаний!

Итак, для сайта OpenQuality.ru написал программную статью Управление изменениями и кессонная болезнь проектов. Получилось много и подробно - спасибо редактору сайта Юрию за правильно поставленные вопросы и предложения. Статья, как можно понять из названия - про то, как управлять изменениями в проекте и как изменяющийся масштаб проекта влечет за собой то, что у людей принято называть декомпрессионной болезнью (кессонкой).

В общем, читаем и высказываемся в комментариях к статье.

Используем git для управления сайтом

2011-02-12T04:03:00.000-08:00

Добрейшего.

Я достаточно давно работаю в отрасли разработки приложений для веба, поэтому всегда с двойным интересом читаю материалы о применении SCM для веб-разработки. Поэтому этот материал особенно порадовал: Using Git to manage a web site, что означает примерно "Как с помощью гита управлять веб-сайтом".

Идея, в общем-то, не нова. Берём git, создаем репо у себя и репо на сервере, где лежит сайт. Далее с помощью напильника и механизма хуков (hooks) настраиваем, чтобы при получении очередной дельты через push, локальная копия исходников сайта обновлялась из репозитория. Разработчик меняет код, делает push на сервер, там срабатывает хук, который разворачивает новые исходники в ту директорию, где у вашего сайта DocumentRoot.

Думаю, что-то аналогичное можно придумать и для Mercurial.

Для тех, кто использует распределённые системы контроля и пишет под веб, это хорошее решение.

Как выбирали между Mercurial и git для Google Code

2011-02-05T04:50:00.000-08:00

Добрейшего.

Некоторое время назад наткнулся на заметку в справке Google Code, посвященную тому, как выбирали распределённую систему контроля версий для этого проекта. Ссылка давно ждала удобного повода, но его не нашлось, так что лучше поздно, чем никогда.

С самого начала своей работы проект Google Code поддерживал только Subversion. Надо полагать, в виду его распространённости - ведь после заката CVS именно он стал стандартом де-факто среди бесплатных систем контроля версий. Проблемой выбора распределённой VCS команда озадачилась в 2008 году, в результате чего появилось вот это эссэ: Analysis of Git and Mercurial. Для тех, кто до сих пор поленился хоть немного изучить английский, есть народный перевод. Несмотря на мелкие неточности и стилистические ошибки, вполне можно понять, о чём речь.

Как видно на сайте Гугл.Кода, выбор пал на Ртутного. Причины - в тексте. Также встречал примерно следующее мнение - мол, приверженцы Subversion обитают на SourceForge, фанаты git - на github, ну и Гугл решил в чужой огород не лезть и взял под крыло Hg. Почему бы нет. К тому же, Python, на котором написана бОльшая часть Hg, весьма любим в компании.

P.S. Первый же коммент к оригинальному тексту вопрошает - почему Bazaar даже не рассматривали? Думаю, в первую очередь из-за его меньшей распространённости. Однако, прочитав очередной Bazaar hate speech, подумал, что не только поэтому :) Хотя это субъективное мнение, конечно.

Update: git таки появился среди поддерживаемых систем, не прошло и полгода: http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem

Книги // Software Configuration Management Patterns

2011-01-18T04:36:00.000-08:00

Добрейшего.

Атака на книжную полку продолжается. На этот раз под раздачу попала ещё одна книжку из числа тех, что выбрал себе для детального ознакомления. Называется Software Configuration Management Patterns: Effective Teamwork, Practical Integration, авторы - Стёпа Берчук (Stephen P. Berczuk) и Брэд Эпплтон (Brad Appleton). На русский можно перевести как "Шаблоны управления конфигурацией ПО: Эффективная работа команды, практическая интеграция."

Тема шаблонов в разработке софта прорабатывается уже достаточно давно. Причем, как выяснилось, начало своё она берет из архитектуры. Сергей Тепляков не так давно рассказал на страницах RSDN Magazine об истоках этого направления, почитайте (после этой заметки, конечно же).

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

Вся книга поделена на вводную часть, 2 основных раздела и пару приложений.

Введение и весь 1-й раздел вкратце напоминают читателю о том, что такое Software Configuration Management, а также что такое шаблоны. Что примечательно - здесь не просто ведется повествование от первого лица, а приводятся цитаты из множества других работ. Авторы, достаточно часто публикуются в журналах и участвуют конференциях. Поэтому нет недостатка как в ссылках на себя самих, так и на других авторитетов отрасли. В общем, нормальный научных подход, сразу видно, что не просто взято из головы, но ещё и как минимум обдумало другими людьми.

Основа книги - это, конечно же, описание самих шаблонов. Каждый шаблон дается в одинаковом виде - описывается проблемная ситуация и задаются вопросы о дальнейших действиях, затем дается развернутый ответ. После чего отмечаются задачи, которые связаны с описанным шаблоном, но ещё не решены (Unresolved issues), а также даются ссылки на литературу, где можно прочитать про описанные техники более подробно (Further reading). В общем, правильный инженерный подход.

Всего описано 16 шаблонов, которые авторы условно делят на 2 множества.
Во-первых это Codeline-related patterns, т.е. те шаблоны, которые показывают, как работать с кодом. Сюда относятся:

Mainline - использование главной ветки для выдачи стабильных релизов и ханения только стабильноо кода;
Active development line - разработка "на транке" с минимальным ветвлением и активной работой;
Private versions - ветвление для нужд разработчика, ветки используются для отладки ипромежуточных результатов;
Release line - ветвление с целью формирование новых релизов (1 новый релиз = 1 ветка);
Release-prep code line - то же, что release line, только ветвление происходит непосредственно перед выпуском для стабилизации работы;
Task branch - ветка-на-задачу;
Codeline policy - внедрение и поддержание политик, тесно связанных с коммитом кода и его (автоматической) проверкой;

Второе множество - это Workspace-related patterns, куда идут:

Private workspace - о необходимости выделять разработчику рабочего пространства с теми версиями кода и настройками среды, которые нужны для работы;
Repository - хранилище, в котором хранятся не только версии кода, но и инструменты, необходимые для работы и создания релизов;
Private system build - о необходимости дать возможность разработчику отстраивать систему без пересечения с остальными участниками проекта;
Integration build - интеграционные билды для объединения работы участников;
Third-party codeline - о том, как организовать версионность сторонних зависимостей;
Task-level commit - вариация на тему task branch;
Smoke test - об автоматизированном тестировании при каждом коммите на главную или активную ветку;
Unit test - одноименной технике;
Regression test - о необходимости проводить регрессионное тестирование перед сдачей дельты на интеграцию

В целом - базовые практики, о которым многие уже слышали или пробовали.

В оставшихся приложениях даются краткие описания полезных ресурсов по вопросам SCM и основных инструментальных средств (впрочем, тут сведения несколько устарели).

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

Книги // Adapting Configuration Management for Agile Teams

2011-01-05T01:56:00.000-08:00

Cigarettes and coffee, man, that's a combination.

(c) "Coffee and Cigarettes", Jim Jarmush

Сам я не курящий, однако для книжки, про которую пойдет речь, это вполне подходящий эпиграф. Потому как книжка - про соединение двух очень связанных областей - это гибкие методологии разработки (a.k.a. Agile) и управление конфигурацией (a.k.a. SCM).

Однако, обо всём по порядку. Не так давно я делал обзор книг по SCM. Заинтересовавшие книжки приобрёл и начал планомерно с ними знакомиться. В первую очередь ознакомился с трудом Боба Айелло Configuration Management Best Practices. Книжка была стоящей, как и ожидалось. Боб, как выяснилось, немного знает русский (работал волонтёром в ER и часто бывал на Брайтон Бич ;) ) и с помощью знакомого русофила ознакомился с отзывом, после чего сильно благодарил.

Следующей в прочтение попала книга Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed за авторством Марио Морейры (Mario E. Moreira). Название можно перевести как "Применение SCM в командах с гибкими методиками разработки: в равновесии между устойчивостью и скоростью". Что по-русски, что по-английски - одинаково громоздко, однако смысл понятен.

Перед прочтением опасался, что книжка будет похожа на героев старого анекдота про морскую свинку, однако опасения были напрасными.

В первой главе Introduction: Racing with Confidence автор заранее говорит - кому вообще стоит читать данную книгу. Как и следовало ожидать - читать можно всем. И тем, кто знаком с agile, но хочет узнать больше про SCM, и наоборот. Много "воды", однако - надо же было с чего-то начать книгу. :) Далее идёт ознакомление с основами как SCM, так и agile.

Глава CM Primer с толком рассказывает, что же такое управление конфигурацией. Причем основы изложены правильно. Сначала говорится о 4 основных направлениях ответственности - identification, control, audit, report. А затем - об основных практиках, таких как контроль версий, багтрекинг, управление отстройкой и многом другом. После этой главы должно появиться понимание - что из себя представляет SCM и какова его роль. С точки зрения СМ-инженера - изложено толково.

Следующая глава - Agile Primer - рассказывает о том, что вы давно хотели узнать про Agile, но всё недосуг было прочитать. Причем упор делается больше на идеях и духе, хотя о конкретных практиках также рассказывается. Для начала цитируется Agile Manifesto - чтобы читатель проникся идеями и ценностями. Далее идет рассказ о популярных методах, например, Scrum и XP. А затем, опять же, немало уделяется внимания именно роли личности и персональным коммуникациям - приводятся психотипы участников agile-движения (несколько - от innovator и champion до deviever и denier), их роли и общий настрой (mindset). В общем, познавательно. Я вот лично не работал в Agile-командах, однако для себя получил изрядную картину того, что же это такое.

Далее в главе How CM and Agile Values Work Together делается первая попытка свести вместе гибкие методики и SCM и показать, что они отлично уживаются и дополняют друг друга. А именно - берётся поочередно каждая практика SCM - будь то контроль версий, выпуск релизов или планирование - и рассматривается с точки зрения Agile. Рассуждение идёт достаточно прагматичное и не предвзятое - практик Agile примеряет "на себя" все практики SCM.

Затем глава Approaching Infrastructure for Agile описывает как выстраивается инфраструктура под гибкую разработку. В основном, описывается два подхода - когда всё выстраивается заранее (envisioning) и когда минимальный набор средств на старте проекта постепенно перерабатывается под нужны каждой итерации (refactoring). Также немало рассказывается о выборе между двумя крайностями: создание инфраструктуры самостоятельно, или же размещение/покупка решений "в облаке" - это направление в последние годы набирает обороты.

Опсле чего глава Approaching the CM Implementation for Agile продолжает развивать нчатую мысль и показывает как практики SCM будут внедрятся в работу agile-команды. Аналогично предыдущей главы рассматриваются подходы envisioning vs. refactoring, после чего читателя активно убеждают в необходимости максимальной автоматизации CM-деятельности, что очень правильно.

Наиболее существенная часть книги - это глава Adapting CM Practices for Agile, где подробно описывается, как практики SCM адаптируются к работе команды, исповедующей Agile. Берется какая-то сторона работы гибких методологий, и показывается - как CM увязывается с Agile в описанном случае. Сюда входит и continuous integration, планирование, рефакторинг, test-driven development, парное программирование, управление изменениями, багтрекинг и некоторые другие аспекты. Всё очень подробно и, опять же, прагматично. Автор спокойно может утверждать, что какие-то традиционные практики вроде планирования или baselining могут просто не понадобиться при грамотной работе "гибкой" команды. Причем описывает это обоснованно, с точки зрения здравого смысла и духа гибких методик.

Следующую главу CM Tool as a Strategic Agile Partner предоставил Деймон Пул (Damon Poole). Он делает упор на выборе инструментария под "гибкие" проекты описывающие выбор инструментария как для CM, так и для всего процесса разработки. Причем берет действительно нужные параметры, такие как производительность, наличие репликации или распределенного механизма, поддержка веток и т.п. Неплохая глава, в общем.

Следующая за ней Evaluating Tools Suited for Agile продолжает разговор о выборе инструментов, причем упор уже далается на том, как правильно построить evaluation, т.е. оценку выбираемых инструментов. Мало, но неплохо.

Закрывает книгу глава, предоставленная Бобом Айелло - Using CM Standards and Frameworks to Support Agile - которая во многом повторяет одноименную главу в его собственной книге, на которую ссылался в начале.

На сайте издательства можно прочитать детальный список глав и разделов.

Кому будет полезна книга?

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

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

Общий итог - надо брать.

Update: обновленную аннотацию опубликовали на RSDN.

Обзор книги Configuration Management Best Practices

2010-12-12T16:34:00.000-08:00

Добрейшего.

Как уже знают постоянные читатели бложика, не так давно я озадачился поиском книжек по управлению конфигурацией ПО. В результате получился обзор литературы по SCM, преимущественно англоязычной. Финалистами стали 3 книжки, которые было решено приобрести и изучить. И первой из них - как по "интересности", так и по авторитетности лично для меня - стала книга Configuration Management Best Practices: Practical Methods that Work in the Real World, написанная Бобом Айелло (Robert Aiello) в соавторстве с Лесли Сакс (Leslie Sachs). На русский название можно перевести как "Лучшие практики управления конфигурацией: практические методы, работающие в реальном мире".

Пока заказывал и дожидался - успел прочитать в электронном виде (пиратство - страшное зло!), однако потраченных денег не жалею - труд автора должен быть оплачен. Да и книжка весьма приятна внешне и внутренне. О чём же она?

Книга поделена на 4 части:

The Core CM Best Practices Framework. Основа, начало начал. Рассказывается, что такое SCM, зачем нужен, из каких базовых практик состоит - коротко и по делу. Интересно, что контроль версий здесь обозначается более общим термином source code management, т.е. управление исходным кодом. Сделано это намеренно, т.к. автор считает, что контроль версий (так традиционно называют эту область) - это лишь одна из функций управления кодом. Немало рассказано и про управление изменениями (change control). Опять же, термин более общий, чем просто традиционное "отслеживание ошибок", потому что речь идет именно о высокоуровневых подходах к вопросу. И, к слову, про эти самые системы отслеживания ошибок - ни слова :), только про запросы на изменения продукта. Немало уделяется и выпуску продукта - а именно выпуску релизов и развертыванию, вместе с контролем зависимостей.

Architecture and Hardware CM. Здесь описывается два отдельных аспекта работы SCM. Во-первых, вводится предположение о том, что разработка архитектуры проекта может быть основана на управлении конфигурацией этого самого проекта. Смелое и странное на первых взгляд предположение, однако изложено интересно.
Во-вторых, поднимается вопрос об управлении конфигурацией аппаратного обеспечения (hardware configuration management). Для разработки систем, где задействованы или разрабатываются аппаратные средства - вещь крайне нужная. Описаны только основы организации HCM, поскольку в каждом случае реализация будет различной.

The People Side of CM. Весь раздел - по сути, рассказ о том, как логичные правила и процедуры сталкиваются с нелогичной и противоречивой человеческой природой. Тут и прагматичное "Rightsizing Your processes" (как сделать процессы не слишком громоздкими), и полное борьбы "Overcoming Resistance to Change", и всепрощающее "Learning From Mistakes That I Have Made". Здесь же - глава, написанная психологом-соавтором Лесли, "Personality and CM: A Psychologist Looks at the Workplace". Названия говорят сами за себя, весь раздел - он про людей и этим всё сказано.

Compliance, Standards, and Frameworks. Как следует из названия, подводится опыт изучения и использования различных стандартов и шаблонов процессов. Ведь сама область SCM существует уже три или четыре десятка лет, поэтому здесь давно уже есть стандартизованные подходы. Про них и ведется рассказ.

Об авторе. Боб Айелло работает в области SCM уже 25 лет (четверть века!). За это время переработал в нескольких компаниях, поучаствовал в куче проектов и проконсультировал уйму народу. В настоящий момент, помимо консультаций, является замруководителя рабочей группы стандарта IEEE 828 по Планированию Управления Конфигурацией. В свободное время - главный редактор CM Crossroads - центрального ресурса по вопросам SCM. Иными словами - игрок высшей лиги, человек и пароход.

О книжке в целом. Если посмотреть в целом, то книга - она про людей, как ни странно. Все описанные подходы описываются с точки зрения здравого смысла и повседневной работы простых инженеров. Много личных примеров, где особенно ценен отрицательный опыт.

Чем ещё ценна - это тем, что в одном источнике собрано то, что раньше можно было прочитать или в стандартах (сухим формальным языком), или в отдельным источниках, где нет общей "картины мира". Эта книжка - приятное исключение. Выпусти Боб книжку пораньше - может быть, и не было бы ни моей серии статей, ни этого бложика тоже - за ненадобностью :)

Кому и зачем нужна книга?

Если пишешь код или тестируешь - будет просто нелишним узнать, что происходит вокруг, и почему менеджеры вдруг приводят какого-то человека, который начинает объяснять как надо правильно жить.

Если работаешь релиз-инженером или СМ-инженером - читать обязательно, более общего взгляда на предметную область просто не видел. Цельная картина мира в голове по прочтении - обеспечена. Понимание того, куда надо идти дальше, проявится ещё более четко.

Если руководишь проектом или являешься техлидом - крайне рекомендую прочитать, хотя бы потому, что есть много пересечений с общепроектными видами деятельности. Да и вообще, СМ - это область базовая, а потому именно она создает много узких мест, bottleneck-ов - так что для их преодоления надо знать с какого боку подойти.

В общем, нужная книжка, надо брать.

Update: На RSDN выложили расширенную версию этого обзора.

Как работают распределенные системы контроля версий

2010-12-10T05:48:00.000-08:00

Добрейшего.

В последнее время у меня как-то много стало появляться заметок с упоминанием Codice Software. В первую очередь, это связано с тем, что я делал обзор Plastic SCM, а также рассказывал про Community Edition этого продукта. Да, понравился мне Пластик, чего у там. К тому же Пабло, один из основателей компании, постоянно публикует разные интересные материалы. Тут и история систем контроля версий, и рассказ про подход "ветка-на-задачу", перевод которого я сделал. В общем, compañero Pablo времени не теряет и всячески популяризирует своё детище и контроль версий вообще.

Ну а на днях он продолжил правое дело просвещения и опубликовал очередную заметку: DVCS for Everyone, что означает примерно "Распределенные системы контроля версий доходчиво для всех".

Что интересного? Простым языком объясняется, что такое централизованные системы контроля версий, что такое распределенные системы, какие бывают их виды и чем они друг от друга отличаются. Есть даже объяснение работы mutsi-site, да ещё и с упоминанием ClearCase, за что большой респект. Как обычно - всё понятно, в усиление дается несколько доходчивых картинок, юмора немного - в итоге читается легко и непринужденно.

В общем, переводить не вижу смысла, читайте как есть.

Ну и картинка с иконкой github для привлечения внимания :

История развития систем контроля версий

2010-11-15T18:47:00.000-08:00

Добрейшего.

Пабло из Codice Software порадовал экскурсом в историю систем контроля версий. Написано живенько, с юмором, очень приятно читать.
Да и главная картинка порадовала, здесь на шкалу времени он положил для сравнения мобильные телефоны, используемые в то время, о котором идет речь (кликабельно):

Кто интересуется предметом - рекомендую для расширения кругозора.

Отличная статья о сборке продуктов промышленного уровня

2010-11-12T16:53:00.000-08:00

Добрейшего.

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

Понятное дело, решил узнать, что нынче говорят про SCM в кругах разработчиков. Выяснилось, что почти ничего. Однако был на этом празднике жизни один доклад, который таки оправдывает существование конференции :) Более того, он сильно перекликается с одной из моих старых заметок.

Issues and Challenges with Industrial-Strength Product Composition (Проблемы и спорные вопросы сборки продуктов промышленного уровня). Докладчики - потомки суровых викингов, Лар Бендикс (Lars Bendix, адъюнкт-профессор из Lund University) и Андреас Горансон (Andreas Göransson, сотрудник Sony-Ericsson).

Что же так порадовало?

Перевод краткого обзора от авторов:

Одним из инструментов создания продуктовых линеек, а также продуктов, выпускаемых в различных конфигурациях, является компонентно-ориентированный подход. Данный подход, во-первых, допускает немалую степень гибкости процесса создания новых продуктов, а во-вторых, способен снизить временные и финансовые издержки. Однако у подобной гибкости, достигаемой путем сборки продуктов из набора базовых компонентов, существует и обратная сторона. Прежде всего, чрезвычайно сложным оказывается сам процесс построения крупной системы из множества мелких частей – в том числе из-за того, что каждый отдельный компонент может существовать в различных вариациях и исправлениях. Кроме того, в процесс разработки новых компонентов нередко вовлечен целый ряд различных заинтересованных лиц, каждое из которых работает в соответствии со своими потребностями и на своем уровне детализации. Анализируя ситуацию в промышленности, мы определили набор проблем и задач, требующих разрешения для эффективной сборки продукта. Фактологическим и информационным хранилищем может служить разделяемая база компонентов, а база правил (rule base) позволит пользователям принимать решения по конфигурации на более высоком уровне, оперируя понятиями завершенности и связности.

Нашлись и тезисы, а по сути полноценная статья: http://www.cs.lth.se/home/Lars_Bendix/Publications/BGSG10b/Moscow-camera-ready.pdf - там много несложного английского.

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

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

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

К сожалению, не указано, на какой стадии готовности и практического применения находится эта модель. Зная, что ей занимается человек из коммерческой компании, можно предположить, что работа ведется и в практическом ключе.

Отличная статья, прочитал с удовольствием.

Вышел Plastic SCM Community Edition

2010-11-02T16:10:00.000-07:00

Добрейшего.

Пропустил вчера, сегодня исправляюсь.
Codice Software, выпускающая Plastic SCM, обзор которого я не так давно делал, решила пойти навстречу малым командам и выпустила Plastic SCM, Community Edition. Это всё тот же Пластик, только обновилась схема лицензирования. Команды до 15 человек могут ставить его себе безвоздмездно, то есть даром. Ну что, неплохой подарок. Стоял бы сейчас передо мной вопрос выбора системы управления исходным кодом - думаю, не удержался бы и внедрил на пробу.

Кстати, как раз вчера они выпустили ещё и новую версию, Plastic 3.0.7, с кучей фенечек для интеграции с MS Visual Studio. Выглядит приятно.

Кто не пробовал, но интересуется тематикой бложика - не побрезгуйте, зацените.

Обзор книг по configuration management

2010-10-28T20:47:00.000-07:00

Добрейшего.

Речь сегодня пойдет о книгах - как российских, так и (преимущественно) зарубежных издательств. Довольно давно озадачился поиском литературы по тематике бложика. Ведь, как известно, нет ничего нового под солнцем, значит и про SCM уже много должно быть написано. Интересовали книжки, не привязанные к конкретным инструментам, т.е. книги, которые бы дали общее понимание предмета. Ну как, например, в моих статьях ;) только шире и глубже.

Собственно, данный блог - это следствие отсутствия материалов на русском языке :). Потому как отечественные издательства, судя по ассортименту, вообще не знают что это такое - управление конфигурациями.
Единственным исключением может служить 1 (одна) книжка про ClearCase: Стратегия управления конфигурацией программного обеспечения IBM Rational ClearCase. Однако, при всем моём почтении к этому продукту, надо признать, что рынок его крайне мал в нашей стране, а значит и книжка уверенно проходит мимо покупателя. К тому же, я её читал :) и там довольно мало про сам SCM и много про КлирКейс.
Встречал ещё книжку по Subversion (перевод книжки издательства O'Reilly), однако на том же Озоне сегодня уже найти не мог. Да и, судя по тому, что я увидел в ней, - это по сути перевод официальной документации. "Если нет разницы - зачем платить больше?" :)

Остается рынок западный. "Уж там-то" - подумал я - "точно должны быть залежи литературы". Да и на CM Crossroads видел упоминание разных названий.

Решил пойти по итеративному пути.

Итерация первая - найти вообще все книги, где упоминается предмет, а затем отсеивать лишнее. Где искать? Конечно, на Amazon.com, большего ларька с книжками за границей не найти.
Вдумчивый поиск и анализ выявил в начале порядка 20 (двух десятков) разных названий.

- Неплохо, - подумал я, - столько СМа, как это всё за раз унести-то?

Надо сделать вторую итерацию. Критерии следующие: год издания - не позднее 2006-2007 года. Именно на это время приходится появление популярных распределённых систем контроля версий, а они оказывают сейчас немалое влияние как на рынок в целом, так и на практики применения инструментов. Так что нужно что-то свежее. Также важно наличие положительных отзывов читателей.
Итог поиска - 3 (три) наименования. Остальные - либо старые, либо новые, но, судя по отзывам, не дающие ничего интересного читателю. Не густо, однако посмотрим, что там.

Итак, шортлист:

Configuration Management Best Practices: Practical Methods that Work in the Real World by Robert Aiello, Leslie Sachs
Свежая книжка от основателя CM Crossroads Боба Айелло. Удалось прочитать часть чернового варианта, который он выкладывал перед выходом книги, можно сказать, что книжка действительно по основам. Взято от всего понемногу, каждая тема хоть немного, но освещена. На мой взгляд, есть некоторое количество слишком общей информации и повторений, однако я - не показатель :) К тому же, читал не всю книгу, да и то - черновик, так что наверняка вся книга будет чем-то более цельным. Надо брать. (Уже взял и даже написал отзыв)

Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed by Mario E. Moreira
Марио уже попадал в поле зрения бложика в материале про CM Journal, так что не буду описывать ещё раз, кто это. Книжка же обещает быть сборником рецептов для наиболее динамичной части сообщества разработчиков, а именно - тех, кто практикует Agile, т.е. гибкие методологии. Тема популярная, востребованная, и я постоянно встречаю в сети её апологетов, которые одновременно интересуются и управлением конфигурациями. Так что книжка будет точно "в кассу". Надо брать. (Уже имеется и книжка, и отзыв)

Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Stephen P. Berczuk, Brad Appleton, Kyle Brown
На эту вещь идет довольно много ссылок с CM Crossroads, а авторы постоянно пишут там в свои колонки. Как видно из названия, речь идет не просто про основы, но про типовые решения. Для описания используется язык patterns language, который используется в довольно большом количестве материалов вне темы SCM, так что изложение будет весьма понятным. Надо брать. (Отзыв уже написал)

Ну прямо выездное заседание CM Crossroads получается, а не перечень литературы :)

Следующая итерация - получить эти книжки "из-за бугра" и, собственно, прочитать :) Так что начинаю напряженно ждать. И параллельно искать электронные варианты ;) Как обычно, следите за анонсами.

Update. Ссылки на написанные отзывы см. по тексту.

eTraxis теперь в линейке 3.х

2010-10-25T04:52:00.000-07:00

Добрейшего.

Прошел всего какой-то год (без нескольких дней), с того дня как я объявил о переходе eTraxis на линейку 2.х. И таки шо бы вы думали? Да, он теперь перерос в линейку 3.х! :) С чем и поздравляю его бессменного новатора - Артёма. Напомню, что мне довелось одно время быть соучастником этого проекта, так что за судьбой его слежу пристально.

Для тех, кто не в курсе, краткое содержание предыдущих серий.

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

Вот поэтому и был начат проект eTraxis. Задача была ни много, ни мало, а сделать гибкую и простую одновременно систему отслеживания запросов на изменение. Можно сказать, что это вполне получилось. Можно зайти на главную страницу проекта и прочитать список фич и даже качнуть демку - и многое станет понятно.

Что же такого появилось в Итраксисе, что сподвигло на изменение главного номера версии с 2 на 3?

Главное изменение - это переработка UI. Появились табы и боковые деревья - все зависимые от контекста. Отсюда выполнение многих задач стало проще. В первую очередь, управление шаблонами - именно оно всегда вызывает вопросы тех, кто хочет кастомизировать жизненный цикл выполняемых задач. Кроме того, добавилось немного разного AJAX'а - опять таки, удобства ради и user experience'а для. В самом релизе 3.0.0 добавилось несколько новых фич, например, вью и фильтры стали единым целым.

Не прошли стороной изменения и инфраструктуру самого проекта. Теперь все материалы переехали на площадки Google. Используется Google Сode (код, документация, сами релизы), Google Groups (список рассылки, он же форум) и Blogger (блог проекта). Старый домен планируется закрыть, т.к. Гугл покрыл собой всё, что было надо.

Кроме того, Итраксис теперь распространяется под GPLv3 (ранее был GPLv2).

Теперь стоит ожидать новых релизов чаще чем раньше, поскольку именно недостатки старого UI сдерживали автора от реализации новых фич. Ну а если кто захочет сделать вклад в развитие - велкам, многие уже поучаствовали :)

Управление конфигурациями в Rational Unified Process

2010-10-11T05:51:00.000-07:00

Добрейшего.

Не так давно Александр Новичков сделал перевод той части RUP, которая касается SCM. Частично процитирую предисловие автора:

Данный материал представляет собой перевод Rational Unified Process в части описания дисциплины управления конфигурациями.

... статья будет полезна всем, кто захочет оформить (формализовать, описать) процесс управления конфигурациями, взяв за основу Rational Unified Process. Кстати обратите внимание на логичность и стройность предлагаемого процесса, а для себя сделайте небольшое резюме: ведь по-крупному в RUP ничего нет принципиально нового - все, что здесь описано и так применяется в организациях. Вопрос только объема и уровня формализации

По традиции, хочется сказать несколько ~~слов~~ абзацей в дополнение.

Что примечательно в продуктах IBM Rational – это основательность и монструозность подхода. Главная характеристика, которая приходит в голову, когда знакомишься с чем-то из их портфолио – это “МНОГО” :). Предусмотрено всё и, если быть в теме, то ничего больше и не нужно - у Рэшнл есть всё что надо, на любой случай. При этом, если вчитаться, всё логично и не так уж и сложно - бери RUP и знай себе, применяй под свои процессы в организации.
Конечно, не всем подойдет RUP, нынче в моде всяческий Agile. Однако с материалом будет невредно ознакомиться всем, кто считает, что занимается управлением проектами и тем более управлением конфигурациями ПО.

Сильно зацепил взгляд раздел "Представления". По сути описаны dynamic views и snapshot views, имеющиеся в IBM Rational ClearCase. При этом snapshot views - это модель, работающая в большинстве современных систем контроля версий, а вот dynamic - это привилегия единичных систем.

Шаг «Определение правил конфигурационной идентификации» - его просто можно брать и копировать к себе в проект, соглашение об именовании бэйзлайна просто универсальное. Хотя, конечно, под проект можно и поменять - это лишь рекомендация от авторов стандарта.

Очень непривычно воспринимать русскоязычные сокращения. СДП, ЗИ, ГКИ, УЗИ и т.д., и т.п. - латинские всегда выглядят привычнее, однако это дело личных привычек.

При прочтении можно провести некоторые параллели с моими заметками. В частности, базовые версии - это базовые конфигурации, управление запросами на изменения - это отслеживание запросов на изменение, группа контроля изменений - configuration control board. Ну и вообще, местами я в статьях повторил структуру процесса RUP, сам об этом не подозревая :)

Хозяйке на заметку: как выяснилось, УК - это не только Уголовный Кодекс, но и Управление Конфигурациями ;)

О текущей работе с Redmine

2010-10-07T23:32:00.000-07:00

Добрейшего.

Не так давно выбрали и настроили Redmine для управления запросами на изменения в небольшой команде. Что сказать - работа идет, система работе не мешает, и это неплохой показатель :)
На сегодня пользователей - 8, (под)проектов - 22, записей - 260, из них закрытых - 190. Вполне нормальные показатели для примерно месяца работы.

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

Обновление статуса записи. Сейчас чтобы двинуть запись в новое состояние, надо жать на ссылку Update, после чего заполнять или изменять поля в форме. Неправильно. Удобно было бы показывать внизу записи формочку:

список доступных состояний
список назначаемых
поле коммента

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

Фильтры. Вот воздал я себе фильтр, которым постоянно пользуюсь. Он показывает все открытые, сгруппированные по статусу, отсортированные по приоритету, к показом колонки с названием проекта и без пары лишних колонок. В проекте, где он был создан, он по дефолту применяется. Однако при переходе в другие проекты фильтрация сбивается. Хорошо, что фильтр я создал именованный - достаточно просто нажать на его название на панели справа, и он применяется. Но ведь это надо делать каждый раз, находясь "не в своём" проекте. Неправильно.

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

Странности. Иногда вылазают странности. Например, будучи админом всея Рэдмайна и конкретного проекта - не могу сменить приоритет задачи или передвинуть её в другое состояния. Эксперименты объяснений не дали. Пока считаю, что это побочный эффект изменения состава групп юзеров после заведения записи. Хотя не факт. В общем, работе пока не мешает, проявляется крайней редко.

Однако это мелочи. Надо поискать - наверняка есть решения. Ещё, надо бы отдельно перебрать доступные плагины и подключить самое вкусное по мере того, как система будет использоваться активнее.

Update. По многочисленным запросам - как закрыть задачу в Redmine.

Коротко о главном

2010-09-30T18:37:00.000-07:00

http://goo.gl/AMY6

A successful Git branching model

2010-09-26T17:09:00.000-07:00

Добрейшего.

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

Не удивительно, что стали появляться и вменяемые руководства по практикам ветвления для новоиспеченных лидеров рынка - в первую очередь git и Mercurial. На одно руководство я уже ссылался. Не прошло и года, как я наткнулся на ещё одно руководство: A successful Git branching model.

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

В принципе, если git заменить на другое название системы контроля версий - хуже не станет, практики проиллюстрированы базовые до неприличия. Однако в данном случае подкупило то, как именно они проиллюстрированы :)

В общем, enjoy.

Update 1. PDF-версия.

Update 2. Обсуждение на Хабе закинутой ссылки, есть пара занятных ссылок.

Update 3. Хороший перевод статьи.

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

2010-09-20T01:57:00.000-07:00

Добрейшего.

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

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

Настройка

Установили в локальную сеть на машину под управлением CentOS. Человек, непосредственно ставивший его, пользовался вот этой инструкцией по установке. Всё заработало сразу. (Есть ещё вот такая заметка про установку Redmine на CentOS + ISPManager, может быть, кому-то пригодится.)

Дальше мне пришлось немного поколдовать, чтобы привести настройки системы в соответствие процессу разработки.

Первым делом сменил заголовок. Был Redmine, стал Красношахтинск! Зато нескучно :) Правда, потом пришел директор и поменял обратно ;) А заодно сделал перевод на русский перечислимых терминов, например группы пользователей, состояния в workflow и список приоритетов (будет ниже).

Перво-наперво завел проекты, соответствующие рабочим задачам. К примеру, проекты, над которыми работаю я, разбиваются естественным образом по доменникам, на которым проекты крутятся. Поддомены - это, в свою очередь, подпроекты. Ну и в ним - своё разделение. У меня получилось 3 уровня вложенности.

А если задача к разным проектам? А в этом случае задача заводится в над-проекте. Например, есть www.project.ku и у него foo.project.ku и bar.project.ku. Задачи, общие для поддоменов, заводятся в www.project.ku.
Вот в соседней Команде Д (см. предыдущий пост) проект один, разбиение на проекты было сделано по а) разделам сайта б) крупным фичам, затрагивающим несколько разделов или сайт целиком.
В общем, способы нарезки предметной области у нас разные. Что лучше - посмотрим со временем, пока что всё устраивает.

Зачем вообще разбивать на проекты? Да хотя бы чтобы задачи не пересекались.в общем списке. Иногда это мешает, но в целом отторжения не вызывает.

Дальше определились с пользователями. Тут просто - завели на каждого участника проекта по юзеру, даже без привязки к Active Directory. Роли (roles) оставили те же, что и были по умолчанию и добавили новую, ну и директор их перевел на русский:

Менеджер
Разработчик
Репортер
Контент-менеджер

Группы пользователей (groups) фактически повторили роли - их стало 4 на каждую команду.

Следующая серия допиливаний пришлась на workflow. Трекеры (trackers) оставили почти как есть, с той разницей, что их переименовали. Было

Bug
New task
Support

Стало

Ошибка
Надо сделать
Разное

Что вполне соответствует их назначению в команде.

Приоритеты (priority) также были переименованы во избежание разночтений:

На потом (эту я добавил)
Низкий
Обычный
Высокий
Срочно!
Незамедлительно!!!

Дальше я решил немного доработать workflow, созданный по умолчанию. В первую очередь, состояния были переименованы:

Новая
Выполняется
Решена
Ожидает проверки
Закрыта
Отклонена

Закрыта и Отклонена - это финальные состояния, перевод в них закрывает задачу. Убрал из переходов состояние "Ожидает проверки" (Feedback). В принятом процессе оно было лишнее. Текущий процесс приведен ниже под пунктом "Использование"

Что ещё оставалось сделать - связать репозиторий SVN с Redmine.
Тут ждала неожиданность: если несколько проектов используют один репозиторий, то к каждому проекту его надо подцеплять отдельно! Учитывая, что репо у "Команды Д" Рэдмайн пережевывал минут 5 (и, соответственно, отъедал место на сервере под свою базу), подцепить репо к каждому из десятка проектов - это тот ещё геморрой... Увы, поиск по манам и форумам ничего не дал - пришлось подцеплять репо к проектам постепенно, по мере необходимости.

Отдельно надо сказать про связь записей Redmine и ревизий SVN. У Рэдмайн есть отличная фича - связывание ревизий в системе контроля версий и своих записей в базе. Т.е. если Василий Пупкин пофиксил в SVN ревизии 9874 баги #125 и #145, то в этих записях появятся ссылки на эту самую ревизию с указанием комментария из ревизии. Соответственно, можно пойти по ссылке и посмотреть внесенную дельту.
Для того, чтобы эта схема работала, надо чтобы в комментарии к ревизии было ключевое слово и номер записи, например "Just made minor fix #124.", где fix - ключевое слово, а #124 - это привязка к записи. Списко ключевых слов редактируется вот тут:

http://local_redmine/settings/edit?tab=repositories
секция Referencing keywords. Я добавил ключевые слова "fix,##,пофиксил,фикс".
Кстати, там же есть возможность привязывать ревизии к определенным состояниям записей - вообще чума! Жаль, нигде не пригодилось :)

Ну и ещё мелочь - о новых ревизиях Рэдмайн узнает (и связывает с задачами) только в 2 случаях:

Когда кто-то заходит во вкладку "Хранилище" (Repository) или
По запуску спецскрипта (например, по крону).

Об этом надо помнить и что-нибудь с этим сделать сразу после первичной настройки системы.

Из первичной настройки - вроде всё.

Использование

Текущий процесс работы над задачей выглядит примерно так.

Запись заводится в состоянии Новая.
Назначается на разработчика.
Когда начинается работа, разработчик переводит в "Выполняется".
Выполнена - он переводит её в "Решена".
Менеджер, видя статус или услышав об изменении от разработчика - в одном комнате ведь сидим ;) - проверяет решение и переводит в "Закрыто".
Или же обратно в одно из предыдущих состояний.
Если заведенная запись не будет решаться по каким-то причинам - она двигается менеджеров в "Отклонена".

Права выставлены по следующим принципам:

Менеджер может всё и ему разрешено движение между любыми состояниями.
Разработчик может двигать запись только между соседними состояниями. Например, из "Выполняется" - только "Новая" и "Решена" или из "Новая" в "Выполняется". Закрыть задачу (перевести в "Закрыта" или "Отклонена") разработчик не может, иначе задача пропадет из поля зрения менеджера. Вместо этого он переводит её в "Решена" с соответствующим комментом.
Репортер (по сути, тестер или сторонний наблюдатель) имеет право только на заведение записи.

Просто и всем понятно. Процесс в проектах несложный, поэтому и трекеры настроены соответствующим образом.

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

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

"Все открытые, сгруппированные по состояниям", с сортировкой по приоритету - этот зрительно дает посмотреть что в работе, что закончено и что из очереди новых задач более приоритетное. Кроме того, тут же позывается столбец "Проект", чтобы видеть, откуда задача прилетела.
Разработчики настроили себе "Мои выполняющиеся" - туда попадают все, что в состояниях до "Решено". Мол, пусть решенные мозолят глаза менеджерам :)
"Все решенные незакрытые" - это для менеджеров, видеть что уже сделано.

Фильтры настраиваются очень просто, так что вполне может быть, что-то появится ещё.

Из повседневного - пока что всё. Посмотрим, что будет дальше.

P.S. Кому как, а у меня Redmine уже ассоциируется больше с системой управления проектами, чем с простым багтрекером.

Updates. Может также пригодиться инструкция по установке RedMine на Windows. Кому лень настраивать руками - есть отличная замена - Bitnami Stack.
Ну и вообще - почитайте до кучи обсуждение заметки на RSDN, есть полезные посты.

Как Redmine используется сейчас. И по многочисленным запросам - как закрыть задачу в Redmine.

А кому не хочется Редмайн - можете попробовать eTraxis. Очень рекомендую.

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

2010-09-06T18:38:00.000-07:00

Добрейшего.

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

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

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

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

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

2010-09-06T15:40:00.000-07:00

Добрейшего.

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

Итак, текст.

Цель статьи - объяснить как работает шаблон "одна ветка на задачу", и почему контролировать проекты - это хорошо. Шаблон этот также известен как "ветка для фичи", "отладочная ветка", "ветка для задачи" и даже "ветка для ошибки".
Ветвление и слияние с последнее время стали горячо обсуждаемой темой, особенно в связи с ростом популярности распределенных систем контроля версий, так что, думаю, вам эта заметка будет весьма кстати :)
Я также попытаюсь обозначить взаимосвязь между этим шаблоном и гибкими методологиями типа Scrum.
Ещё я объясню почему "ветка на задачу" является основой для параллельной разработки, и почему этот шаблон гораздо лучше последовательной разработки ("разработки на транке").

Что такое задача

Для начала позвольте задать вопрос: вы используете систему отслеживания запросов на изменения? Если да - переходите к следующему подразделу. Нет - продолжайте читать!

Так значит, у вас нет системы багтрекинга?! Это надо исправить в первую очередь. Возьмите уже хоть какую-нибудь систему. Нет, не надо тут разводить долгих и скучных оценок и сравнений, просто возьмите любую, ведь любая система - это лучше, чем ничего. А вообще, прочитайте Joel's test: 12 steps to better code и трижды проверьте пункт 4.
Есть много систем, которые можно использовать:

Бесплатные: Bugzilla, Mantis, Trac
Коммерческие: Jira, OnTime, Rally, VersionOne

И много других.
Системы отслеживания запросов на изменения предназначены для отслеживания любых запросов (и ошибок), не ограничиваясь одними лишь ошибками.

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

Да, может показаться невероятным то, что вы до сих пор ничего подобного не делаете, однако запомните: никогда больше не делайте изменений в коде без соответствующей задачи. Не важно, исправляете ли вы ошибку, выравниваете кнопочку или же разрабатываете абсолютно новую фичу: создайте для них задачу!

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

Задача должна быть короткой!

Предполагается, что задачи должны быть короткими, как и исправления ошибок. Так что не заводите задачи, которые предполагается решать 3 недели. Разделите её на более короткие. Если вы более привычны к гибким методикам вроде Scrum, то вы сразу вспомните одно из ключевых правил, гласящих, что длительность задач надо держать не выше 16 часов. Думаю, это очень хорошее правило.

Жизненный цикл задачи

Схема ниже показывает, как работает жизненный цикл задачи, её взаимоотношение со всем процессом Scrum. Примечание: задачи, на которые я ссылаюсь, это те задачи, на которые разбиваются истории пользователей - user stories в терминологии Scrum - во время планирования спринта.

Контроль версий находится в самом центре схемы в качестве координатора картинки в целом, однако давайте посмотрим, каковы основные компоненты.

Задача

О чем это? Любой чих будет задачей, а задачи, как уже говорилось выше, управляются вашей любимой системой отслеживания. Что важнее, задачи возникают из списка пожеланий по продукту (заявок от клиентов, списка пожеланий, и т.п.)
Кто это использует? Все. Завести задачу может разработчик, также как и менеджер; тестеры могут найти ошибку, дефект и т.д.
Задача - это центральный элемент в координации проекта.

Ветка

О чем это? Это основа работы разработчика. Разработчики будут всегда работать на ветках, и никогда - на главной ветке (транке). Каждая задача будет всегда начинаться из хорошо известной точки, базовой конфигурации или стабильного релиза.
Кто это использует? Разработчики в повседневной работе. Интеграторы, когда надо создать релиз. Каждая задача тестируется и валидируется, прежде чем её метят как завершенную в системе отслеживания.

Интеграция

О чем это? Когда ряд задач закончен, самое время создать новый релиз. Помните, что "выпускайте пораньше, выпускайте почаще" - это лучшая практика для предотвращения "большого взрыва при интеграции", корня всех зол в мире SCM.
Кто это использует? Интеграторы. Интеграторами могут быть разработчики, играющие эту роль раз в неделю, раз в день - в зависимости от частоты создания релизов.
В больших проектах интегратор может быть полноценной штатной единицей. Они не только сливают изменения обратно на главную ветку, но и отвечают за то, что отстройка производится правильно. Поэтому они, вероятнее всего, бегло просмотрят код, зададут вопросы разработчикам, если что-то не совсем ясно или ведет к конфликтам. Ответственность - вот ключевое слово, стоящее за ролью интегратора.

Примечание для маньяков continuous intergration: да, после continuous integration жизнь есть и, вообще говоря, ветки для задач, исправляют типичные упущения CI и переводят его на другой уровень. Пройдите по указанной выше ссылке и посмотрите на следующие шаги, упомянутые в книге Дюваля про CI.

Релиз

Что это? Результатом интеграции является новый стабильный релиз. "Стабильный" означает, что он прошел все тесты и не осталось ни одной известной ошибки (или все они хорошо известны).
Кто это использует? Вся команда. Как только релиз закончен, он может быть отдан команде тестирования (если таковая есть). Разработчики будут использовать свежевыпущенный релиз как отправную точку для новых задач, над которыми они будут работать во время следующего рабочего цикла.

Часто задаваемые вопросы

Вопрос: Ну так всё-таки, что же такое ветка для задачи?
Ответ: Вы, наверное, слышали про концепцию отладочных веток или веток для фич, не так ли? Ладно, даже если не слышали, ответ таков: это ветка, которую вы используете для решения задачи. Она кратковременна и её назначение - быть использованной для отдельной фичи или исправления ошибки.

Вопрос: Но ведь ветки - это зло?
Ответ: Да кто ж вам такое сказал? Вычитали наверное где-нибудь в руководстве или на форуме по Subversion, может даже на каком-то другом сайте по SCM, да? Ветки - это великолепный инструмент разработчика, но в большинстве систем контроля версий они неправильно реализованы - в том же CVS или Subversion, SourceSafe, Perforce, Team Foundation Server и многих других. А потом говорят, что ветвление - это нехорошо. Наглая ложь! Ветвление - отличная вещь, и надо использовать его ежедневно, вот только инструмент для него надо использовать правильный.

Это не про DVCS

В последнее время буквы DVCS (распределенные системы контроля версий) стали буквально заклинанием на программерских форумах. Благодаря Git и Mercurial целые орды программеров заинтересовались распределенными системами и, что ещё важнее, ветвлением и слиянием. И хотя ветка на задачу - базовый сценарий работы для большинства практиков DVCS (включая Plastic SCM), это не означает, что он является следствием их распределенной структуры. Отнюдь - это лишь следствие того, что они хорошо работают с ветвлением и особенно слиянием.

Факты говорят за себя: хорошие распределенные системы хороши с ветвлении и слиянии, однако ветка на задачу - это не только из области распределения, их можно отлично сделать и в централизованных системах. Вот только большинство централизованных систем вроде Subversion, CVS, TFS, Perforce и им подобных не умеют обрабатывать ветки нормальным образом.

Почему ветка на задачу лучше?

Я детально описал шаблон "ветка на задачу", рассказал о жизненном цикле задачи и его основных элементах. Так что теперь вы вполне представляете почему этот подход хорош. Теперь я намереваюсь подробно осветить почему ветка на задачу - это лучший способ работы почти для всех команд почти всё время (есть всё-таки обстоятельства, когда не надо так часто ветвиться, однако это бывает не так часто).

Столкновение миров: последовательная разработка против параллельной

Давайте рассмотрим типичный проект, который работает по шаблону последовательной разработки, более известному как "разработка на транке" или "разработка на главной ветке". Он всего лишь означает, что все кладут (или "чекинят", от "check in") свои изменения на одну и ту же ветку. Подобный подход очень легко настраивается, очень легко понимается и именно ему следуют большинство разработчиков, использующих инструменты типа Subversion, CVS, SourceSafe и иже с ними.

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

В примере на схеме видно как Пэт (Pat) создает новую форму загрузки, но вносит ошибку через набор изменений 10476. После чего должна поправить её и чуть позже внести на главную ветку (cset:10478). Это значит, что отстройка была поломана между изменениями 10476 и 10478, а все, кто обновляет свои копии в промежутке между ними, будут затронуты этой ошибкой. Именно так, скорее всего, и произошло с Пабло (pablo) после того, как он внёс набор изменений 10477 и обновил свою рабочую копию.

Особо внимательные могли заметить, что мы смешиваем важные изменения в cset:10474 (большое изменение в одном из базовых запросов, которое может поломать приложение самыми экзотическими способами) и cset:10475. Что это значит? Это значит, что если бы нам надо было выпустить очередную версию системы, то базовая конфигурация получилась бы неготовой или недостаточно стабильной.

А теперь посмотрим, как этот сценарий выглядел бы при параллельной разработке.

Как видно, здесь задействованы несколько веток, поскольку каждая задача теперь - это отдельная ветка. А ещё есть стрелки слияния (зеленые такие) и базовые конфигурации (baselines, мы и раньше могли их создавать, однако с новым шаблоном их создание стало ещё понятнее). Взяв этот пример за основу, я пройдусь по проблемам, с которыми мы можем столкнуться при последовательной разработке, объясню как их поможет избежать параллельная разработка и почему эта модель лучше.

Код всегда под контролем

Как часто вы чекинитесь (вносите изменения в систему контроля), когда работаете на транке (при разработке на единственной ветке)? Спорим, вы прежде пять раз подумаете, потому как очень не хочется видеть коллег по работе, орущих на вас за то, что из-за ваших изменений отстройка упала?

Ну так вот, вы работаете над трудной задачей - сложные изменения, несколько дней работы - где вы храните код? Он под контролем версий? Скорее всего, нет, ведь вы не чекините код, который не компилируется, не закончен или конфликтует другими изменениями. Это немалая проблема и одновременно обычная вещь при применении единственной ветки: изменения долго находятся за пределами контроля версий до тех пор, пока разработчики не закончат работу. Контроль версий используется лишь как механизм доставки вместо полноценной системы.

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

Боковая панель - она же работала 5 минут назад!!! Наверняка с вами такое случалось: работаете над изменениями, код работает, что-то поменяли, всё поломалось и вы теряете время, пытаясь понять (обычно комментируя и раскомментируя куски кода), что же вы сделали не так. Такие вещи вполне обычны, когда вы экспериментируете, изучаете API или работаете над чем-то сложным. Если вы на своей ветке - почему бы не чекиниться после каждого изменения? Тогда вам не придется полагаться на (рас)комментирование кода для проверки вариантов работы.

Держите главную ветку нетронутой

Поломка отстройки - вещь достаточно частая при разработке на одной ветке. Чекините какой-то код, который не протестировали как следует - и вы уже не проходите какие-то тесты или даже хуже: код перестает строиться.

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

Имейте хорошие точки отсчета, не стреляйте по движущимся мишеням!

Когда вы работаете на единой ветке, то чаще всего трудно сказать, от чего ты ведете отсчет своей рабочей копии.

Позвольте пойти чуть дальше: как видно из картинки ниже, в какой-то момент вы обновляете рабочую копию с /main. Что это за момент? Это явно не BL130, потому что после неё были ещё некоторые изменения. Поэтому если появляется ошибка, какова её причина - предыдущие изменения или ваши?

Конечно, вы можете сказать: если использовать continuous integration, то всегда можно убедиться, что отстройка проходит нормально (при том, что это достаточно инертная техника - сначала ломаем билд, потом его чиним), поэтому что бы вы ни залили - оно будет в порядке. Да, вы правы, однако что это за конфигурация? Если обновиться в этот момент, то вы будете работать с промежуточной конфигурацией, чем-то малоопробованным... вы будете стрелять по движущейся мишени!

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

Как видно, здесь большая разница: все задачи начинаются из одной хорошо известной отправной точки. Никаких гаданий, никаких "нестабильных конфигураций". У каждой задачи - четкая начальная стабильная точка, что позволяет фокусироваться на своих собственных изменениях.

Заставляйте создавать базовые конфигурации

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

Независимость задач

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

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

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

Ветки как единица изменения

Давайте окунемся в глубины истории SCM: в начале не было никаких наборов изменений и вся работа делалась пофайлово. Не было нормального способа узнать какие изменения связаны с какой задачей, кроме ведения списков файлов в системах отслеживания ошибок, навешивания меток или же записи заметок об изменениях.

Потом на сцену вышли наборы изменений и жизнь стала налаживаться: теперь можно связать изменение 10474 с правками в запросе к БД. Зачастую система отслеживания запросов на изменения может хранить ссылку на набор изменений и наоборот. Проблема в том, что такой подход заставляет разработчика использовать наборы изменений как атомарные единицы изменений, а это не очень удачная идея. И вот почему: по определению набор изменений может содержать одну версию каждого файла или директории - и что если вам надо сделать более чем один чекин для одного файла по ходу работы над одной задачей? А нельзя. Так что всё кончится тем, что чекиниться будете редко, а это небезопасно. И это неправильно!

Ну а потом появилось следующее поколение систем SCM, которые могли правильно работать с ветвлением и слиянием. Вот поэтому сейчас, вместе с Plastic, стало возможным использовать ветки как нормальную единицу изменения. И ветки не ограничены числом версий файла или директории - пожалуйста, делайте коммиты так часто, как захотите!

Хватить распространять ошибки

Люди, имеющие отношение к опасным материалам, работают контролируемом окружении, обычно за закрытыми дверями, для того, чтобы предотвратить распространение катастрофических последствий, если таковые появятся. Мы можем у них многому научиться.

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

Теперь посмотрим на ситуацию с точки зрения "ветки на задачу". Ошибка всё равно будет, однако у нас есть возможность среагировать прежде чем она затронет главную ветку. Есть разногласия и есть стратегия по предотвращению.

Улучшенное отслеживание

Лучшее подтверждение - на практике: взгляните на ветку task115. Вы знаете, что это за задача в системе отслеживания запросов на изменения? Видимо, 115, да? Клёво. Есть связь. Достигнута полное отслеживание по шкале CMMi. Проще и быть не может.

После этого мы уже можем реализовывать интеграции ещё клёвее (навроде того, что мы делаем в Plastic), чтобы можно было дважды щёлкнуть на ветку и проверить связанную задачу или же перейти к ней и проверить измененные файлы, создать инспекцию кода и т.п.

Но в самой основе этого отслеживания лежит простое соглашение об именовании. Такого вы не сделаете с подходами, основанными на наборах изменений или использую разработку на главной ветке.

Закругляемся!

Длинная получилась заметка!

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

Мы используем этот шаблон уже долгое время в хорошими результатами. Конечно же, мы сочетаем разные шаблоны: ветка на задачу используется для кратковременных (тактических) задач, тогда как долговременные - такие как релизы с исправлениями ошибок, новые линейки для техподдержки и т.п. - обычно ведутся на более длительных по времени жизни (стратегических) ветках. Можете посмотреть предыдущую статью по поводу стратегий интеграции.

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

2010-08-23T15:29:00.000-07:00

Добрейшего.

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

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

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

2010-08-19T06:14:00.000-07:00

Добрейшего.

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

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

2010-08-03T05:18:00.000-07:00

Добрейшего.

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

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

Статья получилась основательная и детальная - человек попробовал всё, о чем пишет, не поленившись списаться с разработчиками указанных систем.

Кстати, если интересно почитать про Базаар из первых рук - тогда вам в блог Базарный день , который ведет один из разработчиков этой системы. Ссылку дал автор в комментах к заметке на Хабре - там, в свою очередь, есть адекватные комментарии по теме.

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

2010-07-25T15:40:00.000-07:00

Добрейшего.

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

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

Из понравившегося.
Antipatterns of Change Control - Антишаблоны контроля изменений - за авторством Mario Moreira. По сути - перепечатка 4-х "антипаттернов" из книги Anti-Patterns and Patterns in Software Configuration Management. Ситуации в статье взяты достаточно простые. Кто хоть раз сталкивался с командной разработкой или делал сколько-нибудь сложную систему, тот обязательно сталкивался в описанными примерами. Например, антишаблон "All Changes are Created Equal" ("Все изменения созданы равными" - аллюзия на цитату из американской конституции). Понятно, что у каждой задачи, а соответственно и изменения, есть свой приоритет и поправить баг, ломающий половину приложения - более важно, чем сделать небольшой клин-ап кода. Другие три антишаблона - примерно такие же.

Однако, сам подход интересен, появился повод прочитать ту самую книжку, которой Марио вдохновился.

A pragmatic approach to Build and Deployment management - Прагматичый подход к управлению релизами, автор - Mayank Gupta. Развернутый пример того, как по шагам навести порядок и внедрить SCM там, где о нём только слышали. Рассмотрена команда, где предыдущий СМщик ушел, оставив недоделки и вообще бардак. Соответственно, специалиста пригласили, чтобы хотя бы не пустить на самотек то, что уже было настроено. В итоге автор разобрался в состоянии дел и разработал план внедрения правильных практик, сделав упор на Continuous Integration. После чего начал план претворять в жизнь. Рассмотрен план работы и его разбиение на фазы.
Изрядная картина того, как надо наводить порядок и внедрять SCM. Мне понравилось.

CM: The Next Generation of Branching Standards, автор Joe Farah. Джо ведет постоянную колонку в этом журнале, называется она "CM: следующее поколение". В рамках этой серии и написана заметка "Следующее поколение стандартов ветвления". Статья довольно большая, что нетипично для CM Journal, кроме того, заставляет малость подумать. Основная мысль автора - перейти от модели "Файлы + Ветки + Метки" к "Product + Stream [+Promotion Level]", то есть по сути выйти на уровень вверх, абстрагироваться от низкоуровневых операций. Разумеется, это невозможно без правильных инструментов. Сколько читал - всё ждал, ну когда речь зайдет о практическом применении. Из краткой информации об авторе выяснилось, что он никто иной, как Главный Перец в Neuma Technology, выпускающий интегрированный продукт Neuma CM+. И хоть прямых ссылок на него в тексте нет - думаю, именно он воплощает описанную технологию. Давно хотел с ним поработать, теперь появился ещё один повод.

Кстати, подобная абстракция, т.е. переход к более высокоуровневым концепциям в СМ, уже встречается в продуктах того же Rational - ранее это проявилось в UCM, теперь во всю применяется в Team Concert и Jazz. Ну и всяческие MS TFS и AccuRev тоже не отстают.
В общем, статью стоит прочитать, чтобы абстрагироваться от привычных вещей и взглянуть сверху на происходящее.

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

2010-06-28T00:38:00.000-07:00

Добрейшего.

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

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

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

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

2010-05-25T05:31:00.000-07:00

Добрейшего.

Через старый уважаемый сайт набрел на статью на молодом гиковом сайте. В общем, на Хабре выложили пост про использование 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

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

2010-05-13T03:41:00.000-07:00

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

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

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

Have fun ;)

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

2010-04-19T05:46:00.000-07:00

Добрейшего.

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

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

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

К слову, терминология в переводе несколько отличается от той, что дана в моих материалах, однако соответствия быстро находятся, т.к. все термины приведены также и на английском. Какая из них лучше - решать читателю. Скромно посоветую свою, выверенную редакторами RSDN Magazine ;)

Итак, интересующимся - рекомендую.

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

2010-04-08T19:21:00.000-07:00

Добрейшего.

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

Распределенная природа работы. Многократно встречается утверждение, что Пластик - истинно распределенная система контроля. Центральный репозиторий имеет место быть, однако каждая рабочая станция может спокойно работать автономно, обмениваясь инфой как с серверами, так и с другими потребителями. Используется 2 механизма на выбор - репликации данных и обмен патчами. Рискну предположить, что в основе репликации лежит аналогичный механизм баз данных средствами back-end СУБД (но могу и ошибаться). С работой патчей тоже все, полагаю, знакомы. Причем обмениваться данными можно как угодно, например - реплицировать целиком отдельную ветку. Сервером при этом может являться даже машина разработчика. Краткая иллюстрация:

Выбор элементов для работы с помощью "selectors". Это одна из ключевых возможностей, на мой взгляд. Концепция явно взята из ClearCase и Perforce. В конфигурационном файле пишется для каждого элемента (или группы элементов): что выбирать (имя или маска для выбора), с какой ветки и версии или по какой метке. Там также пишется - что делать при чекауте элемента (например, создать автоматом ветку). Надо посмотреть исходники с другой ветки для группы файлов - меняется одна строчка, переустанавливается конфиг, дальше система подбирает из репозитория правильные версии элементов - и юзер продолжает работу (подбор новых версий и скачивание идет без его участия, автоматом). По сути, происходит выбор конфигурации продукта путем её (конфигурации) описания специальными правилами. Это позволяет более гибко задавать срез версий, который хочет получить пользователь. Такой подход более универсален, чем, например, просто номер ревизии, т.к. интересующие версии могут быть раскиданы по разным ревизиям репозитория. Здесь же можно в одном workspace видеть данные с разных веток одновременно. Вот небольшой пример селектора с одним правилом (их может быть неограниченное количество):

Возможности ветвления и слияния. Авторы считают, что надо уделять больше внимание отращиванию веток и их слиянию. Ведь именно плохая работа с branching и merge отпугивает народ в принципе от использования практик ветвления, что очень плохо (чему доказательством многочисленные войны на форумах). Создатели это понимают (и всячески это подчеркивают) - и делают всё, чтобы отращивание и слияние веток было как можно более простым. Механизм довольно интересен - с одной стороны, ветка отращивается для репозитория целиком, с другой - в неё "складываются" версии по мере появления для каждого элемента. Слияние данных тоже не отстает по возможностям, оно там трёхпозиционное, с поиском дельты через общего предка - я с таким работал в ClearCase, отличный механизм. Ну и до кучи - есть selective merge (cherry picking), это слияние не ветки целиком, а указанного диапазона версий (такое и в SVN есть); также есть subtractive merge (про этот вид анти-слияния стоит отдельно потом написать заметку). Есть также 3D-просмотр дерева.

Переносимость. Заявляется кроссплатформенность (Windows, Linux, Solaris, MacOS), в качестве back-end используются разные СУБД. В частности, не так давно был заявлен Oracle в качестве ещё одной поддерживаемой базы. Требует .NET 2.0 - то есть или соответствующий фреймоврк под виндами, или Mono.

Интерфейс. Имеется родной GUI-клиент, есть интеграция с Visual Studio, Eclipse, JDeveloper. Есть и консольный клиент. Но основной упор делается на удобство родного клиента - вплоть до 3-хмерного просмотрщика истории элемента (веток, версий, меток и т.п.).

Интеграция с багтрекерами. В настройках клиента указаны Bugzilla, Jira, Mantis, Trac и ещё несколько других. На картинках в доках видно, что есть привязка задач к веткам, что логично и очень правильно.

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

Есть много других фишек, например, ряд вещей, связанных с безопасностью или сбор метрик по работе с кодом.

В целом же привлекла внимание наиболее интересная фича - selectors. Как уже было сказано, она сильно напоминает config specs у ClearCase и аналогичный механизм у Perforce.

Пощупал
Итак, думаю, надо скачать демку и пощупать. Зарегался на сайте сначала, но потом саму закачку решил отложить - инсталятор 50 мег, а инет дома оставляет желать лучшего в вечерние часы. В общем, не стал качать, потом был занят.... И тут - письмо, пишет их продажница. Мол, Юрец, ты у нас тут по сайту ходил, решила узнать - мож тебе помощь какая нужна?
В общем, понятно - работа с потенциальным клиентом, молодцы, зачёт.
Не удержался - скачал на работе. Поставил, получил ошибку при настройке способов аутентификации между клиентом и сервером, списался с суппортом, на следующий день (разница во времени...) получил совет как победить (граждане, читайте мануалы!). Суппорту - ещё один зачет, молодцы. "....А вы все здесь - маладцы!" (с) День радио. :)

В общем, запустил. Сайт и мануал - не обманули, всё работает как описано и нарисовано на картинках.
Работа с ветками, метками и историей элементов - вполне понятна и не вызывает отторжения. По крайней мере, короткого User manual мне хватило чтобы сразу сделать всё что надо.

Selectors работают как заявлено - имея несколько отращенных веток свободно указывал несколько в селекторе и элементы действительно выбирались по нескольким веткам. Ветки растятся, метки вешаются, мёржи сливают, конфликтные ситуации ловятся. Приятный редактор диффов и слияний.
Репликации также работают нормально - получилось создать 2 репозитория на сервере и за-push-ить между ними пару веток. При этом машина разработчика становится сама сервером (работает по 8084 порту).
Интеграцию с багтрекерами не проверял, т.к. пользуюсь eTraxis, который они не поддерживают ;)

Особенности.

Все операции над объектами - элементами, ветками, метками делаются мышкой через контекстное меню, никаких кнопок на тулбаре нет, горячих клавиш нет. Для частого использования (например, интеграторами) это будет геморрой и для больших объемов работы - GUI-клиент противопоказан, надо использовать командную строку. Кстати, в некоторых других тулзах гуёвые операции сопровождаются консольным выводом - это бывает полезно - здесь же этого также нет, увы.

Сам по себе GUI - очень неплох, приятен и вообще даже местами красив. Сделал небольшое дерево веток с версиями в 3D-просмотрщике, получилось малость непонятно, но очень прикольно :) Кстати, желающие могут просмотреть историю изменений через Gource - об этом подробно написано в их блоге.

Итого
Хороший продукт, мне понравился, попробую поработать с ним в рабочем режиме.
Любителям попробовать что-то новое - качать и ставить обязательно.
Ностальгирующим по P4 или ClearCase (типа меня) - рекомендую настоятельно.
Любители распределенных систем - попробуйте, расскажите насколько модель работы Пластика плоха/хороша по сравнению с вашими тулзами.

Ссылки
Официальный сайт
Документация
Список клиентов со ссылкой на отзывы

Windows. A Software Engineering Odyssey

2010-03-30T06:17:00.000-07:00

Добрейшего.

В предыдущем посте я упоминал Майкрософт и политики управления конфигурациями, которую они использовали для разработки Windows. Нашел презентацию от одного из инженеров, работавшим над Windows 2000 - Марка Луковского - где примерно половина материала касается непосредственно системы контроля версий и обеспечения параллельности разработки. Считаю, познавательный материал. Ниже - сама презентация и некоторые мысли.

Захотите посмотреть на полный экран - жмите Full.

В общем, какие, с моей точки зрения, важные моменты я увидел.
Наследство от Win NT 3.1 досталось веселое - строгая подчиненность; все работают на одной ветке (другие не позволяет система); жесткая связь процесса выпуска билда системы и его тестирования; ломает один разработчик - починки ждут 1400 разработчиков и вся команда из 5000 голов. Надо было что-то делать. В первую очередь - разбивать всё на более мелкие составляющие - более мелкие команды; менять систему контроля версий; автоматизировать отстройку.

В результате взяли SourceDepot (доработанный Perforce) и перекочевали на неё "на живую", по ходу работы. Параллельно работала SLM (предыдущая система контроля версий) и шла миграция на SourceDepot, причем попутно менялась сама структура исходников проекта. Представить только как полторы тысячи человек (постепенно это число выросло до 5100 человек) перетаскивают всю эту уйму кода, попутно жонглируя им в совершенно другие структуры (а число файлов постепенно выросло до 411 тысяч файлов) - жутко интересно становится, во что оно им стало по времени и нервам...

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

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

Народ спорил, что такое же можно было бы сделать с помощью любой распределенной системы. Наверное, не спорю. Не забывайте, что по состоянию на то время из распределенных систем был разве что BitKeeper, да и сама концепция распределенных систем была для знакома лишь гикам-разработчикам Линукса. Да и, судя по всему, им требовалась какая-никакая централизация и разделение труда, ведь команда быстро растет и устраивать хаос на ровном месте руководству совсем бы не захотелось. Как именно работала централизация - опять же, читайте предыдущую статью про применение SourceDepot.

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

Так что грамотные правила совместной работы, поддерживаемые инструментарием - это отличная комбинация.

P.S. И, конечно же, привет противникам ветвления ;)

Немного об SCM в Microsoft

2010-03-27T06:14:00.000-07:00

Добрейшего.

На RSDN в ходе дискуссии кинули ссылкой на заметку, датированную 2006 годом, написанную бывшим сотрудником Microsoft.
Мойша (автор) писал, в основном, касательно бюрократии, царившей в конторе, на примере работы над своей фичей. В довесок было также упомянуто вскользь о политиках контроля версий и о том, как они добавляли неповоротливости в и без того неповоротливый механизм. Ниже - оригинальный текст и некоторые выводы из прочитанного.

In Windows, this model [централизованного репозитория - прим. ред.] breaks down simply because there are far too many developers to access one central repository. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.

Итак, у них иерархия репозиториев.

В корневом лежит наиболее стабильная рабочая версия системы, которая имеет определенные версии входящих в неё подсистем (hardware, core, UI и т.п.). Это 1 уровень.
Каждая подсистема разрабатывается в своём репозитории. Из корня берется послденяя доступная версия системы и от неё идет разработка. В "корень" отправляются лишь стабильные версии подсистемы путем репликации (или же хитрой миграции). Это уровень 2.
Подсистемы состоят из компонент - и для каждой тоже есть свой репозиторий, с копией последней стабильной подсистемы (и какой-то версией всей операционки). Это уровень 3. В нём компонент созревает и периодически отдается в подсистему уровнем выше.
Последний, 4-й уровень, содержит наименьшие атомарные модули (с разной свежести версиями подсистем, компонент и т.п.) и отдает результаты работы на 3-й уровень.

Вот и получается, что для того, чтобы код конечного разработчика попал от него в корень (т.е. в код операционной системы) - он интегрируется сначала в компонент, проверяется, потом в подсистему, снова проверяется, а затем уже в код системы. И чтобы разработчику получить для работы последнюю стабильную версию системы, ему надо дождаться, пока пройдет обратная миграция кода (propagate, "пропагейт") - от корня к конечному репозиторию. Что ж, есть в этом своя логика. Жаль, что переходы между уровнями шли так долго.

Кстати, немедленно вспомнилась моя же заметка про основы СМ и базовые конфигурации. А именно - фрагменты с картинками о компонентах, суперкомпонентах и продуктах. Только у МС всё значительно сложнее.

Есть ещё сложности при таком сценарии, про них писали в комментах - с циклическими зависимостями. Если модуль А зависит от модуля Б, и Б зависит от А, и кроме того, они находятся в разных репозиториях это значит, что:

для разработки, отладки и предварительного тестирования надо иметь в одном из репозиториев результаты обеих модулей, т.е. сделть модуль А, дождаться реплики на ноду выше, дождаться пропагейта из ноды - "вниз" к модулю.
в продукт или подсистемы выше уровнем надо подавать на интеграцию изменения параллельно.

Вообще, управление зависимостями - задача очень нетривиальная. И будь это всё в одном центральном репозитории - проблем бы вообще не стояло. Но тут - иерархия, приходится как-то крутиться.

Итог такой организации работы: изменения проходили снизу вверх и обратно очень долго, месяцами - и это очень плохо.

Комменты
Само собой, комментов - раскинулось море широко. Большая часть - высказывания про саму фичу, но мне же показалась интересной следующая инфа:

The current source code management setup in Windows was introduced by Mark Lucovsky (him who Ballmer threw a chair at when he announced he was joining the big G). The VCS is called SourceDepot and it's a modified version of Perforce.

В общем, при работе над Вистой (как, наверное, и при работе над более ранними версиями) использовали систему контроля версий, именуемую СорсДипо. Она является разновидностью Perforce (P4, Перфорс), проприетарной системы контроля версий. Мне довелось работать с ним немного плюс слышал от коллег разное. В общем, да, выбор неплохой. Надо полагать, Перфорс доработали для Майкрософт именно в сторону распределения репозиториев. Не путать с распределением всей системы контроля версий - всё-таки Перфорс является централизованной системой контроля и репликация репозиториев ещё не делает её "гитом". Кстати, некоторые возможности, вроде аналога конфигспеков, делают её приближенной по возможностям к ClearCase.

Так-то так.
Интересно было бы узнать, используют ли в МС по-прежнему СорсДипо (заметка Мойши ведь от 2006 года) или уже полностью перешли на TFS даже для создания Windows? По крайней мере, руководства по TFS-ному СМ они пишут во всю.

P.S. На отдельной странице собраны ссылки на статьи по основам контроля версий и вообще управлению конфигурациями.

git presentation by Linus Torvalds - для коллекции

2010-03-25T23:59:00.000-07:00

Добрейшего.

Прежде чем писать про новые системы контроля версий (да, про них заметки на подходе), надо бы подбить имеющуюся информацию о существующих.
Апологеты git и вообще распределенных систем контроля версий часто ссылаются на речь Линуса Торвальдса в рамках Google TechTalk, где он описывает своё детище - git. Именно с неё, насколько помню, началась экспансия git на рынок систем контроля версий.
Кто бы как не относился в распределенной модели, а знать первоисточники надо.

Читаем стенограмму самой речи на английском. Не все понимают живую английскую речь - читать им будет удобнее. Ссылок на многочисленные переводы не дам, не буду баловать, учите английский, оригиналы рулят.
У кого английский получше - смотрим длинное видео. Линус, как известно, финн, так что английский там несложный.

Кстати кто ещё не читал - заметка про политики контроля версий с использованием git.

Критика VersionControlTools Фаулера

2010-02-27T06:11:00.000-08:00

Добрейшего.

Перефразирую советскую классику: "А не замахнуться ли нам на Мартина нашего, понимаете ли, Фаулера?". Ну, просто набрел сегодня на свежую статью от означенного автора и зацепил меня заголовок "VersionControlTools". Да, в оригинале тоже слитно, Вики уже прям надиктовывает названия статей.

Так вот, увидев ключевое слово, не смог пройти мимо. Прочитанное, мягко говоря, разочаровало. Приведу несколько значимых для меня пунктов и цитат.

1. Рассуждая о стОящих системах контроля версий, автор не заморачивается ознакомлением с большинством из имеющихся. Для рассмотрения берутся традиционные SVN, git, Mercurial. Про остальные говорится, что в них нет или capability, или visibility. Т.е. остальные или хиленькие, или малораспространённые. Кто же попадает в эти категории? В первую очередь, IBM Rational ClearCase и Microsoft Team Foundation Server ("Two in particular generate a lot of criticism"). В сад также отправляются Perforce, Bazaar и MS VSS (этого - поделом, надо сказать). Причина?

I will, at least for the moment, leave it with the fact that developers I respect have worked extensively with, and do not recommend, these products.

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

2. Далее идет выбор между централизованной и децентрализованной (распределенной) моделью. Или вам нужна централизация,тогда SVN - ваш выбор, или децентрализация - тогда будет ещё одна развилка - git/Hg. Далее идет разбор плюсов и минусов обеих моделей. Точнее даже не моделей, а просто SVN и всего DVCS. Причем после короткой прилюдии у Subversion рассматриваются только минусы: распределенные системы быстрее на операциях с локальным репозиторием, они могут эффективно работать без наличия сети... И ещё один минус: оказывается, в распределенных системах вы можете гадить в локальный репозиторий сколько угодно и весь этот стыд не будет никому доступен, пока вы сами не выдадите его миру... а в SVN - все видно, даже те ветки, код на которых строиться не будет (увидят - засмеют!). В общем, первые 2 причины засчитываются, третья является просто следствием странного представления о стыде и его видимости.

3. Отдельно автор остановился на ветвлении (branching). По его мнению

... the argument against a DVCS, that it encourages wanton branching, that feels good early on but can easily lead you to merge doom.

Т.е. развратное ветвление приводит к непонятно хаосу во время слияния (merge doom).

Причем!

... reckless branching isn't something that's particular to one tool. I've often heard people in ClearCase environments complain of the same issue.

Т.е. необоснованное бранчевание - это прям беда многих тулов и поговаривают, что в КлирКейсе та ж самая задница!

Что тут скажешь... многие команды вообще только-только начинают понимать, что отращивание бранчей - это хорошо и этого не надо бояться. А тут уже 2 шага вперед - все так и норовят сделать лишний десяток веток, по рукам не успеваем давать! В общем, странное заявление. NB: Ветвиться можно и нужно.
К слову, о ClearCase. Там ветвление вообще делается почти прозрачно для пользователя. Достаточно в правилах текущего представления репозиториев сказать - "при чекауте вот этих элементов автоматически создать ветку такую-то и сделать эту ветку рабочей для указанного элемента". Что и происходит. Девелопер лишь делает чекаут элемента - автоматом создается ветка и работа идет уже на ней. Причем таких автоветок можно делать любое количество и их содание будет происходить прозрачно.
Reckless, говорите... ну-ну...

4. Далее идет сравнение распределенных Hg и git. Тут встреча проходит на равных, в конце мачта - ничья, а Mercurial выигрывает по буллитам... ну, просто Фаулер использует именно его и всё тут. Принципиальных отличий нет.

5. Предлагается рассмотреть вариант с использованием сразу двух систем контроля версий. Конечно, упоминается git-svn. Делается вывод, что иногда можно и так, особенно если начальство навязывает одну систему, а команда подпольно юзает что-то другое, сливая в навязанную систему лишь большими кусками. В общем-то, был у нас подобный пример на одном проекте - использовали SVN и ClearCase... Я там не работал, но разработчикам нравилось. А сколько было геморроя интегратору... это знает только он. Хотя, человек тварь живучая, ко всему привыкает и даже начинает получать от неудобств особенное удовольствие.

По мне - так на здоровье, хоть 3 системы. Главное тут - как это организовать, а ещё важнее - как поддерживать в работающем состоянии, без отката к хаосу.

6. Ну и под конец следует вывод, ради которого можно было и не читать всю статью, а проскроллить вниз, ибо истину говорит:

often its the practices and workflows that make a bigger difference

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

В целом, вся статья - много слов о простых истинах и собственных домыслах.

Сухой остаток: ничего нового; читать рекомендую только ценителям истинного SCM (при наличии иммунитета), евангелистам DVCS и фанатам Фаулера.

О важности CM

2010-02-04T15:58:00.000-08:00

На проводе Stephen Nuchia, Founder at J-BIRD Search and Rescue:

A childhood friend of mine was killed fighting a fire in 2001 and I just recently read the official report on his death. Poor CM turns our to have been one of the three mistakes that killed him. The maintenance procedures being used for his breathing apparatus didn't match the model of equipment issued. Does CM matter? It does to me.

via LinkedIn

Статья про слияние изменений (merge)

2010-02-03T20:15:00.000-08:00

Набрёл сегодня на небольшую статью под названием "Who’s afraid of the big bad merge?" ("Кто боится большого и страшного Мёржа?") Речь идет о слиянии (merge) исходников между ветками по время параллельной разработки.

Из вступления:
In this post I will take a look at some of the issues that arise from managing parallel development and, perhaps more importantly, provide some guidance on how to avoid the pitfalls of parallel development.
что означает примерно следующее: "О некоторых проблемах параллельной разработки и о том, как с ними бороться."

Картинка для привлечения внимания:

Итак, Часть 1 , часть 2. После каждой части - подзаголовок Mitigation, именно там показывается, как можно смягчить показаные проблемы.

Советы толковые. Во время работы в Мотороле приходилось сталкиваться почти со всеми описанными случаями. Но поставленный процесс и супер-инструмент IBM Rational Clearcase сводили на нет все попытки Полярного Зверька забороть нас.

via CMCrossroads

И снова о RSDN Magazine #3

2010-01-31T04:25:00.000-08:00

Пару слов в продолжение записи о RSDN Magazine #3.
Статью разместили в онлайне:
http://www.rsdn.ru/article/Methodologies/CM_basics_part2.xml

Причем там присутствует фрагмент с развернутым примером про отращивание веток и их слияние.

Приятного чтения.

P.S. Вот обложка, кстати. Увидите - берите два ;)

RSDN Magazine #3 2009

2010-01-16T01:02:00.000-08:00

В свет вышел RSDN Magazine за номером 3, год выпуска - 2009.
При чем здесь записки СМщика? Там опубликовано продолжение (оно же завершение) первой статьи об основах СМ. К сожалению, статью урезали, чтобы уложить в объем журнала. Остался за бортом развернутый пример с отращиванием веток и рисованием стрелочек слияния. Кому интересно - он есть в статье про контроль версий.

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

P.S. Теперь я писатель-рецидивист.

DVCS // Пример CM-политики с использованием git

2009-11-22T18:06:00.000-08:00

Через известный ресурс набрёл на описание политики управления конфигурацией в рамках проекта с использованием git.

Собственно, сама заметка.

При всём моём неприятии git и распределенной модели... :) Раз уж их используете - то хоть используйте правильно и эффективно, как показано в заметке.

P.S. Ну и набор ссылок по теме:
http://scm-notes.blogspot.com/2009/11/ms-tfs-branching-guidance.html - о ветвлении и работе с контролем версий в Team Foundation Server
http://scm-notes.blogspot.com/2009/10/software-configuration-management-6.html - о распределенных системах контроля версий
http://www.cmcrossroads.com/bradapp/acme/branching/ - всеобъемлющая статья из серий "basics" и одновременно "essentials" на уважаемом ресурсе.
http://www.infoq.com/articles/agile-version-control - о контроле версий в стиле agile.

Gource // визуализация контроля версий

2009-11-19T23:03:00.000-08:00

Проект дня — Gource.

Берёт на вход логи проекта из git, а также SVN, CVS, Mercurial (после конвертации) и растит в реальном времени дерево — как развивался проект, как появлялись элементы, и их версии.

Одно из видео проекта. Там их несколько.

Enjoy.

MS TFS // Branching Guidance

2009-11-06T05:42:00.000-08:00

Набрёл на неплохой текст от команды Microsoft Team Foundation Server: Branching Guidance
Будущим и нынешним пользователям обозначенной системы предлагается:

проникнуться важностью ветвления и слияния изменений для работы больших команд;
узнать, какие типы веток бывают и как строить изоляцию работы на их основе;
посмотреть на практических примерах как надо правильно отращивать и мёржить изменения.

Интересен неожиданный термин isolation, обозначающий отделение некоторого потока работ при помощи выбранной техники ветвления. Причем оно отделено от понятия changeset. За подробностями - в статью, по контексту будет понятно, о чём я. В целом же - повторение уже описанных истин о контроле версий :).

Лишний раз утвердился во мнении, что MS знает толк в методологии разработки софта :) потому как не просто дает инструмент для грамотного СМа, но ещё и объясняет - зачем подобные инструменты вообще нужны.

Вот тут - одностраничная HTML-версия.

eTraxis // Теперь в линейке 2.x

2009-10-19T17:25:00.000-07:00

Некоторое время назад я участвовал в разработке open source проекта eTraxis — системы отслеживания ошибок, а точнее — системы отслеживания запросов на изменения. Если вдруг кто до сих пор не знает, что это за класс систем — читайте мою статью про системы отслеживания запросов на изменения из цикла материалов по Software Configuration Management.

Система эта предоставляет веб-ориентированный интерфейс — что, в общем-то, уже почти стандарт. Серверная часть традиционна — PHP + Apache, а вот парк СУБД даст фору многим подобным системам: помимо традиционного же MySQL поддерживаются PostgreSQL, MSSQL и Oracle.
Из базовых фич:

гибкая настройка жизненного цикла записей (ошибок, фич, любых запросов) — настраивается без преувеличения всё в жизненном цикле;
управление правами групп — вплоть до отдельного поля; также есть авторизация через LDAP;
зависимости между записями;
сохранение полной истории работы с записями — запоминается любое изменение в любом поле;
большое количество локализаций;
нотификации/подписки/напоминания;

Есть много других фич, полный список можно найти на сайте.

Система постоянно развивается уже несколько лет. Насколько известно, установлена в нескольких десятках организаций — от Приморской краевой администрации до инсталяций в Штатах (я сам использовал в одном из подразделений Моторолы) и Европе (взгляните на список локализаций ;) ). Кстати, не так давно один из энтузиастов добавил его в список кандидатов в репозиторий ArchLinux.

Не так давно система перешла на новый виток развития — что было отмечено переходом нумерации в диапазон 2.х. Что же так изменилось? Прежде всего, это коренные изменения в поддержке Юникода в MSSQL. Переписано то, что касается работы этой СУБД с UTF — до этого приходилось делать довольно немало костылей, чтобы заставить работать базу, где есть только UCS и нет даже намека на поддержку универсальной кодировки. Так же надо отметить прекращение поддержки PHP версии ниже 5.1 и MySQL версий ниже 5.0. Всё это позволило переписать, упростить и улучшить код — и, конечно, улучшить его работу.

Теперь для разработчика, решившего модифицировать систему, станет ещё проще внести нужные изменения. А для администратора уже некоторое время существует целое руководство. Для него же, как и для потенциального пользователя, есть и демо-версия на базе XAMPP.

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

SCM // 6. Распределенный контроль версий

2009-10-19T17:19:00.000-07:00

Сегодня речь пойдет о довольно спорном и в чём-то провокационном вопросе — распределенных системах контроля версий.

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

Так вот, в какой-то момент возникает необходимость сделать доступным центральное хранилище локально в одном из центров разработки – для ускорения работы и обхода ограничений по трафику или пропускной способности. Скажем, есть две команды, расположенные территориально в разных местах и часовых поясах – скажем, Дальний Восток России и Центральная временная зона США, их разделяет полмира. Работа идет над одним проектом, и есть необходимость менять одни и те же части продукта. Предположим, что сервер системы контроля версий стоит в США – соответственно, разработчикам в России для создания каждой новой версии приходится отправлять изменения через половину земного шара. Да и любая операция вроде перехода на другую ветку со взятием целиком всей выбранной конфигурации, будет отнимать слишком много времени, учитывая величину пинга. В общем, в подобных ситуациях централизованное хранилище – не самый удобный вариант.

Поскольку проблема не нова и актуальна, со временем были сформулированы разные подходы к решению задачи. А точнее – два подхода к построению распределенных систем контроля.

Открытое распределение – это принцип построения, при котором каждая рабочая копия конфигурации может иметь свой набор дочерних версий и обмен созданными версиями происходит по выбору создателя изменений.

Плюсом подобных систем является то, что работа на отдельной рабочей станции может идти независимо от других экземпляров хранилища. Собственно, хранилища может и не быть – сколько копий, столько и хранилищ. Не удивительно, что подобные системы нашли применение в первую очередь в Open Source. Отсутствие необходимости содержать отдельный сервер дает возможность обмениваться только той информацией, которая нужна, и не перегружать хранилище и трафик той дельтой, которая может кому-то никогда так и не понадобиться.
Минус подобного подхода в том, что обмен дельтой рабочих продуктов плохо поддается централизованному контролю. Получается некоторое броуновское движение дельты, которое многим менеджерам, привыкшим к централизации, может быть не по душе.
Примерами подобных систем могут быть BitKeeper, git, Mercurial (Hg).

Распределение путём репликации предусматривает создание равноценных копий центрального хранилища данных (или его частей) на всех распределенных серверах. Здесь можно провести аналогию с базами данных и их репликацией. Для каждого разработчика хранилище версий, к которому он подключается, является основным. Все версии и ветки создаются в центральном хранилище или реплике. Для распределения данных делается копия хранилища на другие имеющиеся сервера и часть разработчиков переключается на сделанную копию. При необходимости обмена результатами работы, происходит репликация хранилища – оба сервера обмениваются метаинформацией.

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

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

Оба типа (открытый и репликационный) схожи между собой — в обоих случаях происходит обмен информацией между разными копиями одного множества элементов и их версий. Разница между ними – в «масштабах». В системах с репликацией минимальной единицей реплики, как правило, является репозиторий или его значимая часть, обрабатываемая как единое целое. В системах с открытым распределением минимальная единица обмена информацией – это отдельная версия отдельного элемента.
Для обоих типов распределения характерна общая проблема. Это необходимость введения четкого соглашения об именовании элементов и их веток, а также меток для обозначения полученных конфигураций. При соединении результатов работы не должны получаться разные файлы с одним и тем же именем и метаинформацией (ветками, метками, атрибутами). Поэтому все разработчики и команды, работающие отдельно друг от друга, должны придерживаться общих стандартов. В разных системах бывают предусмотрены механизмы для обеспечения этого условия. К примеру, при работе с ClearCase создаются триггеры на создание любой метаинформации, проверяющие её на соответствие стандарту – для всех создаваемых веток ставится необходимым наличие в имени ветки кода (или идентификатора) того сайта (команды), в котором ветка была создана.

Кроме того, системы с открытым распределением фактически оставляют на усмотрение каждого отдельного разработчика – что он отдаст команде в виде дельты, а что не станет выставлять на общее обозрение. Плохо это или хорошо – зависит от культуры, принятой в рамках проекта. Для более централизованных систем, с репликацией репозитариев, эта проблема видится под другим углом. Когда все обязаны вносить свои изменения в центральную (для своей команды) систему контроля версий, база метаинформации быстро разрастается в размерах – что сказывается как на стоимости хранения, так и на скорости репликации разнесенных в пространстве баз.

Какой из подходов лучше, конечно, нельзя сказать сразу и для всех проектов. Приспосабливать для работы броуновское движение git'а или остановиться на более стабильном состоянии – решать менеджменту каждого проекта. Единого решения для всех команд и проектов нет и быть не может. Кому интересно посмотреть на различия разных систем и моделей – см. ссылку [1].

Кстати, распределенными могут быть не только системы контроля версий, но и системы отслеживания запросов на изменение. Логика работы совершенно аналогична. Вот только основная модель работы – репликационная. Пример – IBM Rational ClearDDTS. Поскольку подобные системы не очень распространены, останавливаться на них подробно не будем.

По традиции, использованные и рекомендуемые для самостоятельного изучения источники:

en.wikipedia.org/wiki/Comparison_of_revision_control_software — сравнение систем контроля версий;
lib.custis.ru/index.php/The_Risks_of_Distributed_Version_Control — трезвый взгляд на риски, связанные с распределенными системами контроля версий;

Порекомендую ещё одну статью о проблемах внедрения разных систем контроля версий:
lib.custis.ru/index.php/Version_Control_and_%E2%80%9Cthe_80%25%E2%80%9D
Немного провокационная, однако стоит прочитать в первую очередь тем, кто относит себя к прогрессивной части программерского сообщества.
И, заранее отвечая на вопрос: нет, я не фанат ни SVN, ни git.

P.S. На отдельной странице собраны ссылки на статьи по основам контроля версий и вообще управлению конфигурациями.

Публикация в RSDN Magazine

2009-10-01T00:01:00.000-07:00

Вышел в свет RSDN Magazine #2 2009 - именно в нём опубликована первая часть статьи Основы "Software Configuration Management". Первые 2 заметки из цикла "SCM", опубликованные ранее, на 95% состоят из материалов именно этой статьи.

Кстати, на обложке, если приглядеться, можно увидеть мою фамилию и название статьи :)

Статья также опубликована на сайте.

P.S. RSDN Magazine #2'2009, К-Пресс, стр. 15-21, ISSN 0234-6621

SCM // 5. Метрики и документация

2009-09-22T19:23:00.000-07:00

Сбор метрик

Что важно для менеджера, когда перед его глазами должна развернуться вся картина происходящего в проекте? Конечно, это цифры. Для контроля над ситуацией руководитель должен видеть не только то, что имеется в настоящий момент, но и то, что было ранее. Соответственно, только имея это целостное видение, можно прогнозировать будущее проекта, корректировать сроки – в общем, вести нормальную управленческую деятельность.

При чем здесь CM? При том, что он контролирует изменения. Если учесть, что любой проект — это изменение рабочих продуктов, то через CM проходят все изменения всего проекта. Стало быть, именно средства по управлению конфигурацией ПО могут давать менеджерам видение того, как изменяется проект во времени. Обычно подобное видение выражается в виде чисел.

Какие же числовые показатели (метрики) можно получить из того, что проходит ежедневно через руки CM-инженеров?

В первую очередь, это всё, что касается учета запросов на изменение продукта:

общее количество открытых/закрытых/находящихся в работе запросов;
срезы запросов по каждому участнику – чем именно озадачен каждый, и в каком состоянии работа;
время нахождения запросов в разных состояниях – как среднее, так и по каждому запросу.

С этого начинает любой менеджер проекта — он смотрит кто чем насколько сильно занят. Кто работает, а кто болтом груши околачивает.

Далее, всегда интересна общая информация о коде, как то: количество строк кода продукта и компонентов. Обычно они считаются в CLOC, NCLOC. Интересует всё, что касается вносимых изменений:

размеры дельты (LOC) в каждом релизе;
размеры дельты по отдельно взятым запросам на изменение (если инструментарий позволяет).

Возможны более экзотические варианты запросов, в зависимости от возможностей инструментария и потребностей проекта:

цикломатическая сложность;
занимаемый размер в памяти (RAM, ROM);
изменения занимаемого объема памяти во времени.

Последняя пара метрик интересуют, как правило, те команды, которые работают с системами, имеющими ограничения по ресурсам. К примеру, мне довелось это видеть в Motorola Mobile Devices Software. Объем памяти всегда критичен для сотовых телефонов, особенно когда речь идет о новых чипсетах и архитектурах. А СМ как раз позволяет собирать эти данные на этапе поготовки резизов.

Кстати, также могут быть интересны отчеты по произведенной работе самих CM-инженеров:

сколько запросов на интеграцию обработали;
сколько релизов сделали;
каково среднее время, затраченное на релиз.

Разумеется, все данные выдаются не только в виде текстовых отчетов, но и в виде самых разных диаграмм – благо, видов их придумали много. Кроме того, по многим показателям можно отследить развитие величин во времени.

Итого: сбор метрик – вещь неотъемлемая от CM в рамках больших проектов. Для мелких проектов сбор метрик упрощается, а то и вообще сводится на нет. Однако, чем больше руководство проекта знает о происходящем на нижнихз уровнях (в коде), тем более эффективно можно построить повседневную работу.

Документирование деятельности CM

Все политики, процедуры и правила, которые устанавливает CM-инженер проекта, должны быть доведены до всех участников проекта. Форма предоставления этой информации не очень важна – главное, чтобы она вообще была предоставлена в срок и была постоянно доступна всем желающим. Как правило, всё, что описывается и формализуется в CM, принято объединять термином «план управления конфигурацией проекта». В англоязычных источниках используется аббревиатура SCMP – Software Configuration Management Plan.

Этот план описывает всё, чем оперирует управление конфигурацией проекта. Сюда входит следующая информация:

Описание всех элементов конфигурации проекта: какие виды, где лежат, кто использует и кто изменяет.
Инструменты, используемых на проекте. Описывается назначение и даются ссылки для скачивания и установки.
Отдельно описывается система отслеживания запросов на изменение: жизненные циклы запросов, группы пользователей, их права, правила использования. Состав групп обычно определяется в самим системах и нет нужды его перечислять в документе.
Описывается порядок работы с системой контроля версий. Какими инструментами пользоваться, где инструкция по установке клиентской части, какие группы пользователей. Отдельно описывается форматы именования веток и меток, это одна из важнейших частей с точки зрения простого разработчика.
Определяются хранилища для релизов и других элементов, не подпадающих под действие системы контроля версий, и описывается порядок работы с ними.
Дается описание процессов стабилизации конфигурации и выпуска базовых релизов – кем инициируется, каковы процедуры применяются, где лежит и кто отвечает за выпуск. Сюда же входит и описание сбора метрик.
Если в рамках проекта разрабатывается несколько компонентов или продуктовых линеек, то описывается процедуры, специфичные для их CM-деятельности.

SCMP может быть оформлен и как отдельный документ, и как серия публикаций в используемой системе документооборота команды разработчиков – например, в Wiki. Главное – чтобы информация была полной, своевременной и доступной для конечного потребителя.

Вместо заключения

Выше были рассмотрены формальные стороны SCM — метрики и документация. Надеюсь, кому-то это даст повод задуматься и, возможно, сделать какие-то движения в нужную сторону.

Приведенная инфа взята из 1) жизни и личного опыта 2) стандарта SEI CMM/CMMI

Продолжение следует.