Delphi 5: Система контроля версий TeamSource

Delphi 5: Система контроля версий TeamSource

Никита Попов
Статья была опубликована на сайте http://nixx.chat.ru/

Еще три-четыре года тому назад термин "система контроля версий проекта" лично в моем сознании ассоциировался с крупными фирмами-производителями программного обеспечения, группами из десятков программистов и миллионами строк исходного кода и даже постепенное вхождение в обиход термина RAD (Rapid Application Development, быстрая разработка приложений) практически не влияло на такую ассоциативную связь, поскольку становление таких средств RAD, как Delphi, а затем С++ Builder и JBuilder только начиналось и практически никто из сегодняшних разработчиков, создавших к настоящему моменту огромное число приложений различной степени сложности, состоящих из тех самых миллионов строк исходного кода, еще не представлял себе тех проблем, которые наряду с неоспоримыми преимуществами привнесли в разработку программного обеспечения RAD-инструменты. Одной из таких проблем стал стремительный рост числа не только модулей исходного кода, но и полноценных проектов, поддерживаемых зачастую одним единственным разработчиком. Средства RAD позволили осуществлять практически полный цикл разработки программного обеспечения значительном меньшими группами людей, нежели это было раньше, значительно повысив производительность как отдельных разработчиков, так и рабочих групп, занятых на том или ином проекте. Рост производительности разработчиков, имевший взрывной характер, что было обусловлено значительным снижением времени, затрачиваемого как на обучение работе со RAD-инструментом, так и на выполнение собственно поставленных перед разработчиком задач, быстро привел к достаточно закономерной перегрузке проектами, исходным кодом и документацией отдельных разработчиков и их групп, заставив многих пересмотреть свои подходы к организации процесса создания программного обеспечения.

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

За короткое время системы контроля версий проектов (Project Version Control Systems, PVCS, не путать с торговой маркой Intersolv PVCS компании Merant) вышли из относительно узкой ниши крупных компаний-производителей программного обеспечения как за счет снижения сложности в использовании, так и за счет значительного (на порядки) снижения стоимости подобных систем и значительного расширения выбора среди классов и продуктов данной категории. Однако до недавнего времени большинство производителей PVCS по инерции ориентировались на крупные компании-производители ПО, или же старались использовать уже имеющиеся наработки, что зачастую приводило к оголению отдельных секторов рынка подобных систем. Живым примером тому может служить практически полное отсутствие до недавнего времени PVCS-продуктов, поддерживающих Delphi и язык Object Pascal (очевидно за счет того, что большинство проектов, использовавших различные PVCS, ранее велось на языке C/C++, а в США еще и на COBOL и ему подобных). Мои личные изыскания на этом фронте велись практически с начала работы с Delphi (1995 год), однако первые, действительно годные к использованию в проектах как одним человеком, так и группой разработчиков, продукты стали появляться лишь где-то в 1997/98 годах (я не имею в виду Lite-версию Intersolv PVCS, встроенную в Delphi 3 Professional и C/S edition, поскольку эта версия являлась скорее переходным средством к "полноценной" версии Intersolv PVCS). Ориентированные же на Delphi системы, обладающие возможностью подключения в виде расширений и экспертов к среде разработки (IDE) Delphi и C++ Builder, полностью использующие возможности Open Tools API, появились лишь в конце 1998 — начале 1999 года (например FreeVCS, система контроля версий проектов для Delphi 4, разработанная Томасом Хенсле (Thomas Hensle, http://www.thensle.de/index.htm). Поэтому на фоне некоторой неразберихи с продуктами PVCS заметным событием стало появление в составе Delphi5 системы контроля версий проектов, разработанной, а главное, используемой, инженерами Borland в их собственных проектах.

Наверное, я не погрешу против истины утверждая, что продукт, созданный разработчиками для разработчиков скорее всего будет обладать теми самыми возможностями, содержать какие-то "изюминки", которых Вам как раз-таки не хватало все то время, пока в нашем с вами распоряжении не появился этот замечательный во всех смыслах продукт: Borland TeamSource.

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

Системой контроля версий проектов (Project Version Control System, PVCS) называется комплекс программного обеспечения, назначением которого является централизованное хранение и обработка всех или большей части объектов (файлов), из которых состоит проект некоего программного продукта.

Под проектом понимается вся совокупность файлов исходных текстов различных языков программирования, ресурсных и других файлов, необходимых для сборки программного продукта (одного или более исполняемых файлов, библиотек DLL и так далее). Часто к вышеперечисленному добавляются исходные тексты файлов справки (Help files), сценарии программ инсталляции, а также сопроводительная документация проекта и так далее.

Хранение составляющих проекта осуществляется таким образом, чтобы обеспечить доступ к любой из зафиксированных версий проекта.

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

Контроль версий проекта является основной задачей PVCS. В общем виде схема работы PVCS выглядит следующим образом:

Общий вид схемы контроля версий проекта с использованием PVCS.

Основными процессами в эксплуатации PVCS являются:

При этом могут использоваться такие сервисные функции, как:

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

В качестве хранилища составляющих проектов различные системы PVCS используют множество технологических решений начиная с файлово-каталожной схемы на выделенном носителе и заканчивая специальными базами данных на платформе тех или иных СУБД. Некоторые PVCS позволяют использовать несколько способов хранения одновременно, используя, например, СУБД для хранения оперативных копий текущей (находящейся в разработке и отладке) версии проекта, а накопитель на магнитной ленте типа DAT — для резервирования и хранения более ранних, уже законченных версий.

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

Итак, мы рассмотрели основные понятия и этапы использования PVCS при разработке программных проектов. Замечу, что во многих случаях PVCS вполне возможно использовать не только для контроля версий программных проектов и их составляющих, но и для контроля версий как различных сопроводительных документов к этим проектам, так и не связанных с ними напрямую файлов, например документов службы технической поддержки, поскольку в большинстве PVCS имеется возможность определения пользовательских типов файлов для помещения в хранилище. Поэтому сфера применения PVCS отнюдь не ограничивается только лишь разработкой программного обеспечения, однако это направление является наиболее важным и все системы PVCS ориентированы в первую очередь на работу с исходными текстами на различных языках программирования, бинарными файлами ресурсов и другими типами файлов, для которых заранее известна их структура и могут быть предусмотрены различные стандартные схемы обработки, например помещение идентификатора версии в текстовый (ASCII) файл с исходным кодом на языке программирования для визуального контроля.

Рассмотрим следующий пример: разработчик A1 из проекта A занимается разработкой внутренней библиотеки A_Library.pas совместно с разработчиком A2. A1 получает копию A_Library.pas и в течении одной рабочей недели занимается реализацией некоторой достаточно объемной части исходного кода внутри этой библиотеки. В некий момент времени, когда разработчик A1 занят своей частью работы, разработчик A2 получает свою копию A_Library.pas с целью внести изменения в свою часть библиотеки. Закончив работу, он передает новую версию на вход PVCS, однако разработчик A1 еще не закончил свою часть изменений в библиотеке. В результате возникает конфликт, поскольку как изменения, внесенные разработчиком A2, так и A1 равно важны для проекта. Разрешить конфликт в данном случае можно было бы добавлением исходного кода, созданного разработчиком A1 в версию модуля от A2 или наоборот, однако в реальной жизни этот вариант по понятным причинам оказывается нежизнеспособен.

Для предотвращения подобных ситуаций применяется нескольких схем разрешения конфликтов, а именно:

В о многих PVCS имеется возможность применения более одной из перечисленных схем в зависимости от настройки и типа того или иного компонента проекта.

TeamSource — это система контроля версий проектов (PVCS), предназначенная для управления версиями проектов, разрабатываемых с использованием Borland Delphi и Borland C++ Builder. TeamSource была изначально разработана для сопровождения проектов на Delphi и C++ Builder, в связи с чем не несет "тяжкого груза наследственности" PVCS исключительно для работы с C/C++, характерного для многих других PVCS. Более того, в силу характерного для всех инструментов, создаваемых в компании Inprise, гибкого подхода к решению поставленных задач, TeamSource может быть совершенно "прозрачно" использована для хранения и контроля версий файлов, не связанных со средствами разработки, например документов MS Word или любых других. Если же Вы используете в своем проекте помимо средств разработки Borland/Inprise инструменты других фирм или же свои собственные, в TeamSource имеется возможность создания расширений (контроллеров) на основе соответствующих API (Application Programming Interface, прикладных программных интерфейсов), позволяющих обрабатывать такие элементы проектов точно так же, как и предопределенные в поставляемых с TeamSource контроллерах.

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

При работе в группе, TeamSource решает большинство из перечисленных в разделе "Немного теории" задач, включая оповещение (Notification) и разрешение конфликтов (Conflict Resolving).

Базовое хранилище версий TeamSource реализовано по файлово-каталожному принципу, однако существует возможность использовать хранилище и контроллер версий системы Merant PVCS (бывший Intersolv PVCS) за счет подключения специального расширения, поставляемого с TeamSource. Также имеется возможность написания собственного расширения для управления хранилищем версий, например для использования в качестве хранилища базы данных SQL-сервера IB DataBase компании InterBase Software.

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

Продолжение статьи будет опубликовано в течение недели

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Interface Ltd. Тel/Fax: +7(095) 105-0049 (многоканальный) Отправить E-Mail http://www.interface.ru
	Ваши замечания и предложения отправляйте автору По техническим вопросам обращайтесь к вебмастеру Документ опубликован: 09.07.01