В этой статье расскажем, какие есть механизмы для организации групповой работы в нашей платформе.
Проблемы, общие для всех групп разработчиков, по сложнообъяснимым причинам находятся на третьем плане важности в ERP системах, где, казалось бы, качество и надежность кода должны быть поставлены во главу угла.
Что, впрочем, позволяет нам (с нашей точки зрения) претендовать на лавры первопроходцев в данной области.
В первой версии платформы поддержка версионирования отсутствовала.
Если вы не читали предыдущих статей этого блога, то стоит ознакомиться с краткой
Соответственно, любые изменения в структуре объектов или коде скриптов немедленно становились доступны всем, включая пользователей системы.
Замечательный механизм мгновенной доставки ошибок пользователям.
Немного помучавшись, и убедившись, что писать совсем без ошибок не получается, решили ограничиться костылями.
Справедливости ради, надо сказать, что это было время, когда легко приделываемые костыли предпочитались сложному механизму, ввиду невероятно сжатых сроков.
Итак, решение заключалось в том, чтобы сделать 2 версии для скриптов — для разработчиков и для пользователей. Достаточно быстро туда добавилась третья версия — для тестирования.
Однако, принципиально проблему это, конечно, не решило.
Хотя ошибки перестали мгновенно попадать к пользователям, конфликты при одновременном изменении несколькими разработчиками никуда не делись.
Занимаясь разработкой новой версии, мы принципиально решили отказаться от костылей и реализовать полнофункциональный механизм.
Мы ввели понятие конфигурации, как всей общности бизнес-объектов, скриптов и прочего и внедрили в платформу распределенную систему контроля версий конфигураций. Соответственно, каждый разработчик вносит изменения в своей ветке, не затрагивая других разработчиков или пользователей. Соответственно, все его изменения происходят в контролируемой и стабильной среде, что значительно снижает вероятность возникновения “неожиданных” ошибок. Таким образом, все версии образуют дерево версий конфигураций, каждая из которых содержит законченный (ну хотя бы по мнению разработчика) набор изменений. В системе реализованы все механизмы для затягивания изменений из дефолтной (пользуясь терминологией Mercurial) ветки, пропихивания изменений на дефолтную ветку. Чтобы не быть голословным, приведу скриншот приложения:
Каждый разработчик (или администратор развертывания, как бы кургузо не звучало это на русском), может посмотреть что, кем и когда было сделано. На следующей закладке можно посмотреть какие изменения были внесены:
Последняя закладка для разрешения конфликтов, должна быть знакома тем, кто пользуется системами контроля версий типа Mercurial. Мы так же приделали все механизмы сравнения объектов разных версий:
Не буду больше засорять текст скриншотами, все необходимые механизмы есть.
Еще мы привязали все изменения к CRM (Change Request Management) системе, и теперь можно посмотреть что было сделано и для чего, или, наоборот, перейти от изменения к соответствующей заявке на изменение (подойдет любая система c web-интерфейсом).
Вообще, интеграция системы контроля версий в платформу позволяет проделывать много полезных трюков. Например — контроль наличия переводов ресурсов. Конфигурация поставляется с поддержкой русского и английского языков, и, соответственно, требуется для всех ресурсов иметь переводы на русский и английский языки соответственно. Мы сделали такую проверку — при пропихивании на default ветку изменений, если не все ресурсы переведены, разработчик получит сообщение. Этого было мало, поэтому мы прикрутили Roslyn project для анализа скриптов. Если в скрипте, есть строки не замененные переводимыми ресурсами, разработчик так же получит сообщение.
Что еще — интегрировали встроенные unit-тесты, систему контроля версий и Team City.
Реализация встроенной системы контроля версий позволила значительно упростить и автоматизировать внутренние процессы разработки.
Ныне времена, когда отсутствовали встроенные механизмы UNIT-тестирования, разделенные версии для разработчиков, комментирования и тегирования изменений, привязки изменений к заявкам на изменение не было, вспоминаются как кошмар Хаоса.
Проблемы, общие для всех групп разработчиков, по сложнообъяснимым причинам находятся на третьем плане важности в ERP системах, где, казалось бы, качество и надежность кода должны быть поставлены во главу угла.
Что, впрочем, позволяет нам (с нашей точки зрения) претендовать на лавры первопроходцев в данной области.
Анамнез
В первой версии платформы поддержка версионирования отсутствовала.
Если вы не читали предыдущих статей этого блога, то стоит ознакомиться с краткой
вводной
В принципе, все написано в выжимке из документации для разработчиков, размещенной на сайте.
Но можно еще короче.
Предметная область описывается с помощью справочников, развязочных таблиц, документов (для отражения процессов или событий в предметной области), итогов (некоторого аналога счета для бухгалтеров, регистров в 1С или кубов в OLAP) и скриптов-обработчиков различных событий, которые создают, изменяют или удаляют перечисленные выше бизнес-объекты.
Но можно еще короче.
Предметная область описывается с помощью справочников, развязочных таблиц, документов (для отражения процессов или событий в предметной области), итогов (некоторого аналога счета для бухгалтеров, регистров в 1С или кубов в OLAP) и скриптов-обработчиков различных событий, которые создают, изменяют или удаляют перечисленные выше бизнес-объекты.
Соответственно, любые изменения в структуре объектов или коде скриптов немедленно становились доступны всем, включая пользователей системы.
Замечательный механизм мгновенной доставки ошибок пользователям.
Немного помучавшись, и убедившись, что писать совсем без ошибок не получается, решили ограничиться костылями.
Справедливости ради, надо сказать, что это было время, когда легко приделываемые костыли предпочитались сложному механизму, ввиду невероятно сжатых сроков.
Итак, решение заключалось в том, чтобы сделать 2 версии для скриптов — для разработчиков и для пользователей. Достаточно быстро туда добавилась третья версия — для тестирования.
Однако, принципиально проблему это, конечно, не решило.
Хотя ошибки перестали мгновенно попадать к пользователям, конфликты при одновременном изменении несколькими разработчиками никуда не делись.
Занимаясь разработкой новой версии, мы принципиально решили отказаться от костылей и реализовать полнофункциональный механизм.
Мы ввели понятие конфигурации, как всей общности бизнес-объектов, скриптов и прочего и внедрили в платформу распределенную систему контроля версий конфигураций. Соответственно, каждый разработчик вносит изменения в своей ветке, не затрагивая других разработчиков или пользователей. Соответственно, все его изменения происходят в контролируемой и стабильной среде, что значительно снижает вероятность возникновения “неожиданных” ошибок. Таким образом, все версии образуют дерево версий конфигураций, каждая из которых содержит законченный (ну хотя бы по мнению разработчика) набор изменений. В системе реализованы все механизмы для затягивания изменений из дефолтной (пользуясь терминологией Mercurial) ветки, пропихивания изменений на дефолтную ветку. Чтобы не быть голословным, приведу скриншот приложения:
Каждый разработчик (или администратор развертывания, как бы кургузо не звучало это на русском), может посмотреть что, кем и когда было сделано. На следующей закладке можно посмотреть какие изменения были внесены:
Последняя закладка для разрешения конфликтов, должна быть знакома тем, кто пользуется системами контроля версий типа Mercurial. Мы так же приделали все механизмы сравнения объектов разных версий:
Не буду больше засорять текст скриншотами, все необходимые механизмы есть.
Еще мы привязали все изменения к CRM (Change Request Management) системе, и теперь можно посмотреть что было сделано и для чего, или, наоборот, перейти от изменения к соответствующей заявке на изменение (подойдет любая система c web-интерфейсом).
Вообще, интеграция системы контроля версий в платформу позволяет проделывать много полезных трюков. Например — контроль наличия переводов ресурсов. Конфигурация поставляется с поддержкой русского и английского языков, и, соответственно, требуется для всех ресурсов иметь переводы на русский и английский языки соответственно. Мы сделали такую проверку — при пропихивании на default ветку изменений, если не все ресурсы переведены, разработчик получит сообщение. Этого было мало, поэтому мы прикрутили Roslyn project для анализа скриптов. Если в скрипте, есть строки не замененные переводимыми ресурсами, разработчик так же получит сообщение.
Что еще — интегрировали встроенные unit-тесты, систему контроля версий и Team City.
Реализация встроенной системы контроля версий позволила значительно упростить и автоматизировать внутренние процессы разработки.
Итого, что дает интеграция системы контроля версий в платформу:
- Резко сократилось количество ошибок из-за одновременного изменения скриптов или структуры метаданных.
- Повысилась прозрачность и прогнозируемость процесса разработки и тестирования (известно какой функционал реализован, кем был заказан функционал и прочее)
- Снизилось количество срочных обращений.
Ныне времена, когда отсутствовали встроенные механизмы UNIT-тестирования, разделенные версии для разработчиков, комментирования и тегирования изменений, привязки изменений к заявкам на изменение не было, вспоминаются как кошмар Хаоса.