В этой статье мы расскажем вам, какие существуют механизмы организации групповой работы в наша платформа .
Проблемы, общие для всех групп разработчиков, по труднообъяснимым причинам отходят на третье место в ERP-системах, где, казалось бы, качество и надежность кода должны ставиться на первый план.
Что, однако, позволяет нам (с нашей точки зрения) претендовать на лавры первопроходцев в этой области.
Анамнез
В первая версия платформы Не было поддержки версий.Если вы не читали предыдущие статьи в этом блоге, то вам следует прочитать бриф.
вводный В принципе все написано выдержка из документации для разработчиков, размещенной на сайте .
Но оно может быть еще короче.
Предметная область описывается с помощью справочников, таблиц связей, документов (для отражения процессов или событий в предметной области), итогов (некий аналог счета для бухгалтеров, регистров в 1С или кубов в OLAP) и скриптов, обрабатывающих различные события, которые создавать, изменять или удалять бизнес-объекты, перечисленные выше.
Соответственно, любые изменения в структуре объектов или коде скрипта сразу же становились доступными всем, включая пользователей системы.
Замечательный механизм мгновенной доставки ошибок пользователям.
Немного помучавшись и убедившись, что без ошибок писать вообще невозможно, мы решили ограничиться костылями.
Справедливости ради надо сказать, что это было время, когда сложному механизму предпочитали легко прикрепляемые костыли из-за невероятно сжатых сроков.
Итак, решением было сделать 2 версии скриптов — для разработчиков и для пользователей.
Довольно быстро туда добавили третью версию — для тестирования.
Однако это, конечно, коренным образом проблему не решило.
Хотя ошибки больше не доходят до пользователей мгновенно, конфликты с одновременными изменениями нескольких разработчиков никуда не делись.
Разрабатывая новую версию, мы принципиально решили отказаться от костылей и реализовать полноценный механизм.
Мы ввели понятие конфигурации как всего сообщества бизнес-объектов, скриптов и т. д., а также внедрили в платформу распределенную систему контроля версий конфигурации.
Соответственно, каждый разработчик вносит изменения в свою ветку, не затрагивая других разработчиков или пользователей.
Соответственно, все его изменения происходят в контролируемой и стабильной среде, что существенно снижает вероятность «неожиданных» ошибок.
Таким образом, все версии образуют дерево версий конфигурации, каждая из которых содержит полный (ну, по крайней мере, по мнению разработчика) набор изменений.
В системе реализованы все механизмы задержки изменений из ветки по умолчанию (используя терминологию Mercurial), перенося изменения в ветку по умолчанию.
Чтобы не быть голословным, приведу скриншот приложения:
Каждый разработчик (или администратор развертывания, как бы коряво это ни звучало по-русски) может видеть, что было сделано, кем и когда.
На следующей вкладке вы можете увидеть, какие изменения были внесены:
Последняя вкладка для разрешения конфликтов должна быть знакома тем, кто использует системы контроля версий, такие как Mercurial. Также мы добавили все механизмы сравнения объектов разных версий:
Больше не буду загромождать текст скриншотами, все необходимые механизмы есть.
Также мы связали все изменения с системой CRM (Change Request Management) и теперь вы можете видеть, что было сделано и почему, или, наоборот, перейти от изменения к соответствующему запросу на изменение (подойдет любая система с веб-интерфейсом) .
В общем, интеграция системы контроля версий в платформу позволяет сделать много полезных трюков.
Например, мониторинг доступности передачи ресурсов.
В конфигурации предусмотрена поддержка русского и английского языков, и, соответственно, все ресурсы должны иметь переводы на русский и английский языки соответственно.
Мы сделали следующую проверку: при отправке ветки изменений по умолчанию, если не все ресурсы были переведены, разработчик получит сообщение.
Этого оказалось недостаточно, поэтому мы подключили проект Roslyn для анализа скриптов.
Если в скрипте есть строки, не замененные переведенными ресурсами, разработчик также получит сообщение.
Что еще — интегрированные встроенные юнит-тесты, система контроля версий и Team City. Внедрение встроенной системы контроля версий позволило существенно упростить и автоматизировать внутренние процессы разработки.
Итого, что дает интеграция системы контроля версий в платформу:
- Количество ошибок из-за одновременных изменений скриптов или структуры метаданных резко сократилось.
- Повысилась прозрачность и предсказуемость процесса разработки и тестирования (известно, какой функционал реализован, кто заказал функционал и т.д.)
- Количество срочных запросов уменьшилось.
Теги: #ERP-системы #проектирование #ERP-системы
-
Red Hat Linux Впервые Представила Локкит
19 Oct, 24 -
Как Я Могу Исправить Бюджет Веб-Хостинга?
19 Oct, 24 -
Эйткен, Роберт Грант
19 Oct, 24 -
«Отзывы — Это Лайки Для Бизнеса»
19 Oct, 24 -
Я Из Морейниса. Косые Взгляды Или Уважение?
19 Oct, 24 -
Профилировщик Приборов Своими Руками
19 Oct, 24