Использование механизма контроля версий в Dynamics AX

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

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

В первых версиях Axapta не имела собственной системы контроля версий. Но однажды, в далеком 2003 году, один разработчик написал первый небольшой интерфейс для работы Aх с системой контроля версий Microsoft SourceSafe. Странно, что хоть Ax уже был куплен Microsoft на тот момент, системы контроля версий не было, хотя в Visual Studio такая уже имелась.

DAX 2009

Первая система контроля версий «из коробки» появилась в Dynamics Ax 2009. Называется она MorphX VCS. Сразу стоит упомянуть, что также был включена поддержка Visual SourceSafe и Team Foundation Server. Но для их разворачивания требуется наличие отдельно настроенной системы контроля версий, к который мы будем подключаться. А чтобы развернуть MorphX VCS необходимо произвести всего несколько настроек прямо из Ax.

Во-первых, необходимо активировать систему контроля версий. Для этого необходимо пройти по пути: «Сервис – Средства разработки – Контроль версий – Настройки» и выбрать пункт «Параметры».

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

Далее по тому же пути необходимо настроить уже «Параметры системы» контроля.

На вкладке «Разное» следует указать или изменить необходимые параметры. В случае наличия ошибок в объекте выявленных в процессе компиляции, такой объект не будет помещен в хранилище контроля версий.

Параметр «Строка состояния» будет отображать описание системы.

На вкладке «Правила объектов» можно указать типы и имена объектов, которые не могут быть добавлены с систему управления версиями.

На следующим шаге, необходимо создать репозитарий для системы контроля. Для этого требуется протий по пути: «Сервис – Средства разработки – Контроль версий – Настройки» и выбрать пункт «Создать репозитарий».

После завершения создания репозитария, в базе данных Ax в таблице SysVersionControlMorphXIte2541 можно увидеть объекты, добавленные в контроль версий. В АОТ таблица имеет имя SysVersionControlMorphXItemTable.

Версии объектов хранятся в таблице SysVersionControlMorphXRevisionTable.

Извлеченные объекты можно увидеть в таблице SysVersionControlMorphXLockTable.

У объекта добавленного в систему контроля версий можно, например, через контекстное меню посмотреть историю или сравнить версии объекта.

Добавлять новые объекты в контроль версий необходимо самостоятельно, через контекстное меню объекта.

Важно помнить, так как таблицы системы контроля версий находятся в базе данных Ax, то при восстановлении базы данных, например, с Prod, данные об изменениях объектов будут утеряны.

Альтернативой встроенной системе контроля версий служит система Team Foundation Server, широко распространенная в данный момент. Для ее настройки существует документ Microsoft Dynamics AX 2009 White Paper: Team Foundation Server Version Control Setup.

DAX 2012

В Dynamics AX 2012 продолжает существовать собственная система MorphX VCS и также обеспечивается поддержка внешних систем контроля.

В 2012 году известные разработчик и программный архитектор Martin Drab написал статью, в которой поднял тему общей и изолированной среды разработки.

В статье он говорит, про то, что Ax 2012 стал более сложной системой, в которой трудно производить совместную разработку в одной общей среде, особенно если команда большая. Что Microsoft сама никак не решает проблему совместной разработки, также и командные проекты не хотят тратить силы и время на поиск решения.

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

Его статья вызывала разногласия. В основном они касались накладных расходов, связанных с разворачиванием отдельных сред. В одном из комментариев был произведен расчет, что при существующем количестве клиентов и размере их баз, на одну изолированную среду разработки, только для базы данных будет требоваться 1Tb дискового пространства. В другом был расчет, по которому на 10 разработчиков, при 20 клиентах требуется разворачивать 200 сред разработки.

Что такое изолированная среда? Изолированная среда разработки означает, что у каждого разработчика есть свой собственный изолированный код для работы. Это также требует отдельной базы данных (разные приложения могут иметь разную схему базы данных) и предпочтительно изолированной операционной системы и всех других необходимых компонентов.

Поэтому он предложил выход, который основан на использовании системы контроля версий, а именно TFS.

    Отдельные рабочие пространства

Ax 2012 поддерживает только одно рабочее пространство TFS. Его решение состоит в том, чтобы создать отдельную папку (рабочую область) для каждого пользователя и перенаправить их в одну общую папку. Для этого нужно использовать точки соединения или символические ссылки. Для этого он вносит изменение в приложение. Проект XPO, который необходим для поддержки множества рабочих пространств находится здесь (его необходимо импортировать в приложение).

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

Далее в импортированном проекте необходимо найти и запустить пункт меню «AddaxPlugin». В форме сначала нажать на кнопку «Update plugins». После этого в списке плагинов активировать «User repository» и нажать кнопку «Configure».

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

Путь до репозитария пользователя создается автоматически, путем добавления Id пользователя к пути, указанном в параметрах системы управления версиями. Символическая ссылка создается при сохранении записи и удаляется, при удалении записи пользователя.

Вот символические ссылки для пользователей administrator и hal и общая папка Shared, на которую указывают все ссылки (и которая также создается автоматически).

Данных подход можно использовать и для Ax 2009.

D365

Первым шагом является настройка Visual Studio Online (VSO). Visual Studio Online теперь поддерживает контроль версий Git, но если решение будет развернуто на стороне заказчика, Microsoft рекомендует выбрать Team Foundation Version Control. По крайней мере, для любых проектов, которые взаимодействуют с Life Cycle Services (LCS).

Необходимо зайти на сайт https://www.visualstudio.com, чтобы зарегистрироваться в Visual Studio Online. Указанное при регистрации имя учетной записи будет частью URL-адреса, который будет использоваться для доступа ко всем проектам.

Создание проекта в Visual Studio

Теперь создадим проект. Назовем его Ax7Experimentation.

    

Далее необходимо подключить «Visual Studio» к проекту и продолжать оттуда.

Запускаем «Visual Studio» под администратором, идем в меню «Team» и выбираем «Manage Connections». Откроется «Team Explorer».

Нажимаем «Connect»

Указываем адрес, состоящий из имени учетной записи, которую мы указывали при регистрации и доменного имени. Выбираем созданный проект и нажимаем «Connect».

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

Для этого нажимаем на «Configure your workspaces», после чего необходимо указать путь к директории, где будет хранится код. Для работы D365 эта папка будет содержать только проекты и сам код. Все артефакты метаданных Dynamics будут находиться в другой папке.

Создадим папку AxTFS и выберем ее.

Нажимаем «Map&Get».

Теперь есть локальная папка, сопоставленная с VSTO. Нажмем кнопку «Source Control Explorer», чтобы открыть проводник. Здесь закончим сопоставления рабочей области и создадим начальные необходимые папки. Создадим папки Trunk и Main. В Main будут храниться файлы, относящиеся к проектам Visual Studio, в ней создадим папку Projects.

Последнее, необходимо указать VSTS, где хранить файлы метаданных D365. Эти файлы находятся в папке, контролируемой службой AOS: «C:\AOSService».

Для этого в директории «Main» создадим еще одну поддиректорию «Metadata». Теперь ее необходимо сопоставить с локальной директорией «AOSService\PackagesLocalDirectory». Для этого идем в «Workspace» и добавляем новую строку, в которой указываем директорию «Metadata» и локальную директорию метаданных.

Далее возвращаем ожидающие файлы в хранилище системы контроля и конвертируем директорию «Main» в ветвь. Для этого вызываем ее контекстное меню, идем в подменю «Branching and Merging» и выбираем «Convert to Branch».

Новый проект D365 должен хранится в директории «Projects», управляемой VSTS. Созданное сопоставление метаданных папок позволит «Visual Studio» создавать элементы проекта в правильном месте и при этом добавлять их в систему управления версиями.

 

Axforum

Version Control System

TFS workspaces in AX2012

Shared vs Isolated AX

TFS is destroying your development capacity

Comments

So empty here ... leave a comment!

Добавить комментарий

Sidebar