Управление Версиями В Ultima Businessware

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

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

Что, однако, позволяет нам (с нашей точки зрения) претендовать на лавры первопроходцев в этой области.



Анамнез

В первая версия платформы Не было поддержки версий.

Если вы не читали предыдущие статьи в этом блоге, то вам следует прочитать бриф.

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

Но оно может быть еще короче.

Предметная область описывается с помощью справочников, таблиц связей, документов (для отражения процессов или событий в предметной области), итогов (некий аналог счета для бухгалтеров, регистров в 1С или кубов в OLAP) и скриптов, обрабатывающих различные события, которые создавать, изменять или удалять бизнес-объекты, перечисленные выше.

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



Управление версиями в Ultima Businessware

Замечательный механизм мгновенной доставки ошибок пользователям.



Управление версиями в Ultima Businessware

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

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

Итак, решением было сделать 2 версии скриптов — для разработчиков и для пользователей.

Довольно быстро туда добавили третью версию — для тестирования.



Управление версиями в Ultima Businessware

Однако это, конечно, коренным образом проблему не решило.

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



Управление версиями в Ultima Businessware

Разрабатывая новую версию, мы принципиально решили отказаться от костылей и реализовать полноценный механизм.



Управление версиями в Ultima Businessware

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

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

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

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

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

Чтобы не быть голословным, приведу скриншот приложения:

Управление версиями в Ultima Businessware

Каждый разработчик (или администратор развертывания, как бы коряво это ни звучало по-русски) может видеть, что было сделано, кем и когда.

На следующей вкладке вы можете увидеть, какие изменения были внесены:

Управление версиями в Ultima Businessware

Последняя вкладка для разрешения конфликтов должна быть знакома тем, кто использует системы контроля версий, такие как Mercurial. Также мы добавили все механизмы сравнения объектов разных версий:

Управление версиями в Ultima Businessware

Больше не буду загромождать текст скриншотами, все необходимые механизмы есть.

Также мы связали все изменения с системой CRM (Change Request Management) и теперь вы можете видеть, что было сделано и почему, или, наоборот, перейти от изменения к соответствующему запросу на изменение (подойдет любая система с веб-интерфейсом) .

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

Например, мониторинг доступности передачи ресурсов.

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

Мы сделали следующую проверку: при отправке ветки изменений по умолчанию, если не все ресурсы были переведены, разработчик получит сообщение.

Этого оказалось недостаточно, поэтому мы подключили проект Roslyn для анализа скриптов.

Если в скрипте есть строки, не замененные переведенными ресурсами, разработчик также получит сообщение.

Что еще — интегрированные встроенные юнит-тесты, система контроля версий и Team City. Внедрение встроенной системы контроля версий позволило существенно упростить и автоматизировать внутренние процессы разработки.



Итого, что дает интеграция системы контроля версий в платформу:

  1. Количество ошибок из-за одновременных изменений скриптов или структуры метаданных резко сократилось.

  2. Повысилась прозрачность и предсказуемость процесса разработки и тестирования (известно, какой функционал реализован, кто заказал функционал и т.д.)
  3. Количество срочных запросов уменьшилось.

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

Теги: #ERP-системы #проектирование #ERP-системы

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.