Атака на книжную полку продолжается. На этот раз под раздачу попала ещё одна книжку из числа тех, что выбрал себе для детального ознакомления. Называется 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 - внедрение и поддержание политик, тесно связанных с коммитом кода и его (автоматической) проверкой;
- Private workspace - о необходимости выделять разработчику рабочего пространства с теми версиями кода и настройками среды, которые нужны для работы;
- Repository - хранилище, в котором хранятся не только версии кода, но и инструменты, необходимые для работы и создания релизов;
- Private system build - о необходимости дать возможность разработчику отстраивать систему без пересечения с остальными участниками проекта;
- Integration build - интеграционные билды для объединения работы участников;
- Third-party codeline - о том, как организовать версионность сторонних зависимостей;
- Task-level commit - вариация на тему task branch;
- Smoke test - об автоматизированном тестировании при каждом коммите на главную или активную ветку;
- Unit test - одноименной технике;
- Regression test - о необходимости проводить регрессионное тестирование перед сдачей дельты на интеграцию
В оставшихся приложениях даются краткие описания полезных ресурсов по вопросам SCM и основных инструментальных средств (впрочем, тут сведения несколько устарели).
Общий итог - хочется больше шаблонов, однако уже в данном виде это - хороший справочник по правильным техникам, надо брать.
>Active development line - разработка "на транке" с минимальным ветвлением и активной работой;
ОтветитьУдалитьЭто да :)
>Release line - ветвление с целью формирование новых релизов (1 новый релиз = 1 ветка);
Да, для релизов делать ветки, по-моему, вполне хорошо. В связи с этим непонятно, зачем нужны метки.
>Release-prep code line
Ну да. Продукт переводится в стадию Release Candidate путем "отстрела" в новую ветку в branches (наследие проклятого царизма, т.е. subversion). Далее происходит доработка этой ветки и затем продукт выпускается из этой ветки.
Я и говорю - хороший справочник по правильным техникам :)
ОтветитьУдалитьПро метки какие соображения будут ? В смысле - не очень понятно, зачем нужны они.
ОтветитьУдалитьВ некоторых шаблонах упоминается навешивание меток. Кроме того, упомянут, как неописанный (но дана ссылка), шаблон "Named Stable Bases".
ОтветитьУдалитьНе очень понятно.
ОтветитьУдалить>Release line - ветвление с целью формирование новых релизов (1 новый релиз = 1 ветка)
Что еще нужно метить, помимо релизов ? ДопустимЮ пометили. Где эта метка потом используется ?
Ну как где? Вот ты пометил версии элементов релизной меткой RELEASE_1.2 , выложил релиз в обедоступное место, объявил о нём.
ОтветитьУдалитьНу а дальше каждый разработчик, кому надо, идет в систему контроля вресий и говорит - "дай-ка мне всё, что есть по метке RELEASE_1.2" - и поулчает полный срез релиза, от которого можно начинать работу.
Как-то так.
>Вот ты пометил версии элементов релизной меткой RELEASE_1.2
ОтветитьУдалитьЗачем еще и метка, если я уже сделал ветку RELEASE_1.2 ? (ветвление с целью формирование новых релизов)
На ветке может быть несколько версий. Какая из них стабильная? Для этого и нужны метки.
ОтветитьУдалитьQ: Какая из них стабильная?
ОтветитьУдалитьA: Стабильная версия, конечно же, отстрелена в свою собственную ветку.
Следующий вопрос :)
Короч, ветка - это набор версий. Только версия может быть стабильной, ветка быть не может стабильной по определению :)
ОтветитьУдалитьСоответственно, как бы ты не растился, повешение метки - единственный верный способ обозначить стабильность версии.