2011-01-18

Книги // Software Configuration Management Patterns

Добрейшего.

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

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

10 комментариев:

  1. >Active development line - разработка "на транке" с минимальным ветвлением и активной работой;

    Это да :)

    >Release line - ветвление с целью формирование новых релизов (1 новый релиз = 1 ветка);

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

    >Release-prep code line

    Ну да. Продукт переводится в стадию Release Candidate путем "отстрела" в новую ветку в branches (наследие проклятого царизма, т.е. subversion). Далее происходит доработка этой ветки и затем продукт выпускается из этой ветки.

    ОтветитьУдалить
  2. Я и говорю - хороший справочник по правильным техникам :)

    ОтветитьУдалить
  3. Про метки какие соображения будут ? В смысле - не очень понятно, зачем нужны они.

    ОтветитьУдалить
  4. В некоторых шаблонах упоминается навешивание меток. Кроме того, упомянут, как неописанный (но дана ссылка), шаблон "Named Stable Bases".

    ОтветитьУдалить
  5. Не очень понятно.

    >Release line - ветвление с целью формирование новых релизов (1 новый релиз = 1 ветка)

    Что еще нужно метить, помимо релизов ? ДопустимЮ пометили. Где эта метка потом используется ?

    ОтветитьУдалить
  6. Ну как где? Вот ты пометил версии элементов релизной меткой RELEASE_1.2 , выложил релиз в обедоступное место, объявил о нём.

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

    Как-то так.

    ОтветитьУдалить
  7. >Вот ты пометил версии элементов релизной меткой RELEASE_1.2

    Зачем еще и метка, если я уже сделал ветку RELEASE_1.2 ? (ветвление с целью формирование новых релизов)

    ОтветитьУдалить
  8. На ветке может быть несколько версий. Какая из них стабильная? Для этого и нужны метки.

    ОтветитьУдалить
  9. Q: Какая из них стабильная?

    A: Стабильная версия, конечно же, отстрелена в свою собственную ветку.

    Следующий вопрос :)

    ОтветитьУдалить
  10. Короч, ветка - это набор версий. Только версия может быть стабильной, ветка быть не может стабильной по определению :)

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

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