Привет. Как и было обещано, это продолжение серии заметок об управлении конфигурацией программного обеспечения, обычно называемой «Управление конфигурацией программного обеспечения».
Весь цикл можно найти по ссылке на тег CM .
Осталось буквально пару заметок, которые еще не освещены.
Сегодня мы поговорим о довольно спорном и в некоторой степени провокационном вопросе — распределенных системах контроля версий.
Знаю, что такие системы популярны среди жителей Хабры, поэтому заранее готов к обсуждению.
Более того, я призываю вас не проходить мимо и высказываться, если вам есть что сказать по делу.
Итак, есть проект и в нем есть система контроля версий, которая обслуживает несколько команд, реализующих этот проект. Система контроля версий одна для всех.
Напомню, что я продолжаю серию заметок, и ранее говорил о контроле версий в целом, минуя конкретные реализации.
Таким образом, предметная область также постепенно развивается от простого к сложному.
Итак, в какой-то момент возникает необходимость сделать центральное хранилище доступным локально в одном из центров разработки — для ускорения работы и обхода ограничений трафика или пропускной способности.
Допустим, есть две команды, расположенные географически в разных местах и часовых поясах — скажем, на Дальнем Востоке России и в центральном часовом поясе США, на расстоянии половины мира друг от друга.
Мы работаем над одним проектом, и возникает необходимость изменить одни и те же части продукта.
Предположим, что сервер системы контроля версий находится в США — соответственно, разработчикам в России для создания каждой новой версии приходится отправлять изменения через полмира.
А любая операция вроде перехода на другую ветку и взятия всей выбранной конфигурации будет занимать слишком много времени, учитывая размер пинга.
В общем, в таких ситуациях централизованное хранилище — не самый удобный вариант. Поскольку проблема не нова и актуальна, с течением времени были сформулированы разные подходы к ее решению.
Точнее, два подхода к построению распределенных систем управления.
Открытое распространение — принцип построения, при котором каждая рабочая копия конфигурации может иметь свой набор дочерних версий и обмен созданными версиями происходит по выбору создателя изменений.
Преимущество таких систем в том, что работа на отдельной рабочей станции может проходить независимо от других экземпляров СХД.
На самом деле репозитория может и не быть — столько копий, сколько репозиториев.
Неудивительно, что такие системы нашли применение прежде всего в Open Source. Отсутствие необходимости содержать отдельный сервер дает возможность обмениваться только той информацией, которая нужна, и не перегружать хранилище и трафик той дельтой, которая может кому-то никогда не понадобиться.
Недостатком этого подхода является то, что обмен дельта-продуктами работы трудно централизовать.
В результате возникает своего рода броуновское движение дельты, которое может не нравиться многим менеджерам, привыкшим к централизации.
Примеры таких систем включают BitKeeper, git, Mercurial (Hg).
Распространение путем репликации предусматривает создание равнозначных копий центрального хранилища данных (или его частей) на всех распределенных серверах.
Здесь можно провести аналогию с базами данных и их репликацией.
Для каждого разработчика репозиторий версий, к которому он подключается, является основным.
Все версии и ветки создаются в центральном репозитории или реплике.
Для распространения данных делается копия хранилища на другие существующие серверы и некоторые разработчики переходят на сделанную копию.
При необходимости обмена результатами работы происходит репликация хранилища — оба сервера обмениваются метаинформацией.
Преимущество такого подхода — централизация работы в пределах одной бригады.
Также стоит добавить, что можно сохранить часть накопленной информации от синхронизации с другими командами, но при этом сделать ее доступной одновременно для всей локальной команды.
Это может быть важно, когда код разрабатываемых подсистем не должен быть доступен общественности, даже другим командам, работающим над тем же продуктом.
Минусом является необходимость настройки механизмов репликации.
Но, как правило, системы, использующие такой подход, предоставляют инструменты для эффективного обмена данными.
Кроме того, для некоторых минусом может стать тот факт, что все операции с версиями производятся на одном сервере, а не на локальном компьютере разработчика.
То есть «распределенность» системы проявляется на уровне команд и их локаций, а не на уровне простого разработчика.
Примерами систем с репликацией являются ClearCase и Perforce. Оба типа (открытый и репликационный) похожи друг на друга — в обоих случаях происходит обмен информацией между разными копиями одного набора элементов и их версиями.
Разница между ними в «масштабе».
В системах с репликацией минимальной единицей реплики обычно является репозиторий или его значительная часть, обрабатываемая целиком.
В открытых системах распространения минимальной единицей обмена информацией является одна версия одного элемента.
Оба типа распространения имеют общую проблему.
Это необходимость введения четкого соглашения об именовании элементов и их ветвей, а также меток для обозначения получаемых конфигураций.
При объединении результатов работы не следует получать разные файлы с одинаковым именем и метаинформацией (ветвями, метками, атрибутами).
Поэтому все разработчики и команды, работающие отдельно друг от друга, должны придерживаться единых стандартов.
В разных системах предусмотрены механизмы обеспечения этого условия.
Например, при работе с ClearCase создаются триггеры для создания какой-либо метаинформации, проверки ее на соответствие стандарту — для всех создаваемых веток необходимо включать в название ветки код (или идентификатор) сайта (команды), в котором создана ветка.
Кроме того, системы с открытой дистрибуцией фактически оставляют на усмотрение каждого отдельного разработчика — что он отдаст команде в виде дельты, а что не выложит на всеобщее обозрение.
Хорошо это или плохо, зависит от культуры, принятой в рамках проекта.
Для более централизованных систем с репликацией репозитория эта проблема видится под другим углом.
Когда от каждого требуется вносить свои изменения в центральную (для своей команды) систему контроля версий, база метаинформации быстро увеличивается в размерах — что влияет как на стоимость хранения, так и на скорость репликации баз данных, распределенных по пространству.
Какой подход лучше, конечно, нельзя сказать сразу и для всех проектов.
Руководство каждого проекта должно решить, адаптировать ли броуновское движение git для работы или остановиться на более стабильном состоянии.
Единого решения для всех команд и проектов нет и не может быть.
Кому интересно посмотреть на различия между разными системами и моделями, смотрите ссылку [1].
Кстати, распространяться могут не только системы контроля версий, но и системы отслеживания запросов на изменения.
Логика работы полностью аналогична.
Но основная модель работы – репликация.
Примером является IBM Rational ClearDDTS. Поскольку такие системы не очень распространены, мы не будем на них подробно останавливаться.
Традиционно используемые и рекомендуемые для самостоятельного изучения источники:
- en.wikipedia.org/wiki/Comparison_of_revision_control_software — сравнение систем контроля версий;
- lib.custis.ru/index.php/The_Risks_of_Distributed_Version_Control — трезвый взгляд на риски, связанные с распределенными системами контроля версий;
И чтобы сразу ответить на вопрос: нет, я не фанат ни SVN, ни git. Это все на сегодня.
Не пройдем мимо, мы высказываемся.
Интересно услышать мнение людей, которые использовали Perforce. Любителям git/Hg/etc — интересно услышать о неочевидных проблемах, возникающих при обмене дельтами (они должны быть, ничего не бывает гладко и идеально).
Если кто-нибудь делал репликацию репозиториев в SVN или даже CVS, сообщите, будем благодарны.
Ну, продолжение следует. Теги: #программное обеспечение #Конфигурация #управление #scm #cm #Конфигурация #распределенный #контроль #версия #контроль версий #git #Mercurial #bitkeeper #ClearCase #Perforce #Project Management
-
Выбор Темы Для Создания Своего Блога
19 Oct, 24 -
Ларомигьер, Пьер
19 Oct, 24 -
Рит++, Фото Третьего Дня
19 Oct, 24 -
Эмюль На Android
19 Oct, 24 -
Плагин Для Расширения Коротких Ссылок
19 Oct, 24 -
Тематические Почтовые Ящики
19 Oct, 24 -
Мегатонны Макулатуры Одним Движением Руки
19 Oct, 24
