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). |
03.01.2003, 09:38 | #2 |
Moderator
|
Как я понимаю, к одному сообщению можно прикрепить только 1 файл
Это проект. |
|
03.01.2003, 09:38 | #3 |
Moderator
|
Это ocx (если у кого-то нет)
|
|
03.01.2003, 09:39 | #4 |
Moderator
|
Это сама статья в формате Word.
|
|
08.01.2003, 14:32 | #5 |
Administrator
|
Re: Размышления на тему “Системы контроля версий в Аксапте”.
Цитата:
Изначально опубликовано Андре
В тот момент, когда я делаю CheckOut, неплохо было бы блокировать в Аксапте соответствующий TreeNode в АОТ’е. По-моему, я когда-то видел такую возможность, но сейчас когда это понадобилось, я не нашел этой возможности. Если кто-нибудь знает как это сделать - сообщите пожалуйста мне об этом. По идее, у некоторых потомков TreeNode есть свойство lockedBy. Через него тоже можно установить блокировку (по крайней мере, так написано в Help). Вот только после изменения его значения взводится флаг IsOld, а сохранение опять сбрасывает свойство (так работало у меня). Цитата:
Изначально опубликовано Андре
Обработка ошибок при вызове COM – методов. В случае если вызов COM объекта/метода приводит к ошибке появляется похожее окошко ... Как можно подавить появление этого окошка ? Попробуй поставить break_point в методе add этого класса. Вдруг узнаешь что полезное. Идея взята с TechNet: http://technet.navision.com/default....put&NEWSID=404
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
02.09.2003, 16:28 | #6 |
Пенсионер
|
Контроль версий
Спасибо Андрей за идею и стартовую реализацию!!!!!
Я немного переработал твой проект и теперь сохраняю просто файлы XPO требуемых объектов. Тем самым я могу сохранять любой объект, а не только методы. Также у меня эта штука работает и с проектами (что гораздо полезнее), при этом у меня сохраняется и структура проекта, а также в поле comment в MSSS новой версии ХРО файла, записывается наименование проекта в котором данный объект изменен. И храню я файлы ХПО в структуре каталогов на диске, которая полностью соответствует структуре АОТ. Кстати структура т.н. проектов в MSSS точно такая же... Еще раз спасибо огромное... зы: мне кажется, что подобным образом можно использовать и GNU версию cvs системы.... |
|
03.09.2003, 11:35 | #7 |
Moderator
|
Цитата:
Еще раз спасибо огромное...
Цитата:
теперь сохраняю просто файлы XPO требуемых объектов. Тем самым я могу сохранять любой объект, а не только методы.
Цитата:
мне кажется, что подобным образом можно использовать и GNU версию cvs системы....
|
|
03.09.2003, 16:24 | #8 |
Пенсионер
|
Цитата:
я всего лишь первый сделал какие-то шаги к ее реализации.
Цитата:
Когда я этим занимался я подумал про это - другое дело, что XPO файлы не настолько читабельны и править их не из Аксапты все-таки рискованно - хотя можно.
Цитата:
Так что подключить CVS я думаю возможно, но подход там будет несколько другой - вместо работы с COM объектами нужно будет генерить и выполнять внешние команды.
|
|
18.09.2003, 12:16 | #9 |
Участник
|
Можете поделиться доработками проекта по контролю версий?
Может быть создадим что то на подобие open-source проекта по интеграции Axapta с VSS ? |
|
19.09.2003, 10:43 | #10 |
Пенсионер
|
Цитата:
Изначально опубликовано Антон
Можете поделиться доработками проекта по контролю версий? Может быть создадим что то на подобие open-source проекта по интеграции Axapta с VSS ? И еще, просьба не пинать сильно за качество кода, да, и я немного изменил идеологию глубокоуважаемого Андре : 1. Потр... помучившись с виртуальной компанией, которую я хотел использовать для совместного доступа всех пользователей к настройкам системы VCS, я засунул эти самые настройки прямо в код!!! тем более, что мы приняли решение хранить все изменения на центральном сервере. Я не стал искать другое решение, т.к. необходимо было срочно запускать этот механизм! 2. Пользователей я стал использовать системных, что думается, гораздо логичнее. 3. Изначально-заложенная Андре функциональность была сознательно урезана, только на сохранение версий кода. Просмотр думается реализовать попозже из-за пробрем с объектом "Versions" в VSS. я не могу ни как его добыть в Аксапте, а соответственно не могу прочитать ВСЕ параметры каждой версии (может кто разгадает эту загадку?). Контрол для сравнения версий работает криво (но я склоняюсь, что это я работаю криво), т.к. M$ не поддерживает его с 1998 года. А посему сравнение в Аксапте не используем. Возможно использование чего-нибудь другого... 4. Т.к. кое что из функционала не используется и настройки мы храним в коде, то формы не используются и часть методов тоже. Идея иб открытии проекта с открытыми исходникам, просто классная, я думаю проблемма настолько наболела, чтодальше некуда. Более того, ИМХО, надо в общем случае уходить от VSS и переходить на GNU CVS, благо исходников в инете хватает. Можно вообще использовать внутренние классы, но как они работают я не знаю... Для этого необходима поддержка администрации форума ИМХО и энтузазистов разработчиков, а не таких чайников как я... |
|
19.09.2003, 11:12 | #11 |
Участник
|
Спасибо!
Разместить проект можно без проблем на таком сайте как SourceForge.net - для этого там имеются все необходимые условия. Общение же и информация о проекте может быть развернута на данном сайте. А то что к этому проекту попросить приложиться "тяжеловесов"-профи по Аксапте - это совершенно верно! Им как раз такая задача по плечу. |
|
19.09.2003, 11:42 | #12 |
Участник
|
Уважаемый <b>blokva</b>!
У меня при компиляции проекта вывалились вот такие вот обшибки ... dem_SourceSafeLauncher - FillNodeList - The class TreeNode does not contain this function. dem_SourceSafeLauncher - MakeExp- The class TreeNode does not contain this function. Хелп ! |
|
19.09.2003, 12:41 | #13 |
Moderator
|
Класс мой. А метод не мой.
Разве у TreeNode есть iterator() ? Есди проект все-таки будет - постараюсь в нем поучаствовать. Но сразу предупреждаю, что во первых мало времени, во вторых проблема для меня стала уже не столь актуальной. Но помочь постараюсь |
|
19.09.2003, 15:42 | #14 |
Участник
|
Ладно, с ошибками я повожусь Думаю работать будет.
Мне вот что интересно - теперь - после того как дописали и как я понимаю внедрели контроль версия - часто пользуетесь им в Аксапте? Можете поделиться впечатлениями от использования данной фичи - как повлияло на практику программирования, процесс и т.п.? |
|
22.09.2003, 20:33 | #15 |
Пенсионер
|
Цитата:
Изначально опубликовано Антон
Уважаемый <b>blokva</b>! У меня при компиляции проекта вывалились вот такие вот обшибки ... dem_SourceSafeLauncher - FillNodeList - The class TreeNode does not contain this function. dem_SourceSafeLauncher - MakeExp- The class TreeNode does not contain this function. Хелп ! Как понятно, я надеюсь, из названия методов, то первый заполняет контейнер элементами маршрута выбранного узла, чтобы было проще воспроизвести потом данную структуру, как в соурс сэйф, так и на диске, может и не оптимальное решение, но я же только учусь, может даже можно было исползовать МАПы , чтобы не преобразовывать потом текстовое наименование узла в объект TreeNode , не знаю... Второй метод я использую для движения вверх по дереву, до первого "экспортируемого" узла, не секрет, что метод отдельно от класса экспортировать нельзя.... |
|
22.09.2003, 20:35 | #16 |
Пенсионер
|
Цитата:
Изначально опубликовано Андре
Класс мой. А метод не мой. Разве у TreeNode есть iterator() ? Есди проект все-таки будет - постараюсь в нем поучаствовать. Но сразу предупреждаю, что во первых мало времени, во вторых проблема для меня стала уже не столь актуальной. Но помочь постараюсь итератор есть и нормально работает, а методы мои, т.к. я уже говорил, что поменял идеологию.... |
|
22.09.2003, 20:51 | #17 |
Пенсионер
|
Цитата:
Изначально опубликовано Антон
Ладно, с ошибками я повожусь Думаю работать будет. Мне вот что интересно - теперь - после того как дописали и как я понимаю внедрели контроль версия - часто пользуетесь им в Аксапте? Можете поделиться впечатлениями от использования данной фичи - как повлияло на практику программирования, процесс и т.п.? Мы - фирма внедренческая в Беларуси, называемся БелСофт, я руковожу отделом разработки 6-8 программеров и тестеров, одновременно внедряется 4-6 проектов, по каждому проекту ведуться доработки, причем все проекты пересекаются на т.н. нашем законодавстве, т.е. многие доработки общие. При стыковке доработок, возникает куча проблемм, кто когда и зачем, что-то сделал, иногда требуется откат на определенный уровень, да и вообще просто посмотреть, как от модификации к модификации менялся код, чтобы можно было создать что-то универсальное, ну и т.д. и т.п. Всвязи с тем, что мне ни кто не помог в перехвате процесса компиляции или сохранения проекта, а сам я не допер, то пришлось данную фичку вводить процедурно, т.е. попросить всех быть благоразумными и запускать эту штуку самостоятельно. Как только программер создает проект под определенную доработку, то он "напихивает" в него объекты, которые он собирается использовать, затем он обязательно сохраняет т.н. исходный код объектов в СС. Далее на усмотрение разработчика, он сохраняет промежуточные состояния, и в конце перед сдачей проекта тестеру, он обязан сохранить проект вновь. В настоящий момент времени мы пока привыкаем к процедуре и накапливаем базу изменений. Как только мы воспользуемся данной фичкой всерьез, тоя непременно сообщу обществу! А еще возникло классное следствие этой фички: например, если требуется перенести ВСЕ доработки по какому либо предприятию, то не надо тоскать весь ЮСР слой, достаточно перенести все ХПО файлы из соответствующего каталога СС и экспортнуть их нв чистую систему! |
|
23.09.2003, 11:00 | #18 |
Moderator
|
Цитата:
Мы - фирма внедренческая в Беларуси,
Цитата:
А еще возникло классное следствие этой фички: например, если требуется перенести ВСЕ доработки по какому либо предприятию, то не надо тоскать весь ЮСР слой, достаточно перенести все ХПО файлы из соответствующего каталога СС и экспортнуть их нв чистую систему!
А почему внедренческая фирма пишет на usr слое ? Или я отстал от жизни ? |
|
23.09.2003, 11:11 | #19 |
Пенсионер
|
Цитата:
Изначально опубликовано Андре
А почему внедренческая фирма пишет на usr слое ? Или я отстал от жизни ? Хотя Вы подкинули неплохой вопрос, надо будет еще ввести сохранение версий по слоям.... |
|
23.09.2003, 15:19 | #20 |
Участник
|
Цитата:
Изначально опубликовано blokva
Как только программер создает проект под определенную доработку, то он "напихивает" в него объекты, которые он собирается использовать... В Аксапте можно заблокировать изменяемый объект. Остальные программисты не смогут править этот объект. Получилось ли использовать данную функцию? Или я чего-то не понимаю? |
|
Теги |
axapta, download, version control, vss, полезное, система контроля версий |
|
|