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

Добрейшего.

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

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

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

Добрейшего.

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

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

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

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

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

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

Добрейшего.

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

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

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

Добрейшего.

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

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

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


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

Вышел Plastic SCM Community Edition

Добрейшего.

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

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

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

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

Добрейшего.

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

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

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

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

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

Добрейшего.

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

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

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

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

Добрейшего.

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

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

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

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

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

Добрейшего.

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

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

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

http://goo.gl/AMY6

A successful Git branching model

Добрейшего.

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

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

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

Добрейшего.

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

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

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

Добрейшего.

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

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


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

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

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

Добрейшего.

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

Итак, текст.

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

Добрейшего.

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

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

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

Добрейшего.

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

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

Добрейшего.

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

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

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

Добрейшего.

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

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

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

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

Добрейшего.

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

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

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

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

Добрейшего.

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

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

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

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

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

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

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

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

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

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


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

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

Have fun ;)

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

Добрейшего.

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

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

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

Добрейшего.

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

Windows. A Software Engineering Odyssey

Добрейшего.

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

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

Добрейшего.

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

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

Добрейшего.

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

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

Добрейшего.

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

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

О важности CM

На проводе 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)

Набрёл сегодня на небольшую статью под названием "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

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

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

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

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

RSDN Magazine #3 2009

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

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

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