Нередкая ситуация: бизнес хочет быстро вносить изменения в такие справочники, как продуктовый каталог и тарифы. Уровень критичности этих справочников — mission/business critical. Самый быстрый вариант — менять сразу на проде. Но, надо помнить что мы банк и если вносить изменения в такие справочники без тестирования, то в случае ошибки рискуешь получить страховки с комиссией в разы больше или меньше нужной, да ещё полный сбой оформления кредитных заявок. Я посвятил этот пост проблеме бизнес-справочников и предложил несколько вариантов решения, проверенных на котиках на себе. Под катом вас ждут максимум конкретики и программный код С#. <Погрузиться в изменчивый мир бизнес-справочников/> Дайте возможность бизнесу вносить изменения на проде, но с условием, что значения будут меняться в рамках заранее протестированного диапазона. То есть их должен будет подтвердить системный аналитик или тестировщик, сверив со сводным протоколом тестирования. Этот протокол можно представить как таблицу: {имя параметра, допустимый (протестированный) диапазон значений}.   У такого подхода есть свои минусы: Необходимо очень много тестировать, чтобы получить сводный протокол на все случаи. Даже количество комбинаций граничных значений всех параметров справочника будет очень большим.   Не исключён человеческий фактор. По-прежнему можно в рамках протестированного диапазона задать тариф с лишним ноликом.   Почему бы не поступать с изменениями справочника так же, как с изменениями кода? Принимать их как условные merge request’ы и прогонять через автотестирование. Вообще, верю, что в какой-то лучшей параллельной вселенной бизнес освоил Git и делает merge request’ы с JSON-файлами или даже со скриптами миграции БД. Но, увы, это песня не про нас… Можно обойтись и без Git на стороне бизнеса. Достаточно просто дать бизнес-аналитикам возможность формировать патчи с изменениями справочника. А после передавать их в тестирование и внедрение так же, как это делают разработчики, когда вносят изменения в конфиги. Выходит простая схема: открыть справочник, внести изменения, запустить их применение. Процесс изменения справочника может проходить, например, так. Бизнес-аналитик: Вносит изменения в продуктовый каталог на одном из стендов разработки. Меняет атрибуты элемента каталога.   Жмёт в контекстном меню каталога «Отправить патч во внедрение».   Сервис каталога, например, через GitLab API: Создаёт в репозитории ветку biz_patch_xxx с единственным новым коммитом, содержащим изменения каталога. Отправляет merge request.   Активирует пайплайн, который применяет патч и начинает автотесты. Запускает стандартный процесс тестирования и публикации. Я вижу три варианта: сериализованные команды CQRS (созданные при редактировании каталога), SQL-инструкции, JSON Patch. Понятно, что с любым решением будут возникать конфликты из-за параллельных изменений. Самый простой путь с ними справиться — не принимать изменения для неактуального состояния справочника. Если несколько пользователей начали менять справочник одновременно, то мы примем изменения от того, кто первым сохранит новые данные. Опоздавшие увидят сообщение по типу «Состояние системы изменилось, пока вы вносили изменения, пожалуйста, внесите изменения заново». Не думаю, что такое упрощение вызовет проблемы. Ситуации, когда справочники меняют много людей одновременно, относительно редки. Реализовать такую проверку можно, если при создании патча сохранять в него хеш состояния справочника. Хеш справочника изменится, когда его отредактируют. И патчи со старым хешем приниматься не будут. Предположим, что у нас есть записанный в JSON небольшой продуктовый каталог розничных кредитов:   Дабы не усложнять статью, предположим, что бизнес-аналитик скопировал продуктовый каталог к себе на рабочую станцию, чтобы отредактировать с помощью блокнота, а лучше — VS Code с JSON-плагином, и вносит такие изменения: Аналитик поменял ставку у одного существующего продукта и добавил ещё один новый.   Пора начать внедрять наши изменения в кредитный конвейер банка. Для начала создадим патч с помощью утилиты:   Утилита создаст для нас файл BankProductsPatch.json. Это и есть патч со всеми изменениями! Всё просто и прозрачно. Сделаны две операции: добавлен (add) новый элемент и заменён (replace) старый.   Транспортируем патч в Git-репозиторий, чтобы GitLab pipeline провёл миграцию изменений. Создаём утилиту, которую будет запускать pipeline, и получаем желаемый каталог.   Теперь продуктовый каталог в изменённом виде (BankProductsWithAppliedPatch.json = BankProductsNew.json) существует на стороне контура разработки и тестирования. Там его можно проверить всеми возможными способами, а после отправить в ветку prod. Решение довольно простое. И стоит заметить, что использование JSON Patch — это только один из доступных вариантов. Я не случайно назвал статью «Бизнес-конфиги». Изменения в некоторых бизнес-справочниках по степени влияния на бизнес-процессы в IT-системах предприятия сопоставимы с изменениями конфигов или даже кода в сервисах этих систем. Поэтому и относиться к таким справочникам нужно соответствующе. Буду рад, если кто-то поделится в комментариях опытом и знаниями о том, как изменять, тестировать и доставлять справочные бизнес-данные в prod-контур предприятия.