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

Через известный ресурс набрёл на описание политики управления конфигурацией в рамках проекта с использованием 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 // визуализация контроля версий

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

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

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



Enjoy.

MS TFS // Branching Guidance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбор метрик

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

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

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

SCM // 4. Контроль версий

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

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

SCM // 3. Отслеживание запросов на изменение

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

Отслеживание запросов на изменение

Для начала, как вообще возникают изменения на проекте? Вариантов всего несколько:

SCM // 2. Конфигурации и baselines

Продолжаем серию заметок про SCM. Сегодня речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.

SCM // 1. Введение в управление конфигурацией ПО

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase. В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

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

Начнём

Категорически вас приветствую.

Здесь будут выкладываться материалы о Software Configuration Management. По-русски это называется Управление конфигурацией программных средств. За несколько лет работы CM-инженером накопился некоторый опыт, которым хочется поделиться с теми, кому это может быть интересно. А заодно и самому не забыть :) поскольку профессионально СМ'ом я уже не занимаюсь. Отсюда и название блога - сиэмщик я, увы, отставной, теперь это моё хобби :)

Кому интересны подробности об опыте - читайте мой профиль на LinkedIn.

Материалы также публикуются на Хабре - читайте na zdorovie.