Devrace Athlant: Интегрированные технологии контроля версий в Borland Delphi и Borland C++ Builder

Введение

Современная разработка программного обеспечения практически немыслима без использования различных средств автоматизации и контроля. Мы постараемся рассказать о технологиях, которые позволяют автоматически отслеживать изменения, вносимые в исходный код, чтобы контролировать весь процесс разработки приложения, как индивидуальным разработчиком, так и группой программистов. Также важным вопросом, рассмотренным в данной статье, является проблема интеграции различных систем в среду разработки Borland Delphi и C++ Builder.

Зачем нужен контроль версий?

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

procedure DropDatabase;
function FindTransaction(TR: TFIBTransaction): Integer;
procedure ForceClose;
function IndexOfDBConst(const st: String): Integer; // Get the index
procedure Open; virtual; // 02-04-01 Added virtual
function TestConnected: Boolean;

Рис.1. Фиксирование изменений кода при помощи комментариев.

Само по себе, это очень хорошая практика, поскольку комментарии облегчают последующее сопровождение кода, однако будем честны: многие ли программисты комментируют все свои изменения? Ситуация усугубляется также тем, что иногда код просто удаляется, а как и где поставить комментарий об удалении какого-либо куска программного кода? А теперь представим, что мы хотим посмотреть самые последние изменения в файле. Эта задача становится весьма трудоемкой, если мы будем ориентироваться на комментарии, поскольку нам придется просмотреть все исходные тексты, чтобы найти там соответствующие комментарии, а потом выбрать из них самые поздние! Существует другой вариант частичного решения проблемы. Разработчики архивируют весь проект время от времени, создавая отдельные архивные файлы для каждого билда. После этого, если, например, возникает необходимость выяснить, какие были сделаны изменения в билде номер 24 относительно билда номер 23, то оба соответствующих архива распаковываются и сравниваются при помощи специальных утилит текстового сравнения. Такой подход работает, однако, по сути, он означает, что контроль версий осуществляется "вручную", со всеми вытекающими отсюда последствиями:

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

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

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

Общий принцип работы с системами контроля версий

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

Прежде всего, все подобные системы представляют собой классические приложения client/server’ной архитектуры. Возьмем некоторую абстрактную систему контроля версий (VCS – version control system). Мы можем назвать это также сервером контроля версий, поскольку именно серверное обеспечение занимается контролем и хранением исходных текстов. Любая VCS оперирует базой данных, в которой сохраняются версии всех исходных текстов. Это может быть как сторонняя база данных, так и некоторая внутренняя. Для нас, как для разработчиков, база данных напрямую недоступна – все операции над исходными файлами осуществляются исключительно только посредством вызовов соответствующих команд VCS. Очевидно, что мы можем построить следующие схемы для системы контроля версий:

Рис.2. Схемы построения систем контроля версий

1-й вариант является наиболее сложным. Сервер контроля версий установлен на отдельном компьютере. Таким образом, он может работать под управлением совершенно иной операционной системы, нежели компьютеры разработчиков. База данных также установлена на отдельном компьютере. На компьютерах разработчиков установлено клиентское обеспечение VCS, которое позволяет выполнять команды на сервере.

2-й вариант более прост: сервер контроля версий и база данных установлены на одном компьютере.

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

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

Рассмотрим теперь, как осуществляется работа с системой контроля версий. Посредством соответствующей команды вы создаете в базе данных некоторый проект, в котором будете сохранять ваши исходные файлы. Обычно VCS позволяет работать с неограниченным количеством проектов в одной базе данных. После создания пустого проекта, вы указываете файлы на вашем жестком диске, которые следует поместить в базу данных для последующего контроля. Сразу после копирования этих файлов в базу данных, у локальных копии файлов устанавливается атрибут Read-only. Это предупреждение, что данные файлы теперь нельзя редактировать напрямую, минуя систему контроля версий. Первые необходимые шаги сделаны. Теперь, если программист хочет сделать какие-либо изменения в файле, то он должен запросить этот файл для редактирования у сервера при помощи команды Check Out.

Сервер передает файл из базы данных разработчику и "делает пометку" в базе данных, что файл занят конкретным разработчиком. Эта команда называется "Check Out". После этого разработчик может редактировать файл. После окончания работы, измененный файл необходимо сохранить в базе данных, для чего снова вызывается соответствующая команда – "Check In". Измененный файл сохраняется в базе данных, однако вместе с новой версией в базе данных сохраняются и все предыдущие версии этого же файла. Таким образом, мы всегда можем посмотреть список всех версий любого файла при помощи команды "History", а также сравнить любые две версии файла, вызвав команду "Get difference". Обратите внимание, что если файл уже занят кем-либо из разработчиков и другой программист попробует выполнить команду "Check Out" для этого же файла, то система контроля версий не позволит ему выполнить данную операцию. Это позволяет целиком избегать коллизий программного кода в одном и том же файле [1]. Подводя итог, мы можем отобразить общую схему работы с системой контроля следующим образом:

Рис. 3. Схема работы с VCS из IDE Delphi/C++ Builder.

Интеграция систем контроля версий в среды разработки.

Если вы еще раз посмотрите на Рис. 4, то обратите внимание, что на этой схеме мы ссылаемся на среды разработки Delphi и C++ Builder. Совершенно очевидно, что если клиентское обеспечение системы контроля версий будет интегрировано в среду разработки, то это сделает использование VCS максимально удобным для разработчика. Проблема, однако, заключается в том, что все системы контроля версий имеют собственное независимое клиентское API для взаимодействия с сервером. Разумеется, производители VCS не имеют возможности создавать инструменты для интеграции своего обеспечения для всех существующих сред разработки. Практика показывает, что обычно они интегрируются с такими продуктами, как Microsoft Visual C++, Microsoft Visual Basic, но не с Borland Delphi и Borland C++ Builder. Интеграция систем контроля версий с продуктами Microsoft стала возможна по причине публикации корпорацией Microsoft специального стандарта: Microsoft Common Source Code Control API, сокращенно SCC API. Поддержка SCC API встроена во все среды разработки Microsoft. Производители систем контроля версий должны включить в свои продукты специальный объект – SCC-Provider, который является связующим звеном между средой разработки и системой контроля версий:

Рис. 4. Схема взаимодействия IDE и системы контроля версий.

Если производители системы контроля версий хотят, чтобы их система была доступна из продуктов Microsoft, то им достаточно только реализовать SCC-Provider. Вы можете протестировать вашу систему на наличие доступных SCC-Provider’ов при помощи утилиты ProvidersTest (http://www.devrace.com/athlant/download.php). После запуска утилита показывает все обнаруженные в системе SCC-провайдеры:

Рис. 5. Проверка установленных SCC-провайдеров при помощи программы ProvidersTest.

Из рисунка видно, что в системе установлено пять SCC-провайдеров: QVCS, Microsoft SourceSafe, Jalindi Igloo для CVS, Intasoft AllChange и Surround SCM. SCC API является универсальным способом интеграции систем контроля версий в среду разработки. До недавнего времени продукты Borland не поддерживали SCC API [2], однако данная интеграция стала возможной после выхода стороннего продукта – Athlant [3].

Особенности использования Athlant

Athlant представляет собой эксперт, совместимый с Delphi 5-7 и C++ Builder 5-6, который интегрируется в IDE. При помощи Athlant программист может вызывать функции любой системы контроля версий из главного меню, Code Editor и Athlant Manager. На текущий момент, вы можете использовать Athlant со следующими системами контроля версий, которые поддерживают SCC API:

Version control system	Vendor	URL
CS-RCS	Component Software	http://www.componentsoftware.com/csrcs
CVS with Jalindi Igloo plugin		http://www.cvsnt.org, http://www.jalindi.com/igloo
VisualAge TeamConnection	IBM	http://www.software.ibm.com/ad/teamcon
Visual SourceSafe	Microsoft	http://msdn.microsoft.com/ssafe/
Source Integrity	MKS	http://www.mks.com/
P4 Version Control System	Perforce	http://www.perforce.com/
PVCS Versions Manager	Merant	http://www.merant.com/
QVCS	Quma Software	http://www.qumasoft.com/
Rational ClearCase	Rational	http://www.rational.com/products/clearcase/
Starbase Versions (StarTeam)	Starbase	http://www.starbase.com/
Team Coherence	QSC	http://www.qsc.co.uk/
CM Synergy (Continuus)	Telelogic	http://www.continuus.com/
AllChange	Intasoft	http://www.intasoft.net/
Code Co-op	Reliable Software	http://www.relisoft.com/
SourceOffSite	SourceGear Corporation	http://www.sourcegear.com/
Seapine Surround SCM	Seapine Software	http://www.seapine.com/
AllFusion Harvest Change Manager	Computer Associates	http://support.ca.com/harvest_supp.html

Рис 6. Список систем контроля версий, реализующих SCC API.

Поскольку Athlant встраивается в IDE, то на его работу действует ряд ограничений, связанных с идеологией среды Delphi/C++ Builder. В частности, для Athlant недоступны файлы, которые не включены в текущий проект. Таково ограничение интерфейса OpenTools API, на базе которого строятся все эксперты. Необходимо разделять понятия "проект IDE" и "проект VCS". Проект IDE – это программа, состоящая из группы файлов соответствующих типов. Проект VCS – это группа файлов, контролируемых системой и объединенных под общим названием. На практике стараются, чтобы проект VCS совпадал с проектом IDE или, как минимум, включал бы его в себя. Проект VCS может содержать любые файлы, как текстовые, так и бинарные: pas, cpp, hpp, dfm, dpk, xml, txt, dof, bpk, jpg и так далее. В отличие от проекта VCS, проект IDE содержит только те файлы, с которыми может оперировать среда разработки.

Итак, первым делом вы должны создать (или открыть существующий) проект IDE. После этого вы должны создать в VCS проект для хранения ваших файлов. Это можно сделать, запустив VCS client при помощи пункта "Athlant | Run external SCC program", или (если позволяет конкретная VCS) прямо из диалога подключения к проекту VCS: "Athlant | Connect to storage...". Если вы подключаетесь к уже существующему проекту, то достаточно вызвать "Athlant | Connect to storage...":

Рис. 7. Диалог подключения и создания проекта VCS на примере Visual SourceSafe.

Если все прошло нормально, то вы фактически работаете с двумя проектами сразу: проектом IDE и проектом VCS. Если вы добавите файл в проект IDE (используя IDE Project Manager), то файл станет доступен для Athlant, и вы сможете включить этот файл и в VCS Project. Обратите внимание на этот факт: даже если вы добавили файл в проект IDE, это не значит, что он автоматически начинает контролироваться VCS. Вы должны явно добавить новый файл в проект VCS ("Athlant | Add …"):

Рис. 8. Добавление файлов в проект VCS.

В данной ситуации есть еще один важный для понимания момент. Когда вы работаете с VCS, то любой файл с вашими исходными текстами присутствует минимум в двух местах: на сервере VCS (в базе данных или в специальном внутреннем каталоге) и на вашем локальном диске, который доступен для IDE. Когда вы добавляете (создаете) файл в проект IDE, то получается, что локальный файл на вашем локальном диске уже есть, но этого файла еще нет на сервере VCS. Можно было бы автоматически добавлять файл из проекта IDE в проект VCS, однако это было бы неудобно, поскольку вновь создаваемые файлы имеют сгенерированные имена вроде "Unit1.pas". Удобнее сначала переименовывать файл, а только потом добавлять его в проект VCS. Как только файл добавлен в проект VCS, то по умолчанию считается, что вы не имеете права его редактировать без специального запроса, поэтому, как уже было сказано, копия файла на локальном диске сразу же получает атрибут read-only. Вы можете читать этот файл, но не можете его редактировать.

Как уже было сказано, для того, чтобы открыть файл для редактирования, необходимо запросить его у VCS при помощи вызова функции Check out. Эта функция доступна в меню "Athlant | Check out …" и в редакторе кода открытого файла:

Рис. 9. Вызов функций контроля версий из Code Editor.

Когда вы считаете, что закончили редактирование файла, необходимо вернуть измененный файл в VCS. Для этого воспользуйтесь командой Check In из меню "Athlant | Check In", или Code Editor (смотри рисунок 8). Фактически, в этом заключается весь цикл работы с VCS. Мы не будем останавливаться на таких дополнительных командах, как Show History или Show Differences, поскольку их использование самоочевидно.

Работа с группами файлов. Установка и использование Athlant Server.

Зачастую программисту приходится работать сразу с группой файлов. Для удобства Athlant содержит специальный инструмент, предназначенный для управления всеми файлами проекта IDE:

Рис. 10. Athlant Manager.

Athlant Manager позволяет производить все операции с файлами проекта IDE при помощи панели инструментов и контекстного меню, которое доступно при нажатии правой кнопки на названии файла. Из рисунка видно, что Athlant Manager разбивает файлы на следующие группы:

Файлы, которые открыты текущим пользователем для редактирования
Файлы, которые открыты другими пользователями для редактирования
Файлы, которые добавлены в проект VCS, а значит, контролируются системой.
Файлы, которые добавлены в проект IDE, но не добавлены в проект VCS.

Обратите особое внимание на папку Favorites. В нее при помощи Drag&Drop можно поместить те файлы, с которыми вы работаете наиболее часто. Для каждого узла в дереве фильтров доступно контекстное меню, позволяющее сразу запросить все файлы группы для редактирования или занести изменения в VCS. Таким образом, поместив нужные нам файлы в папку Favorites, мы всегда сможем быстро запросить их всех у VCS.

Теперь предположим, что мы работаем в группе разработчиков. В этом случае, как уже было сказано, может возникнуть ситуация, когда вы попробуете запросить файл, который уже занят другим программистом. Система, разумеется, обработает эту конфликтную ситуацию, однако гораздо удобнее было бы знать заранее, занят ли файл кем-то или нет. К сожалению далеко не все системы предусматривают механизмы нотификации клиентов о том, что кто-то изменил состояние какого-либо файла. Однако мы можем воспользоваться возможностями Athlant Server. Athlant Server является дополнительной программой, входящей в состав основного пакета Athlant. Из компьютеров, на которых был установлен Athlant, выберите компьютер для Athlant Server. Найдите в каталоге, в который был установлен Athlant, файл AthlantServer.exe. Чтобы зарегистрировать сервер в системе, запустите "AthlantServer.exe" с параметром REGSERVER. На всех остальных рабочих местах необходимо открыть опции Athlant (Пункт меню "Athlant | Options"):

Рис. 11. Опции Athlant Server.

Необходимо указать имя компьютера, на котором будет запускаться Athlant Server в поле "Remote Server name", и включить опцию "Listen to remote events". В этом случае, когда кто-то забираете файл для редактирования, или отдаете измененную версию, все остальные разработчики автоматически получат обновленную информацию о состояния файла в Athlant Manager. Также, Athlant Server включает в себя систему обмена сообщениями. Задав свое имя в полей Display user name, и включив опцию Listen to incoming messages, вы получаете возможность посылать и принимать сообщения от других пользователей Athlant. Функция для отправления сообщения доступна в меню "Athlant | Send message…". В появившемся диалоге указать имя получателя (выпадающий список заполняется именами разработчиков, которые в данный момент доступны) и набрать текст посылаемого сообщения.

Заключение

Использования систем контроля версий может значительно повысить производительность, как индивидуальных программистов, так и целых коллективов разработчиков. На практике, автоматический контроль кода во многом заставляет разработчиков аккуратнее подходить к исправлениям, поскольку возможность редактировать тот ли иной файл жестко регламентируется системой контроля версий. С точки зрения администрирования какого-либо проекта, контроль версий дает, пожалуй, наиболее четкое представление о том, как ведется работа над разработкой. Использование SCC API в Athlant позволяет, с одной стороны, интегрировать в Delphi/C++ Builder совершенно разные системы контроля версий, а с другой стороны, дает возможность разработчикам использовать все эти системы единообразно. Переключение между системами контроля версий в Athlant без установки дополнительных средств интеграции позволяет разработчикам использовать одновременно разные системы контроля версий в разных проектах, выбирая системы в зависимости от требований к проекту.

[1] Некоторые системы контроля версий позволяют редактировать один и тот же файл несколькими программистами, сохраняя отдельно несколько параллельных версий файла. Подобные системы также предоставляют возможность полуавтоматического объединения нескольких параллельных версий в одну.

[2] Исключением является лишь JBuilder Enterprise Edition.

[3] Сайт продукта http://www.athlant.com, http://www.devrace.com/athlant