2010-10-28

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

Добрейшего.

Речь сегодня пойдет о книгах - как российских, так и (преимущественно) зарубежных издательств. Довольно давно озадачился поиском литературы по тематике бложика. Ведь, как известно, нет ничего нового под солнцем, значит и про 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. Ссылки на написанные отзывы см. по тексту.

24 комментария:

  1. Первая книга нашлась в электронном варианте достаточно быстро: http://depositfiles.com/ru/files/4cjxuz3ci

    ОтветитьУдалить
  2. 2Gleb Vinogradov
    Спасибо! Видимо, недавно выложили :) потому как книжка само по себе свежая.

    ОтветитьУдалить
  3. А вот http://continuousdelivery.com/ не смотрел?
    Несколько "именитых" вроде на неё ссылались (вроде фаулер был среди них).

    ОтветитьУдалить
  4. 2Qrilka

    Смотреть - смотрел, но решил оставить на потом.

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

    Во-вторх, Фаулер у меня на особом счету :) я как-то препарировал его статью по СМ, она должна быть среди остальных - не впечатлился. Выяснилось, что его взгляды - следствие увлечения как раз CI. И сейчас у меня как раз на очереди написать небольшой обзорчик его статьи на тему ветвления.

    В общем, спасибо, книжку эту себе положил в список на чтение.

    Кстати, в комментариях бывает Maxim.Ge, который одновременно и сторонник Фаулера, и приверженец CI. Максим, что скажешь про книжку? :)

    ОтветитьУдалить
  5. ну будем ждать темы про CI тогда

    ОтветитьУдалить
  6. >Кстати, в комментариях бывает Maxim.Ge, который одновременно и сторонник Фаулера, и приверженец CI.

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

    У нас есть два разных полюса:
    1) Ветка-на-задачу с отдельным интегратором. Тяжелые проекты, сложные методологии, большие команды или их большое количество, отсутствие покрытия проекта тестами.
    2) Работа на trunk с CI, интегратора нет. Небольшие проекты, простые agile-практики, одна небольшая команда, проект хорошо покрыт тестами.

    Задача SCM в случае конкретного проекта - определить свое положение между этими точками.

    У тебя конкретно в бложике да и вообще в основном в статьях лыко идет в строку 1.

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

    Ясно, что универсального рецепта нет, нужно подбирать по месту.

    >Максим, что скажешь про книжку? :)

    Я пока классику читаю :)
    http://rsdn.ru/article/Methodologies/CM_basics_part1.xml

    ОтветитьУдалить
  7. >Выяснилось, что его взгляды - следствие увлечения как раз CI.

    А не выяснилось ли заодно, что твои взгляды - результат неиспользования практики CI :) ?

    ОтветитьУдалить
  8. Maxim Ge комментирует...
    >У нас есть два разных полюса:
    1) Ветка-на-задачу с отдельным интегратором.

    Я, кстати, так и не понял, как изящно реализовать эту практику в DVCS типа git/mercurial

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

    Такое ощущение, что в экосистеме VCS, как ни странно, есть свободная ниша.
    1) Чтобы слияние
    2) Чтобы работа без подключения
    3) Чтобы удобные ветки в центральном репозитории

    ОтветитьУдалить
  9. А вариант с 2 репами?
    http://m-ivanov.livejournal.com/7988.html
    по идее gitosis вроде можно настроить на подобную работу в рамках 2 репы, но нам показалось явное отделение мух от котлет логичнее. Правда внедрять это дело стали не так давно (да и я на этом месте тоже недавно).

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

    Если внимательно почитать и указанную статью, и последнюю, на которую ссылался про git - там достаточно убрать упоминание git и репликации между личными репо - и будет не отличить от писания практик работы с каким-нибудь SVN.

    Если взять каноническую статью
    http://www.cmcrossroads.com/bradapp/acme/branching/
    то достаточно примерить описанное на git и на SVN, чтобы понять - что разницы по большому счету нет.

    ОтветитьУдалить
  11. > А не выяснилось ли заодно, что твои взгляды - результат неиспользования практики CI :) ?

    Нет, это посттравматический синдром после 3 лет на Мотороловском СМе :))))

    ОтветитьУдалить
  12. >А вариант с 2 репами?
    http://m-ivanov.livejournal.com/7988.html

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

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

    ОтветитьУдалить
  13. И потом, вот такой момент

    http://habreffect.ru/files/a65/0f3b26572/ms.png

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

    Картина маслом - я сливаю 179 веток по шести репозиториям ( 3 * 2 ). Не вдохновляет, честно скажу. Ни на переход на git, ни на форсирование практики ветка-на-задачу с последующим интегрированием.

    ОтветитьУдалить
  14. Т.е. тебе эти 179 задач сдают махом в 1 и тот же момент времени?
    Это какие-то автоматизированые гиперразработчики?
    Чтот мне не верится, что задачи у вас десятками в день закрываются, если так, то это какой-то микроменеджмент.
    С другой стороны понятное дело, что при наличии интегратора, на него ложится доп. нагрузка, вопрос в оправданности этой доп. стадии проверки через интеграцию.
    При наличии достаточно квалифицированных кадров эффективней всё прямо в trunk складывать.

    ОтветитьУдалить
  15. Я как непосредственный реализатор схемы (с Qrilka), то могу сделать пока следующие выводы:

    1. gitosis - знатная штука, особенно с патчем: http://github.com/mzupan/gitosis
    2. репы не всегда нужно две:
    2.1 может быть одна репа и только один человек может в нее писать - интегратор. подходит для мелких утилиток (т.к. у нас dcsv, то достаточно просто прислать патч)
    2.2 может быть одна общая dev репа для нескольких проектов с чисткой репы раз в месяц/год/столетие от мусора (проекты правда должны быть не очень большие). (опять же фича гита с remote позволяющая подцеплять в виде remote что угодно и куда угодно и это merge делать)

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

    ОтветитьУдалить
  16. > Хотя конечно в случае квалифицированной команды это 5-е колесо не нужно.

    Не согласен :) Как минимум в двух вариантах 5-колесо становится полноценной третьей осью подвеске :) и влечет появление 6-го колеса и увеличивает проходимость и грузоподьёмность :)

    1) Поток изменений от команды настолько велик, что даже квалификация всей команды не позволяет справиться с ним.

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

    Посоветую статьЮ, на которую тут уже Максим дал ссылку:
    http://rsdn.ru/article/Methodologies/CM_basics_part1.xml
    почитайте части, где рассказывается про baselining и компонентную разработку. Тут как раз оно, только картинки похуже :)
    http://scm-notes.blogspot.com/2009/09/software-configuration-management_06.html

    ОтветитьУдалить
  17. 2Aquary
    а я вот не соглашусь с твоим неоглашением, правда исходя из своего коммента - я говорил о "достаточной квалификации" (и octo47 тоже её подразумевал, видимо), в твоих же вариантах выходит, что квалификации получается недостаточно (которой может быть и по сути "физически" недостаточно в варианте с сильно большим проектом), в итоге не получаем мы "ситуацию с 5-м колесом".

    ОтветитьУдалить
  18. Qrilka комментирует...
    >Т.е. тебе эти 179 задач сдают махом в 1 и тот же момент времени?

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

    >При наличии достаточно квалифицированных кадров эффективней всё прямо в trunk складывать.

    Зачем же такие крайности - где надо, заводится ветка на задачу. Однако смысл CI в том, чтобы как можно чаще сбрасывать в trunk, и тут интегратор отпадает, команда должна самоорганизоваться, что и, собссвенно, и требуется по методологии Scrum.

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


    Aquary комментирует...
    >2) расширяем вариант 1 и получаем: над проектом работает несколько команд - тут уже даже мегапрофи не могут срастить что к чему и требуется сторонняя сила в виде интеграционной команды, которая бы привела к общему знаменателю всю работу.

    Именно

    ОтветитьУдалить
  19. Кстати, чтоб не держать под подушкой, вот остальные книги, не вошедшие по разным причинам в шортлист.

    Anti-Patterns and Patterns in Software Configuration Management by William J. Brown, Hays W. McCormick, Scott W. Thomas

    Templates for Software Configuration Management by John M. Neorr

    Transparent CM: How to Get There (Configuration Management) by David Lyon

    Transparent CM: How to Get There (Volume 1) by David Douglas Lyon

    Configuration Management by Dr. Gary L. Vincent Ph.D.

    The Configuration Management Templates Sourcebook by Gerard Blokdijk

    The Build Master: Microsoft's Software Configuration Management Best Practices by Vincent Maraia

    Practical CM III: Best Configuration Management Practices for the 21st Century by Mr. David Douglas Lyon

    Configuration Management Principles and Practice by Anne Mette Jonassen Hass

    Configuration Management: Implementation, Principles, and Applications for Manufacturing Industries by Joseph Sorrentino

    Real World Software Configuration Management by Sean Kenefick

    Software Configuration Management: A Clear Case for IBM Rational Clearcase And Clearquest Ucm by IBM Redbooks

    Configuration Management Best Practices - Templates, Documents and Examples of Configuration Management in the Public Domain by Jonas Beach

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

    ОтветитьУдалить
  21. Ранжировать особо не получится - книжки целиком не читал, отсев производится по
    1) содержанию, где его удавалось просмотреть
    2) содержимому, где, опять же, удавалось проглядеть
    3) числу упоминаний на СМ-Перекрестках
    4) отзывам на Амазоне
    5) цене, т.е. я собирался себе их купить

    Из первоначального списка только 4 книги подошли по всем критериям. Три - как раз упомянуты в статье, оставшаяся одна - это первая из большого списка, "Anti-Patterns and Patterns in Software Configuration Management". Её не стал брать просто потому, что старая, а так отзывы по ней самые положительные. Оставшиеся позиции в списке не подошли по 3 или 4 пунктам сразу - увы, их пришлось выбрасывать.
    Есть какая-то книжка из списка, не подошедшая сразу по 5 пунктам - стоила под сотню баксов, но никаких подробностей про неё вообще не смог разузнать.

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

    ОтветитьУдалить
  22. Если уж "за книжки" речь пошла, то ты не думал использовать что-нибудь аля shelfari?
    (если что, моя страница - http://www.shelfari.com/qrilka )

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

    ОтветитьУдалить