Поставка, тестирование и сопровождение

Поставка, тестирование и сопровождение#

Подробные правила организации разработки, релизов, Git, миграций и оптимизации кода описаны в общих разделах документации. На этой странице фиксируются проектные требования: что должно быть воспроизводимо, что проверяется на ревью и какие действия нельзя выполнять при проектной поставке.

DataInstall и миграции#

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

Для этого используются поддерживаемые механизмы установки данных, DataInstall или миграции.

В типовой поставке Global ERP могут использоваться стандартные DataInstall-скрипты, которые устанавливают базовые справочники, настройки и служебные данные по умолчанию.

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

Через воспроизводимые скрипты рекомендуется переносить:

  • проектные классы и таблицы;

  • характеристики, если они регистрируются кодом;

  • настройки печатных форм;

  • начальные значения проектных справочников;

  • настройки интеграций;

  • проектные настройки типов объектов;

  • права и административные объекты, если это предусмотрено проектом;

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

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

Требования к скриптам установки данных#

Скрипты установки данных должны быть:

  • идемпотентными;

  • версионированными;

  • привязанными к проектному модулю;

  • понятными по назначению;

  • безопасными при повторном запуске;

  • проверенными на тестовом экземпляре.

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

Миграционные пакеты проектного модуля#

Если проектный модуль требует установки первичных данных или выполнения миграции данных через Scala-код, для него создается миграционный пакет.

Миграционный пакет именуется по шаблону:

<ИмяМодуля>_MigratePkg

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

Проектные миграционные задачи должны использоваться для воспроизводимого переноса изменений между экземплярами системы, если изменение нельзя надежно перенести только через интерфейсную настройку или SQL-скрипт.

В миграционных пакетах допустимо размещать:

  • создание или изменение проектных справочников;

  • регистрацию проектных настроек;

  • установку начальных данных проектного модуля;

  • изменение структуры данных, требующее прикладной логики;

  • перенос данных между старой и новой проектной структурой.

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

Права доступа#

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

При разработке нужно проверить:

  • нужен ли административный объект;

  • какие роли или профили должны иметь доступ;

  • какие операции доступны пользователю;

  • кто может просматривать данные;

  • кто может изменять данные;

  • кто может запускать печатные формы и отчеты;

  • кто может выполнять сервисные операции.

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

Аудит#

Для проектных сущностей необходимо определить, требуется ли аудит.

Аудит следует включать, если объект содержит:

  • критичные бизнес-данные;

  • данные, влияющие на финансовые или учетные процессы;

  • настройки прав или маршрутов согласования;

  • интеграционные настройки;

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

Система контроля версий#

Проектный код должен храниться в системе контроля версий.

Каждое изменение должно быть связано с задачей или основанием изменения.

В репозиторий не должны попадать:

  • локальные настройки разработчика;

  • временные файлы;

  • выгрузки пользовательских данных;

  • секреты, пароли и токены;

  • файлы, не относящиеся к проектной поставке.

Ветки и ревью#

Разработка выполняется в отдельной ветке.

Перед включением изменений в основную ветку требуется ревью.

На ревью проверяется:

  • соответствие проектному именованию и общим правилам именования GlobalFramework;

  • отсутствие изменений типовой поставки без согласования;

  • корректность выбора способа проектной доработки;

  • отсутствие дублирования стандартной логики;

  • корректность работы с БД и транзакциями;

  • наличие тестирования;

  • наличие описания изменения.

Проверка производительности при ревью#

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

Проверяется:

  • как часто вызывается проектный код;

  • выполняются ли запросы внутри циклов;

  • можно ли заменить пообъектную обработку пакетной;

  • используется ли кэширование там, где оно оправдано;

  • учитываются ли реальные объемы данных на продуктивной среде;

  • нет ли лишней загрузки ROP-объектов;

  • нет ли копирования больших объектов в память без необходимости;

  • разделена ли логика Avi и Api;

  • не размещена ли сложная бизнес-логика в интерфейсном слое;

  • используются ли стандартные сервисы GSF вместо самописных обходных решений.

Если проектная доработка содержит SQL-запросы, дополнительно проверяется:

  • не используется ли SELECT *;

  • совпадают ли типы сравниваемых значений и колонок;

  • нет ли функций над индексируемыми колонками в условиях фильтрации;

  • нет ли небезопасной конкатенации SQL-строк;

  • передаются ли значения через параметры;

  • нет ли SQL-запросов внутри вложенных циклов;

  • проверен ли план выполнения для тяжелых запросов;

  • обоснованы ли индексы, сортировки, DISTINCT, GROUP BY и JOIN;

  • учитывается ли поведение запроса на больших объемах данных.

Релиз#

Релиз — это установка проектных изменений на экземпляр системы для тестирования или эксплуатации.

В состав релиза должны входить:

  • версии проектных модулей;

  • список задач;

  • описание изменений;

  • инструкции по установке;

  • перечень миграций и DataInstall-скриптов;

  • перечень ручных действий, если они неизбежны;

  • инструкция по проверке результата;

  • список рисков и обратимых действий.

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

Минимальный набор проверок#

Для каждой проектной доработки необходимо проверить:

  • создание и редактирование данных;

  • сохранение и откат транзакций;

  • работу обязательных атрибутов;

  • работу прав доступа;

  • работу печатных форм;

  • работу JEXL-скриптов;

  • работу универсального фильтра, если добавлены новые атрибуты;

  • работу интеграций, если изменены интеграционные данные;

  • перенос изменений на другой экземпляр;

  • отсутствие ошибок в логах.

Регрессионное тестирование#

Регрессионное тестирование обязательно, если доработка:

  • переопределяет типовую логику;

  • меняет поведение базового справочника или документа;

  • добавляет атрибуты, участвующие в отчетах или интеграциях;

  • меняет права доступа;

  • влияет на печатные формы;

  • меняет переходы состояний;

  • затрагивает массовые операции.

Документирование проектных изменений#

Для каждой проектной доработки должно быть описание, достаточное для сопровождения.

Описание должно включать:

  • назначение доработки;

  • список созданных или измененных объектов;

  • способ реализации;

  • правила именования использованных сущностей;

  • настройки, которые нужно перенести между экземплярами;

  • влияние на права доступа;

  • влияние на отчеты и печатные формы;

  • влияние на интеграции;

  • инструкцию по проверке;

  • ограничения и известные особенности.

Если доработка реализована через проектное переопределение, необходимо отдельно указать:

  • какой типовой объект переопределен;

  • какой метод переопределен;

  • почему не использована настройка или точка расширения;

  • какие риски есть при обновлении типовой поставки.

Запрещенные практики#

Запрещено:

  • изменять типовой код без согласования;

  • изменять доменные файлы, которые перезаписываются кодогенератором;

  • добавлять физические колонки в БД в обход ODM/миграций;

  • использовать системный суффикс _dz для проектных атрибутов;

  • создавать проектные объекты с именами, похожими на типовые;

  • копировать типовую логику целиком без анализа;

  • использовать JEXL для большой и критичной бизнес-логики;

  • хранить пароли, токены и секреты в коде, JEXL-скриптах или настройках без защищенного механизма;

  • выполнять Generate Tables Force по папке модуля или application;

  • переносить настройки вручную без фиксации способа воспроизведения;

  • выпускать релиз без списка изменений и инструкции проверки;

  • использовать SELECT * в проектных SQL-запросах без необходимости;

  • выполнять SQL-запросы внутри вложенных циклов;

  • формировать SQL через небезопасную конкатенацию пользовательских значений;

  • использовать функции над индексируемыми колонками в условиях фильтрации без анализа влияния на индекс;

  • допускать неявные приведения типов в критичных SQL-условиях.

Чек-лист проектного разработчика#

Перед реализацией:

  • требование проверено на возможность настройки без кода;

  • выбран способ реализации;

  • определено, нужен ли новый класс, характеристика или переопределение;

  • выбран проектный модуль;

  • проверены правила именования;

  • определено влияние на права, аудит, отчеты и интеграции.

При разработке:

  • проектные объекты созданы с проектным префиксом;

  • проектные атрибуты имеют суффикс _z;

  • системный суффикс _dz не используется;

  • ручной код не размещен в генерируемых доменных файлах;

  • настройки переноса оформлены воспроизводимо;

  • JEXL не содержит избыточной логики;

  • SQL-запросы параметризованы;

  • тяжелые запросы проверены на больших объемах данных.

Перед передачей на ревью:

  • код собран;

  • изменения проверены на тестовом экземпляре;

  • выполнены основные сценарии тестирования;

  • подготовлено описание изменения;

  • зафиксированы миграции и DataInstall-скрипты;

  • указаны ручные действия, если они есть;

  • проверено отсутствие конфликтов имен.

Перед релизом:

  • сформирован состав поставки;

  • подготовлена инструкция установки;

  • подготовлена инструкция проверки;

  • определен порядок отката или восстановления;

  • выполнено регрессионное тестирование затронутых процессов.

Содержание