|
03.01.2003, 09:34 | #1 |
Moderator
|
Размышления на тему “Системы контроля версий в Аксапте”.
Добрый день.
Люблю праздники - неожиданная куча свободного времени позволяет обдумать и реализовать то, о чем давно думал, но руки не доходили. Собственно, эта статья и является результатом моих экспериментов. Здесь я попытаюсь подвести итог своим размышлениям. Следует учесть, что данные размышления, пока так и остаются теорией и не были проверены на практике. Поэтому относитесь к проекту не как к готовому решению, а как к одному из возможных направлений решения подобных задач. Итак, к делу. Не раз меняя что-либо в стандартной функциональности Аксапты я доходил до точки, когда был вынужден сказать себе – “Стоп. Вернемся к тому, с чего начали” или “Интересно, как выглядел этот код, пока он я еще работал и я не начал его менять ?”. Посмотрим, что для этого может предложить стандартная функциональность Аксапты. Да в принципе и не много – ну могу я периодически выгружать необходимый проект во внешний файл(в конце концов файлов становится так много, что сам перестаешь в них разбираться) , могу откатиться назад к первоначальному состоянию, просто удалив свой слой для данного объекта (дешево и сердито). Эти способы мало того, что неудобны, так еще и не позволяют многих вещей, таких как: • Откат отдельного метода класса. Почему я вынужден экспортировать/импортировать весь класс, когда мне нужен всего лишь один метод? И не говорите мне, что это противоречит духу ООП – да противоречит, но часто бывает нужным. • Установление личности программиста, внесшего те или иные изменения в проект. Да есть такая вещь как комментарии, но либо мы храним в методе закомментированную историю всего метода и код вырастает до нереальных объемов, либо мы удаляем исправленный код и эту версию нам уже не вернуть. • Наглядное сравнение двух версий проекта. Этот пункт в принципе реализуем – на usr слой грузим одну версию проекта, на usp – другую и сравниваем. Но уж больно муторно все это и нужна очень веская причина, чтобы начинать всю эту бодягу. Итак, после некоторого времени программирования в Аксапте перед программистом встает проблема контроля версий проектов, классов методов и прочих объектов Аксапты. Что здесь можно сделать? Я вижу здесь два решения: 1. Написание своей системы контроля версий в Аксапте. Аксапта предоставляет средства, которые позволяют получить доступ к коду любого метода любого класса. Получаем код и в необходимый момент времени сохраняем этот код в специально созданную таблицу примерно такого вида: Кроме того, в этой либо другой таблице можно хранить информацию о версии (а именно дату версии, автора версии и т.д.) Однако прежде чем реализовывать данный вариант следует подумать о таких вещах, как: • Мы храним каждую версию метода, а не различия между ними. Это приводит к увеличению объема нашей таблицы, что понятно не есть хорошо. • Кроме того, неплохо бы подумать о том, как мы будем сравнивать версии методов и визуализировать эти отличия. Эти моменты требуют разработки очень большой функциональности и прежде чем пойти по этому пути, стоит решить – а стоит ли это тех усилий, которые вы затратите. С другой стороны, вы получаете полный контроль над процессом. Так что решать вам. 2. Можно интегрировать Аксапту с одной из уже имеющихся систем контроля версий, например Microsoft SourceSafe. По этому пути я и попробовал пойти. Запускаем Ole View из состава Microsoft Visual Studio и в разделе Type Libraries находим строку Microsoft SourceSafe 6.0 Type Library (Ver 5.1). Отлично – библиотека есть, значит, уже есть шанс. Там же можно посмотреть, что сервером объектов в моем случае является d:\Languages\vs6\vss\win32\SSAPI.dll. Остается рассмотреть только некоторые ключевые моменты: Открываем базу данных в SourceSafe: PHP код:
Выбираем проект, который будет использоваться при работе с Аксаптой: PHP код:
И добавляем какой-либо файл в SourceSafe: PHP код:
Аналогичным образом интерфейс IVSSItem предоставляет возможность выбирать в SourceSafe необходимые файлы, делать Check In и Checkout. Рассмотрим подробнее операцию сравнения двух версий одного метода. Немного покопавшись в реестре, я нашел интересный ActiveX, зарегистрированный в моей системе – DiffMergeCtrl ActiveX Control Module (DiffMergeCtl.ocx). К сожалению, у меня не было возможности узнать, кто его зарегистрировал, но судя по тому, что он находился в папке D:\Program Files\Common Files\Microsoft Shared\vs98 его установил либо сам SourceSafe,либо он зарегистрировался при установке какой-либо иной части Visual Studio. На всякий случай я выложу этот ocx, если у вас не зарегистрирован этот компонент – скачайте и зарегистрируйте его. Все это дело я реализовал как Add-Ins: поэтому при импорте проекта будьте осторожны – он перезапишет ваш SysContextMenu. Вся функциональность реализована в виде двух классов – dem_SourceSafeEngine и dem_SourceSafeLauncher. При выборе любого из пунктов меню запускается метод main класса dem_SourceSafeLauncher. При этом сам выбранный пункт меню передается в EnumParameter MenuItem’а. В методе извлекается вся необходимая информация и запускается метод Run() этого же класса: PHP код:
PHP код:
Рассмотрим один из методов, например AddItem: PHP код:
Если вы решите аналогичным образом работать с методами формы и таблиц, Вам нужно реализовать соответсвующие методы dem_SourceSafeEngine и добавить в этот метод соответсвующие cas’ы. Напоследок, покажу пару методов из dem_SourceSafeEngine – addItem и addClass: PHP код:
В первой строке метода мы генерируем имя, под которым элемент будет находиться в хранилище. Алгоритм генерации этого имени расположен в GetElementNameFromTreeNode. В данный момент имя элемента образуется из имени класса и имени метода, разделенных точкой. Если Вас не устраивает данный алгоритм – перепишите этот метод. Теперь addClass: PHP код:
Перед началом работы необходимо произвести настройку всей системы. Для этого предназначена форма dem_SSSetup. Описание настроек: • Путь к базе – полный путь к файлу srcsafe.ini соответствующей базы SourceSaf’а. Путь должен быть задан в соответствии с “Аксаптовским стандартом” – двойной слеш вместо одинарного. • Имя проекта в SourceSafe – тот проект в SourceSafe, в котором Вы собираетесь хранить методы Аксапты. Естественно проект должен быть создан перед началом работы. • Имя временной папки – укажите папку, в которую будут временно выгружаться файлы при Checkout. Папка должна существовать. Кроме того, в Аксапте необходимо сделать эту папку Working Folder для проекта Axapta. (Становимся в дереве на проект “Аксапта”, говорим File -> Set Working Folder и выбираем эту папку). Обратите внимание, что путь к временной папке должен заканчиваться двойным слешем – это важно. • В таблице задаются имена пользователей и пароли для доступа в SourceSafe. Пользователи выбираются из таблицы EmplTable, пароли непосредственно заводятся в таблицу. В базе SourceSafe должны существовать такие пользователи с заданными паролями. Для занесения пользователей в SourceSafe воспользуйтесь утилитой SourceSafeAdmin. При работе Аксапта определяет текущего пользователя (curUserId()) берет из этой таблицы соответствующий пароль и именно с этим именем и паролем лезет в SourceSafe. В случае неправильной настройки одного из этих параметров в методе dem_SourceSafeEngine.new произойдет ошибка при попытке вызвать метод open COM-объекта. Теперь о том, что осталось за кадром: • Все это дело реализовано только для классов и методов классов. Система контроля версий не будет работать с методами таблиц и отчетов. Я пока не стал это реализовывать; думаю, если это кому-то понадобится - справитесь. • В проекте опущены некоторые проверки, которые не существенны для того чтобы понять суть дела, но необходимы в финальной версии проекта. • В тот момент, когда я делаю CheckOut, неплохо было бы блокировать в Аксапте соответствующий TreeNode в АОТ’е. По-моему, я когда-то видел такую возможность, но сейчас когда это понадобилось, я не нашел этой возможности. Если кто-нибудь знает как это сделать - сообщите пожалуйста мне об этом. • Интерфейс IVSSVersions. Этот интерфейс предоставляет информацию о версиях. Как работать с ним в Axapta я так и не понял. Вот как бы это выглядело в VB: PHP код:
PHP код:
В VC я смог вызвать _NewEnum(). Как реализовать данную функциональность в Аксапте мне не понятно. Опять же, если у кого то есть идеи по этому поводу – буду рад их услышать. • Обработка ошибок при вызове COM – методов. В случае если вызов COM объекта/метода приводит к ошибке появляется похожее окошко: Как можно подавить появление этого окошка ? Конструкция try {… не спасает, а лишь откладывает появление данного сообщения до момента уничтожения объекта, некорректно вызвавшего метод COM объекта. • В Аксапте я нашел следующие классы xVcsServer и xVcsClient, обладающие весьма многообещающими методами. Судя по всему, эти классы нигде не используются и мне не совсем понятно их назначение – то ли у нас не закуплена соответствующая функциональность, то ли это запланировано на будущее, то ли это наоборот осталось от старой функциональности. Если кто-либо поделится со мной этой информацией – буду признателен. Заключение: 1. Буду рад услышать любые мысли/замечания как по моей реализации, так и по самой проблеме статьи. Особенно буду благодарен тем, кто поможет решить вопросы описанные чуть выше. 2. Вы можете использовать этот проект по своему усмотрению, как только Вам будет угодно(то есть, без каких либо ограничений). Если идея кому-то понравится и дело дойдет до коммерческого распространения буду рад увидеть ссылку на автора(то есть меня) в исходном коде. Хотя и это не является обязательным. |
|
|
За это сообщение автора поблагодарили: mazzy (17). |
Теги |
axapta, download, version control, vss, полезное, система контроля версий |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|