Андре: Интеграция Ax с системами контроля версий

[Андре]

В этой ветке я хотел бы подвести некий промежуточный итог одной из перых тем, начатых мною на этом форуме(Размышления на тему “Системы контроля версий в Аксапте”.). Я осознаю возможную реакцию на этот пост, но желание поделиться опытом перевесило верояность неконструктивной критики. Если у вас будут конкретные вопросы - с удовольствием отвечу. Если будут предложения и пожелания по улучению процесса - с удовольствием выслушаю. Комментарии в стиле "стандартная связка AX + MS SS рулит", честно говоря, не интересны, так как я имею свое мнение на этот счет, подтвержденное практикой.

Все ниженаписанное - не спланированная статья, а всего лишь мой поток мыслей, которыми мне захотелось поделиться в субботу в час ночи после удачной сборки ax-проекта, который разрабатывался двумя разработчиками параллельно в течении трех месяцев на разных проектах и которые практически необщались с друг другом. Несмотря на то, что каждый разработчик решал свои задачи на своем проекте, мне достаточно просто и комфортно удалось слить все измениние в одно общее решение. Однако предупреждаю, что это мое решение, выработанное мною путем проб и ошибок и оно скорее всего не будет идеальным для вас. Хотя я и пишу про связку "ax +cvs" сразу предупреждаю, что код относящийся к axapta в моем репозитории составляет менее 5%. Если вас интересует только axapta уверен, что вы сможете выработать для себя решение, более удобно заточенное для решения ваших задач.

Итак мысли:

1. Две вещи, необходимые мне, как разработчику - wiki и система конроля версий(cvs). И если удобную мне wiki я выбрал сразу (wikidPad), то с системами контроля версия я прошел долгий путь "ms source safe -> perforce -> subversion -> mercurial" в течении 10 лет. Первая(wiki) позволяет упорядочить свой опыт и быстро находить решения уже решенных проблем, вторая(cvs) - помогает мне уверенно отвечать на вопросы, касающиеся исходного кода, такие как:

- что я сделал чтобы решить эту проблему;
- для чего и как я менял этот код;
- какие другие модификации затрагивали данный код и т.д.

Даже если я работаю один по данной схеме, выгоды от этой связки перевешивают затраты на поддержание ее в актуальном состоянии. Если вы считаете, что cvs вам не нужна и все вами написанное прекрасно живет у вас в голове - дальнейшие размышления вам будут неинтересны.

2. Интеграция cvs и среды разработки. На самом деле ответ на вопрос о ее необходимости не столь однозначен, а сторонников ее отсутствия примерно столько же, сколько приверенцов инеграции. Если инересуют аргументы обеих сторон советую почитать обсуждения в разделе "Средства разработки" на www.rsdn.ru. В любом случае, я предлагаю абстрагироваться от рекламных лозунгов MS об интеграции (MS VS + MS SS, MS AX + MS SS) и взвесить - "вам шашечки или ехать".
Когда то, еще в 2.5 я писал связку Ax + SS, когда еще Damgaard не продался Navision/MS и данная возможность не была реализована в стандартном функционале. Я пробовал стандартную связку Ax4 + SS. Для меня, слабые стороны backend (SS) перевешивают сомнительные достоинства frontend (возможность порулить cvs напрямую из Ax). Я не считаю интеграцию необходимым условием при выборе cvs. Я считаю, в силу специфики axapta, что полноценную интеграцию ЭТОЙ системы с cvs сделать удачной очень сложно, если возможно вообще. Более того, по моим ощущениям это даже не нужно.

3. По способу извлечения файлов из репозитория для изменения(check out) все cvs можно разделить на две группы: оптимистичные и пессимистичные (терминология моя). Пессимистичные предполагают, что за время, пока разработчик работает с файлом, кто-то может изменить тот же самый кусок кода, поэтому (по умолчанию) блокируют файл сразу после его передачи разработчику. Именно это стандартный режим работы MS SS и именно так работает связка MS AX + MS SS.

- Данный подход предполагает что если разработчик вовремя не позаботился и не забрал для изменения все необходимые ему файлы, то потом в offline он будет только кусать себе локти не имея возможности поправить необходимые куски кода, не нарушив регламент разработки.
- Данный подход предполагает, что если разработчик забрал файлы для изменения и внезапно заболел, то возможность правки этих файлов другими разработчиками будет невозможна до его выздоровления (без нарушения регламента разработки).
- Данный поход предполагает, что если я забрал файлы для изменений и внес все множество мелких несвязанных изменений в offline (а я часто так делаю), то в репозиторий cvs они лягут одним большим коммитом. Подумайте об этом. В history cvs у вас будет одна запись "сделано A, B,C и D" и у вас не будет возможности отделить изменения произведенные для реализации фичи A от исправления бага B. Это может оказаться очень важным когда вам спустя месяцы или даже годы понадобится использовать fix B на новом проекте и перед вами будет стоять задача отделения его от фичи A.
- Данный поход предполагает, что если я забрал файлы для изменений и работаю в offline то я не могу сделать коммит, реализовав одну из фич. Мне некуда его делать. Вместо этого я сохраняю промежуточный проект во временую папочку с именем project005.xpo, чтобы в случае, если я дальше что-то напортачу я мог бы откатиться на него обратно. Хм... мы вроде ставили cvs, чтобы уйти от этого...

imho, cvs-пессимисты абсолютно не подходя для поектов где есть вероятность разработки не в центральном офисе. Если кто-то знает вторую современную cvs-пессимиста - скажите мне об этом, я постараюсь объодить стороной это чудо.

Оптимистичные системы контроля версий предполагают, что вероятность возникновения конфликта мала и не блокируют файл перед его модификацией. В общем то, во многих системах этого типа (например, Subversion) операция получения файла из репозитория отсутствует как таковая - разработчик правит локальную копию когда ему вздумается, а конфликты, если такие возникли разруливает в момент помежения модификаций в репозиторий. К слову, конфликты возникают не так часто, как ожидают люди пришедшие с SS. Большая часть возникших конфликтов разрешалась автоматическим мерджем под моим присмотром. Справедливости ради, скажу что axapta позволяет допилить классы, отвечающие за работу с cvs так, чтобы они поддерживали нужную вам cvs и вобщем то на черновую интеграцию с AX с Perforce я потратил где-то дня три. Более-менее стабильное решение поддерживающее интеграция с cvs, отличной от MS SS, реально сделать за пару недель. Однако даже cvs-оптимисты не решают две последнии озвученные мною проблеиы. Поэтому...

4. Если вы все-таки решили выбрать cvs (а не брать то, что идет в комплекте) то крайне рекомендую посмотреть на распределенные cvs (distributed cvs). Если объяснять коротко и на пальцах, то они позволяют каждому разработчику создать свою копию репозитория у себя на ноутбуке и полноценно работать с ним в offline, делая в него коммиты. После завершения работы над законченым куском функционала они позволяют слить все модификации в общий репозиторий. Причем, что очень важно, не одной большой транзакцией, а последовательностью всех коммитов, которые делал разработчик, не потеряв всей истории разработки. Раньше из известных dcvs был только платный BitKeeper на котором, кстати, собиралось ядро linux пока Линуса не достала его закрытось и он не написал свой Git. Также есть, Bazaar и Mercurial. Все они бесплатны, и на мой взгляд, сделать однозначный выбор нельзя. Насколько я знаю все они поддерживают конверторы, позволяющие импорировать репозитории из других систем с историей всех изменений. Рекомендую посмотреть все и принять решение на основаннии вышего набора критериев. Я выбрал Mercurial.

5. Понимаю, что этот пункт вызовет наибольшее раздражение противников "велосипедов", но чтобы не быть голословным мое решение сейчас выглядит так:

a) Модификация в ax позволяющая из контекстного меню проекта выгрузить его поэлементно с заданной структурой папок. Каждый элемент выгружается два раза - в папку проекта (чтобы иметь changelist по конкретной модификации) и в папку где храняться все объекты приложения(чтобы иметь сквозную историю модификаций по всей системе).
б) Набор скриптов (bash + python) разделяющая из выгруженных файлов действительно код от служебной информации, типа даты и времени выгрузки. Ее потеря для меня не крична, зато удобнее просматривать изменения, не отвлекаясь на изменения "не по делу". В общем то, это совсем не обязательный шаг - любой адекватный diff можно научить игнорировать эти изменения. Однако cvs при каждом коммите будет напоминать что вновь выгруженные файлы изменились, хотя в них поменялась только дата выгрузки.
в) Ручной diff и commit всех изменений в репозиторий из командной строки.
г) Если возникает необходимость вести удаленную разработку все изменения коммитятся в локальный репозиторий.
По приезду в офис я получаю перечень коммитов, которые нужно проиграть на рабочем приложении:
ademidov@ademidov:~$ cd main_repository
ademidov@ademidov:~$ hg incoming local_repository
И вношу каждый коммит в общую базу с общим репозиторием, руками делая merge если в этом возникает необходимость:
ademidov@ademidov:~$ hg pull local_repository
После этого подъем проекта на сборочное приложение и компиляция, чтобы убедиться что нет ошибок.

[belugin]

См. также:
База знаний ERP : Axapta / Интеграция Visual Source Safe

[belugin]

Вопрос: внедрено ли где-нибудь вот это вот что описано в первом посте?

Цитата:

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

Четверка вроде уже не добавляет эти сведения.

[oip]

Цитата:

Также существует проект ddpVault для интеграции /Source Gear Vault в Axapta — он с исходниками выложен на /Got Dot Net?

Цитата:

У www.perfectprogramming.com.au есть модуль контроля версий для Axapta

Ссылки на проект и на модуль мертвые.

[belugin]

Да. похоже они стали Итерейшн Два и не перенесли туда проекты

[Андре]

Цитата:

Вопрос: внедрено ли где-нибудь вот это вот что описано в первом посте?

У меня реализовано с помощью bash скриптов. Или вопрос был не в этом?

[belugin]

не, я просто уточнил, это все уже реально работает в реальной команде или только идея?

[Андре]

Работает не у всех, а только у тех, кого это заинтересовало. Я сильно не уверен, что продавливание таких методик силой реально что-то улучшит.
Теоритически, я могу пропускать все наши проекты через cvs так как перед помещением их в приложение они проходят у нас определенную процедуру, в которой устанавливается однозначная связь между проектом, задачей которую он решает и автором модификации. Но опять же, мне кажется, что тупой импорт их в cvs бесполезно.
Пока cvs - это частная инициатива нескольких разработчиков. Вполне возможно, что так оно и останется.