Использование контроля версий для разработки в ERP-системе MS Dynamics AX — штука довольно неоднозначная. Кто-то не использует совсем, кто-то использует встроенную систему контроля версий MorphX.

Меня зовут Игорь Глухов, я разработчик MS Dynamics AX в компании Lamoda. В этой статье речь пойдет о том, как мы начали использовать в качестве контроля версий Team Foundation Server и Azure DevOps в Dynamics AX 2012 и как стали применять контроль версий для подготовки релизов.

Ниже расскажу все подробности:

  • История изменений: с чего начали;
  • Контроль версий: синхронизация и подключение среды разработки;
  • Подключение Test и Prerelease к контролю версий;
  • Как происходит сборка релиза сейчас и какие результаты получили на выходе.

image

История изменений: с чего начали


Начнем с того, что раньше мы вели разработку в одном общем Dev-окружении. Чтобы выполнить одну модификацию, нужно было внести изменения в объекты системы (таблицы, классы, формы и прочее), которые группировали проект. Один проект в Axapta – для нас одна модификация.

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

image

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

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

В результате перенос больших проектов мог занимать более 30 минут. А в в релизе, где 20-30 проектов, это занимало уже 8 часов и иногда даже больше.

Чтобы избавиться от этих проблем, мы решили:
1. Внедрить систему контроля версий для прослеживания истории изменения объектов,
2. Ускорить процесс переноса модификаций и сборку релиза.

Контроль версий: синхронизация и подключение среды разработки


Систему контроля версий выбирали по следующим критериям:

  1. Поддержка встроенными средствами Axapta без кастомизаций.
  2. Простота установки и поддержки.
  3. Функционал позволит реализовать новый процесс переноса модификаций.

Первым выбором нашей команды был Team Foundation Server (TFS), но его настройка и поддержка требовали слишком больших трудозатрат. Более привлекательной нам показалась идея использовать Azure DevOps: он позволяет создать репозиторий того же TFS, при этом не требует отдельной настройки и администрирования самого сервера.

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

image

Последовательность шагов:

  • В начале мы создаем локальную файловую директорию для хранения объектов Axapta в виде файлов.
  • Далее заводим репозиторий контроля версий, организуем там новую директорию разработки для сохранения наших изменений и также настраиваем её в приложении.
  • Синхронизация запускается из Axapta и инициирует сравнение версии файла в локальной директории с версией объекта, который находится в репозитории.
  • Если в репозитории есть новые объекты или другие изменения, то сначала обновляется локальная файловая директория, а потом она синхронизируется с приложением Axapta.

Первоначальная синхронизация Axapta с контролем версий занимает более 3 часов. Это связано с тем, что синхронизируются порядка 20 тысяч объектов: сначала с файловой директорией, потом с приложением. Дальнейшая синхронизация – это 10-15 минут. За это время подтягиваются только те изменения, которые мы сделали в контроле версий с момента последнего обновления.

Стандартная схема подключения к контролю версий подразумевает, что есть одно приложение и одна локальная файловая директория для синхронизации с контролем версий. Мы внесли изменение в стандарт Axapta и добавили возможность работы в одном Dev-приложении с несколькими файловыми директориями с возможностью запуска синхронизации для каждого разработчика.

image

В процессе работы мы заметили, что появились конфликты синхронизаций. Это приводило к потере кода. Поэтому решили вернуться к стандартной схеме Axapta, в которой есть одно приложение, одна файловая директория и одна директория контроля версий.

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

image

Теперь мы получили возможность прослеживать изменения объектов, эта схема была отлажена и сбоев больше не возникало.

После внедрения контроля версий мы посмотрели на новую версию системы Dynamics 365, где сборка релиза происходит с помощью переноса changeset-ов в Visual Studio, и решили попробовать сделать так же.

С появлением контроля версий в TFS мы получили доступ к таким его элементам как:

  • Сhangeset – это совокупность изменений объектов, сохраненная в контроле версий.
  • Work Item – это задача, которая может объединять в себе несколько changeset-ов.

В новой концепции мы ушли от идеи, что одна задача – это один проект, к идее, что одна задача – это один Work Item.

Подключение Test к директории контроля версий Dev


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

Мы рассматривали несколько вариантов подключения со своими плюсами и минусами и выбрали такой, где приложение Test подключается к той же директории контроля версий Dev, что и все DevBox-ы.

Таким образом, все объекты в контроле версий становятся общими для всех DevBox-ов и для приложения Test. Все изменения, сделанные в DevBox-ах и выгруженные в контроль версий, будут попадать и в приложение Test.

image

Перед подключением мы сделали подготовительные работы:

  • В нашем случае из-за потерь кода на Dev были различия между приложениями Dev и Test. Следовательно, нужно было их выровнять, чтобы после подключения Test к контролю версий Dev и запуска синхронизации, отличающийся код не был потерян.
  • Также необходимо было реализовать вход в Axapta для пользователей, у которых нет учетной записи в TFS (это бизнес-пользователи и консультанты), и сделать другие небольшие доработки.

Синхронизация контроля версий в Test

Доступ к синхронизации нужен всем разработчикам, чтобы они могли переносить код. А значит, каждому пришлось бы настраивать локальную директорию.

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

Мы решили завести отдельную техническую учетную запись, для нее настроили локальную директорию и организовали запуск клиента Axapta под этим пользователем с автоматическим запуском синхронизации контроля версий. Таким образом, каждый разработчик получил возможность запускать синхронизацию. Она всегда запускается под одним пользователем, и нам нужна только одна локальная директория.

Подключение Prerelease к контролю версий


Prerelease – это приложение, на котором мы делаем сборку релиза.

Первые этапы настройки делали в Visual Studio:

  • Директорию Dev контроля версий конвертировали в ветку (Branch). Это необходимо для того, чтобы в дальнейшем создать иерархию от этой директории.

image

  • Создали новую ветку от директории Dev для Prerelease. Тут важно было правильно выбрать дату. Впоследствии при переносе changeset-ов можно видеть только те, которые были сделаны начиная с этой даты.

image

  • Получили иерархию веток от директории Dev:

image

  • Дальше в приложении Prerelease настроили параметры управления версиями на эту новую ветку.

image

  • При создании иерархии веток для ветки Prerelease скопировались все объекты ветки Dev с версией на выбранную дату. Но приложения Dev и Prerelease — это совсем разные приложения, поэтому нельзя было брать эти версии объектов. Мы удалили все созданные объекты из ветки Prerelease и запустили добавление модели usr в систему управления версиями.

image

Синхронизация контроля версий в Prerelease

В отличие от синхронизации на DevBox-ах и на приложении Test, для Prerelease при переносе changeset-ов объекты в локальной директории обновляются до последней версии. При синхронизации Axapta подтягивает только те объекты, чья версия в локальной директории отличается от версии в контроле версий. В случае с одной настроенной локальной директорией система не найдет изменений во время синхронизации и ничего не обновит в приложении. Чтобы избежать этой проблемы, мы создали отдельную локальную директорию для переноса changeset-ов. Таким образом, мы сделали две локальные папки: одна для переноса changeset-ов, вторая для запуска синхронизации контроля версий в Axapta.

image

Как происходит сборка релиза сейчас


В Azure DevOps есть список Work Item. Каждый Work Item содержит в себе список changeset-ов, где есть перечень всех изменений, относящихся к задаче.

image

image

Сначала мы использовали Visual Studio 2010, поскольку Axapta 2012 поддерживает только ее для интеграции с TFS. Так как мы создали отдельную директорию для переноса changeset-ов, то впоследствии стали использовать Visual Studio 2017.

Сам перенос changeset-ов в релиз выглядит следующим образом: в Visual Studio запускаем объединение (Merge) на ветке Dev. В качестве источника указываем ветку Dev, в качестве назначения – ветку Prerelease, и выбираем перенос конкретных changeset-ов.

image

Далее видим список changeset-ов, которые доступны для переноса, выбираем необходимый и применяем его, затем делаем check-in изменений.

image

После переноса всех changeset-ов по всем задачам к релизу запускаем синхронизацию с контролем версий в Axapta, чтобы подтянуть все перенесенные изменения в приложение.

image

Схематично процесс выглядит следующим образом:

image

Что получилось в итоге


  • У нас появился контроль версий, а значит, история доработок.
  • Мы ускорили и упростили перенос модификаций с приложения Dev на приложение Test. Если раньше на перенос большого проекта уходило 30 минут и более, то сейчас изменения всех разработчиков попадают на Test где-то за 5-10 минут, поскольку не нужно загружать проекты и сравнивать объекты. Более того, мы ушли от ручной работы, и это позволило нам избежать ошибок, связанных с переносом или затиранием чужого кода из-за неосторожности или невнимательности.
  • И, самое главное, что нам удалось уменьшить время на подготовку релиза. Если раньше на это уходило порядка 8-10 часов, то сейчас занимает менее 4. И сам релиз стал проще, поскольку не надо выгружать и загружать проекты, все происходит в Visual Studio.