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

Еще три-четыре года тому назад термин "система контроля версий проекта" лично в моем сознании ассоциировался с крупными фирмами-производителями программного обеспечения, группами из десятков программистов и миллионами строк исходного кода и даже постепенное вхождение в обиход термина 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 для работы с данным проектом: определение участников проекта, задание паролей и прав доступа к тем или иным составляющим (чтение, модификация, удаление и т.д.) и к ко всему проекту, определение перекрестных связей составляющих проекта, определение владельцев тех или иных составляющих.

· Ввод (Check-In) в контроллер версий PVCS модифицированных (или вновь созданных) составляющих проекта для помещения их в центральное хранилище версий с присвоением номера версии составляющей и проекта.

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

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

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

· Оповещение участников проекта об изменениях и действиях над проектом (Notification).

· Создание конфигурации для компиляторов с языков разработки для сборки проекта по его структуре (Configuration building).

· Автоматическая сборка заданной версии проекта (Project building).

· Защита заданной финальной версии проекта от дальнейшей модификации (Version/Project Locking).

· Помещение информации о версии составляющей и проекта (Version Info Embedding) в общий ресурсный файл или прямо в файл элемента проекта для дальнейшего использования при сборке (создание ресурса VERSIONINFO) или же для визуального контроля.

· Автоматическое создание нового идентификатора (Version ID Generation) версии составляющей или всего проекта как в процессе Check-In, так и при автоматической сборке проекта (Project building) или установке идентификатора версии проекта или его составляющей.

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

Хранилище PVCS

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

Блокировка отдельных составляющих и проекта в целом (Version/Project Locking)

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

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

Разрешение конфликтов (Conflict Resolving)

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

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

· Блокировка версии компонента проекта при операции Check-Out до повторного Check-In;

· Блокировка модификации компонента проекта кем-либо кроме ответственного разработчика;

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

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

Что такое система TeamSource

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 изначально является средством групповой разработки, однако может использоваться и в однопользовательском режиме, п