Версіонування в Ultima Businessware

У цій статті розповімо, які є механізми для організації групової роботи нашої платформі.
Проблеми, загальні для всіх груп розробників, сложнообъяснимым причин знаходяться на третьому плані важливості в ERP системах, де, здавалося б, якість і надійність коду повинні бути поставлені на чільне місце.
Що, втім, дозволяє нам (з нашої точки зору) претендувати на лаври піонерів в даній області.

Анамнез

першої версії платформи підтримка версионирования була відсутня.

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

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

Відповідно, будь-які зміни в структурі об'єктів або код скриптів негайно ставали доступні всім, включаючи користувачів системи.

Чудовий механізм миттєвої доставки помилок користувачам.

Трохи помучившись, і переконавшись, що писати зовсім без помилок не виходить, вирішили обмежитися милицями.

Справедливості заради, треба сказати, що це був час, коли легко приделываемые милиці мали перевагу перед складного механізму, зважаючи на неймовірно стислі терміни.
Отже, рішення полягало в тому, щоб зробити 2 версії для скриптів для розробників і для користувачів. Досить швидко туди додалася третя версія — для тестування.

Однак принципово проблему це, звісно, не вирішило.
Хоча помилки перестали миттєво потрапляти до користувачів, конфлікти при одночасному зміні кількома розробниками нікуди не поділися.

Займаючись розробкою нової версії, ми принципово вирішили відмовитися від милиць і реалізувати повнофункціональний механізм.

Ми ввели поняття конфігурації, як всієї спільності бізнес-об'єктів, скриптів і іншого і впровадили в платформу розподілену систему контролю версій конфігурацій. Відповідно, кожен розробник вносить зміни у своїй гілці, не зачіпаючи інших розробників або користувачів. Відповідно, все його зміни відбуваються у контрольованій і стабільній середовищі, що значно знижує ймовірність виникнення «несподіваних» помилок. Таким чином, всі версії утворюють дерево версій конфігурацій, кожна з яких містить закінчений (ну хоча б на думку розробника) набір змін. У системі реалізовані всі механізми для затягування змін з дефолтної (користуючись термінологією Mercurial) гілки, пропихивания змін на дефолтну гілку. Щоб не бути голослівним, наведу скріншот додатка:

Кожен розробник (або адміністратор розгортання, як би кургузо не звучало це російською), може подивитися, ким і коли було зроблено. На наступній закладці можна подивитися які зміни були внесені:

Остання закладка для вирішення конфліктів, повинна бути знайома тим, хто користується системами контролю версій типу Mercurial. Ми так само зробили всі механізми порівняння об'єктів різних версій:

Не буду більше засмічувати текст скріншотами, всі необхідні механізми є.

Ще ми прив'язали всі зміни до CRM (Change Request Management) системі, і тепер можна подивитися, що було зроблено і для чого, або, навпаки, перейти від зміни до відповідної заявці на зміну (підійде будь-яка система з web-інтерфейсом).

Взагалі, інтеграція системи контролю версій в платформу дозволяє виконувати багато корисних трюків. Наприклад — контроль наявності перекладів ресурсів. Конфігурація поставляється з підтримкою російської та англійської мов, і, відповідно, потрібна для всіх ресурсів мати переклади на російську та англійську мови відповідно. Ми зробили таку перевірку — при пропихивании на default гілку змін, якщо не всі ресурси переведені, розробник отримає повідомлення. Цього було замало, тому ми прикрутили Roslyn project для аналізу скриптів. Якщо в скрипті, є рядки не замінені перекладними ресурсами, розробник так само отримає повідомлення.

Що ще — інтегрували вбудовані unit-тести, систему контролю версій і Team City.

Реалізація вбудованої системи контролю версій дозволила значно спростити і автоматизувати внутрішні процеси розробки.

Разом, що дає інтеграція системи контролю версій в платформу:

  1. Різко скоротилася кількість помилок за одночасного зміни скриптів або структури метаданих.
  2. Підвищилася прозорість і прогнозованість процесу розробки і тестування (відомо який функціонал реалізований, ким був замовлений функціонал та інше)
  3. Знизилася кількість термінових звернень.
Нині часи, коли були відсутні вбудовані механізми UNIT-тестування, розділені версії для розробників, коментування і тегів змін, прив'язки змін до заявок на зміну не було, згадуються як кошмар Хаосу.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.