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