Использование контроля версий для разработки в ERP-системе MS Dynamics AX — вещь довольно спорная.
Кто-то им вообще не пользуется, кто-то использует встроенную систему контроля версий MorphX. Меня зовут Игорь Глухов, я разработчик MS Dynamics AX в Lamoda. В этой статье будет рассказано о том, как мы начали использовать Team Foundation Server и Azure DevOps для контроля версий в Dynamics AX 2012 и как мы начали использовать контроль версий для подготовки выпуска.
Ниже я расскажу вам все подробности:
- История изменений: с чего мы начинали;
- Контроль версий: синхронизация и подключение среды разработки;
- Подключение Test и Prerelease к контролю версий;
- Как сейчас собирается релиз и какие результаты были получены на выходе.
История изменений: с чего мы начинали Начнем с того, что раньше мы разрабатывали в одной общей среде разработки.
Для выполнения одной модификации необходимо было внести изменения в системные объекты (таблицы, классы, формы и т.п.
), группирующие проект. Для нас один проект в Axapta — это одна модификация.
Весь код, который был разработан в рамках проекта, был помечен комментарием с названием проекта.
Эта концепция не отслеживала историю изменения объекта.
Если мы забывали указать комментарий или ставили название не того проекта, то было сложно определить, к какой задаче относится код. Также мы переносили модификации между приложениями с помощью проектов.
Процесс оказался трудоемким и требовал внимательности: нужно было сравнивать все объекты внутри проекта и брать только тот код, который относится к текущему проекту.
В результате миграция крупных проектов может занять более 30 минут. А в релизе с 20-30 проектами это занимало уже 8 часов, а иногда и больше.
Чтобы избавиться от этих проблем, мы решили: 1. Внедрить систему контроля версий для отслеживания истории изменений объекта, 2. Ускорить процесс переноса модификаций и сборки релиза.
Контроль версий: синхронизация и подключение среды разработки Система контроля версий была выбрана по следующим критериям:
- Поддержка встроенными инструментами Axapta без настройки.
- Простота установки и обслуживания.
- Функционал позволит реализовать новый процесс передачи модификаций.
Идея использования Azure DevOps нам показалась более привлекательной: она позволяет создать репозиторий того же TFS, и не требует отдельной настройки и администрирования самого сервера.
Давайте подробнее рассмотрим, как выглядит процесс синхронизации в приложении Axapta с выбранным контролем версий.
Последовательность шагов:
- Сначала мы создаем локальный файловый каталог для хранения объектов Axapta в виде файлов.
- Далее создаем репозиторий контроля версий, организуем там новую директорию разработки для сохранения наших изменений, а также настраиваем ее в приложении.
- Синхронизация запускается из Axapta и инициирует сравнение версии файла в локальном каталоге с версией объекта, который находится в репозитории.
- При появлении новых объектов или других изменений в репозитории сначала обновляется локальный каталог файлов, а затем он синхронизируется с приложением Axapta.
Это связано с тем, что синхронизируется около 20 тысяч объектов: сначала с каталогом файлов, затем с приложением.
Дальнейшая синхронизация занимает 10-15 минут. За это время обновляются только те изменения, которые мы внесли в контроль версий с момента последнего обновления.
Стандартная схема подключения к контролю версий подразумевает наличие одного приложения и одной локальной файловой директории для синхронизации с контролем версий.
Мы внесли изменение в стандарт Axapta и добавили возможность работы в одном Dev-приложении с несколькими файловыми каталогами с возможностью запуска синхронизации для каждого разработчика.
В процессе работы мы заметили, что появились конфликты синхронизации.
Это привело к потере кода.
Поэтому мы решили вернуться к стандартной схеме Axapta, которая имеет одно приложение, одну файловую директорию и одну директорию контроля версий.
Для каждого разработчика мы развернули отдельную виртуальную машину, настроили для них индивидуальные среды разработки и еще раз сделали первоначальную настройку локальных каталогов и репозитория контроля версий.
Теперь мы смогли отслеживать изменения объектов, эта схема была отлажена и сбоев больше не было.
После внедрения контроля версий мы рассмотрели новую версию системы Dynamics 365, где релиз строится путем переноса наборов изменений в Visual Studio, и решили попробовать сделать то же самое.
С появлением контроля версий в TFS мы получили доступ к таким элементам, как:
- Набор изменений — это набор изменений объекта, хранящихся в системе контроля версий.
- Рабочий элемент — это задача, которая может объединять несколько наборов изменений.
В новой концепции мы отошли от идеи, что одна задача — это один проект, к идее, что одна задача — это один рабочий элемент.Подключение Test к каталогу контроля версий Dev Поскольку все модификации тестируются в Тестовом приложении, код для релизов следует брать из него.
Это означает, что Test также нужно было подключить к контролю версий.
Мы рассмотрели несколько вариантов подключения с их плюсами и минусами и выбрали тот, в котором тестовое приложение подключается к тому же каталогу управления версиями Dev, что и все DevBoxes. Таким образом, все объекты в системе контроля версий становятся общими для всех DevBox и тестового приложения.
Все изменения, внесенные в DevBoxes и загруженные в систему контроля версий, также будут включены в тестовое приложение.
Перед подключением мы проделали подготовительную работу:
- В нашем случае из-за потери кода на Dev возникли различия между приложениями Dev и Test. Поэтому необходимо было их выровнять, чтобы после подключения Test к Dev-контролю и запуска синхронизации отличающийся код не терялся.
- Также необходимо было реализовать вход в Axapta для пользователей, не имеющих учетной записи TFS (это бизнес-пользователи и консультанты), и внести другие мелкие доработки.
Однако при подключении нескольких локальных папок объекты обновлялись только в одной директории.
Если бы каждый разработчик запускал синхронизацию, объекты загружались бы неоднократно, увеличивая нагрузку на систему и риск ошибок или сбоев.
Мы решили создать отдельный технический аккаунт, создали для него локальную директорию и организовали под этим пользователем запуск клиента Axapta с автоматическим запуском синхронизации контроля версий.
Таким образом, каждый разработчик смог запустить синхронизацию.
Он всегда работает под одним пользователем, и нам нужен только один локальный каталог.
Подключение пререлизной версии к системе контроля версий Предварительная версия — это приложение, на основе которого мы создаем выпуск.
Первые этапы настройки были выполнены в Visual Studio:
- Каталог Dev системы контроля версий был преобразован в ветку (Branch).
Это необходимо для того, чтобы в дальнейшем создать иерархию из этого каталога.
- Создана новая ветка из каталога Dev для пререлиза.
Важно было выбрать правильную дату.
В дальнейшем при переносе ревизий вы сможете увидеть только те, которые были сделаны начиная с этой даты.
- Мы получили иерархию веток из каталога Dev:
- Далее в предварительном приложении мы настроили параметры контроля версий для этой новой ветки.
- При создании иерархии веток для ветки Prerelease были скопированы все объекты в ветке Dev с версией на выбранную дату.
Но Dev и Prerelease приложения — это совершенно разные приложения, поэтому взять эти версии объектов было невозможно.
Мы удалили все созданные объекты из ветки Prerelease и начали добавлять модель usr в контроль версий.
Синхронизация контроля версий в предварительной версии В отличие от синхронизации в DevBoxes и тестовом приложении, для предварительной версии при переносе наборов изменений объекты в локальном каталоге обновляются до последней версии.
При синхронизации Axapta подтягивает только те объекты, версия которых в локальном каталоге отличается от версии в контроле версий.
В случае одного настроенного локального каталога система не найдет изменений при синхронизации и не будет ничего обновлять в приложении.
Чтобы избежать этой проблемы, мы создали отдельный локальный каталог для переноса наборов изменений.
Таким образом мы сделали две локальные папки: одну для переноса ревизий, вторую для запуска синхронизации контроля версий в Axapta. 
Как сейчас собирается релиз
Azure DevOps имеет список рабочих элементов.
Каждый рабочий элемент содержит список наборов изменений, который содержит список всех изменений, связанных с задачей.
Впервые мы использовали Visual Studio 2010, поскольку Axapta 2012 поддерживает его только для интеграции с TFS. Поскольку мы создали отдельный каталог для переноса ревизий, впоследствии мы стали использовать Visual Studio 2017.
Реальный перенос ревизий в релиз выглядит так: в Visual Studio запускаем Merge на ветке Dev. Указываем ветку Dev в качестве источника, ветку Prerelease в качестве места назначения и выбираем перенос конкретных наборов изменений.
Далее мы видим список доступных для переноса ревизий, выбираем нужный и применяем его, затем регистрируем изменения.
После переноса всех ревизий для всех задач к релизу запускаем синхронизацию с контролем версий в Axapta, чтобы подтянуть все переданные изменения в приложение.
Схематически процесс выглядит так: 
Что произошло в конце
- Теперь у нас есть контроль версий, что означает историю изменений.
- Мы ускорили и упростили перенос изменений из приложения для разработчиков в приложение для тестирования.
Если раньше на перенос большого проекта уходило 30 и более минут, то теперь изменения от всех разработчиков попадают в Тест примерно за 5-10 минут, так как нет необходимости скачивать проекты и сравнивать объекты.
Более того, мы отошли от ручной работы, и это позволило избежать ошибок, связанных с переносом или перезаписью чужого кода по невнимательности или невнимательности.
- И, самое главное, нам удалось сократить время подготовки релиза.
Если раньше на это уходило около 8-10 часов, то теперь меньше 4. Да и сам релиз стал проще, так как нет необходимости загружать и скачивать проекты, все происходит в Visual Studio.
-
Просмотр Улиц. Сейчас В Антарктиде
19 Oct, 24
