Есть довольно знакомая ситуация.
На тестовой базе всё работает. На рабочей нет.
Версия конфигурации вроде та же. Релиз тот же. Доработку проверили. Начинаешь разбираться, и через какое-то время выясняется, что на одной базе включено расширение, на другой оно отключено. Или отличается функциональная опция. Или в тесте осталась старая настройка обмена. Или вообще базы давно живут каждая своей жизнью.
И начинается стандартный обход: открыть одну базу, открыть вторую, смотреть настройки, расширения, константы, обмены, почту, вспоминать, что ещё могло отличаться.
Мне хотелось получить более простой ответ на вопрос:
чем эта база по своему эксплуатационному состоянию отличается от той, которую я считаю образцом?
Для этого и появилась BaseDiff.
Важно сразу оговориться: это не ещё один механизм сравнения конфигураций и не замена штатному сравнению/объединению. Задача здесь немного другая.
Что именно я хотел сравнивать
Допустим, есть PROD и TEST.
Конфигурации у них могут быть одинаковыми, но окружение почти никогда не совпадает на сто процентов.
Например, вполне нормально, если различаются:
- адреса внешних сервисов;
- настройки почты;
- отдельные функциональные опции;
- узлы обмена;
- параметры, которые специально меняются на тестовом контуре.
А вот некоторые отличия уже хочется увидеть сразу:
- в TEST подключено расширение, которого нет в PROD;
- расширение есть на обеих базах, но версии разные;
- расширение внезапно отключено;
- изменился состав метаданных основной конфигурации;
- база находится в другом состоянии по полнотекстовому поиску;
- отличаются важные настройки;
- версия информационной базы БСП не соответствует конфигурации.
Собственно, BaseDiff и работает вокруг этой идеи: не пытаться ответить на вопрос «одинаковые ли базы вообще», а показать конкретные эксплуатационные отличия.
Рис. 1. Главная форма BaseDiff
Снимок вместо постоянного доступа к двум базам
Основной сценарий получился довольно простой.
На рабочей базе сохраняется снимок в файл .basediff.
Потом этот файл можно открыть на тестовой базе и сравнить с её текущим состоянием.
То есть схема такая:
PROD - снимок -TEST - сравнение
Сам PROD при этом не обязан оставаться доступным во время сравнения.
Есть и второй вариант: взять два уже сохранённых снимка и сравнить их между собой вообще без подключения к базам.
Это оказалось удобно не только для PROD - TEST. Например, можно сохранить состояние базы до каких-то работ, потом сделать второй снимок после и посмотреть, что поменялось.
Сам .basediff это не копия базы и не выгрузка данных пользователей. Это описание выбранных параметров состояния, которое обработка потом умеет сопоставлять.
Рис. 2. Создание снимка
Перед сравнением можно решить, насколько глубоко смотреть
Некоторые проверки быстрые, некоторые на большой базе могут занять заметное время.
Поэтому перед сравнением есть отдельный предпросмотр.
Там можно включить или выключить, например:
- сравнение расширений;
- проверку применимости расширений текущей базы;
- сравнение размера данных информационной базы.
Тяжёлые операции специально не запускаются все подряд без спроса. Если включить расчёт размера данных, проверку применимости или сбор части серверной информации, обработка предупреждает, что лучше делать это в техническое окно.
Мне хотелось, чтобы обычное сравнение не превращалось в «нажал кнопку и теперь жди непонятно сколько».
Рис. 3. Предпросмотр сравнения
Как выглядит результат
После сравнения результат не сваливается в одну большую таблицу «Истина/Ложь».
У строки есть статус:
| Статус | Что означает |
|---|---|
| Совпадает | Значения одинаковые |
| По правилу | Отличие есть, но для этих контуров оно ожидаемое |
| Отличие | Значения отличаются, отдельного правила нет |
| Критическое | Отличие, на которое стоит посмотреть в первую очередь |
| Не удалось | Параметр не получилось получить или сравнить |
Основной рабочий режим у меня включить «Только отличия» и уже идти сверху вниз.
При этом ошибка в одной категории не должна валить весь снимок. Если какой-то параметр получить не удалось, он остаётся в результате с пояснением, а остальные категории продолжают собираться.
Рис. 4. Результат сравнения
Самое полезное для меня ожидаемые отличия
Если просто сравнивать PROD и TEST, довольно быстро появляется другая проблема: они и должны отличаться.
Например:
PROD:
https://api.company.ru
TEST:
https://api-test.company.ru
Если каждый раз показывать это красным, через десять таких строк на реальные проблемы уже перестаёшь смотреть.
Поэтому есть профиль .basediffprofile.
В нём можно описать ожидаемые отличия между контурами.
Тогда BaseDiff не говорит, что значения одинаковые. Он честно показывает, что различие есть, но переводит его в статус «По правилу».
То есть смысл не в том, чтобы добиться искусственных 100% совпадения, а в том, чтобы отделить нормальную разницу между средами от неожиданной.
Без профиля тоже можно работать тогда каждое расхождение просто будет обычным «Отличием».
Рис. 5. Профиль правил / отличие «По правилу»
Что происходит с конфигурацией
Отдельно хотелось понимать, что базы хотя бы не разошлись по составу метаданных.
Для этого в снимке есть отпечаток основной конфигурации.
Он строится по отсортированному списку полных имён объектов метаданных и считается через SHA-256.
Здесь есть важное ограничение.
Если в одной базе добавили, удалили или переименовали объект, отпечаток изменится.
А если разработчик просто поменял несколько строк в модуле существующего объекта, но состав метаданных не изменился, такой отпечаток этого не увидит.
И это сделано сознательно.
BaseDiff не должен превращаться в своё сравнение исходников. Для кода есть хранилище, Git, штатное сравнение конфигураций и другие нормальные инструменты. Здесь нужен скорее быстрый индикатор: состав основной конфигурации тот же или уже нет.
Расширения я вынес отдельно
С расширениями история интереснее.
На практике как раз они часто становятся причиной ситуации «на тесте работает иначе».
Для каждого подключённого расширения можно увидеть и сравнить:
- наличие на обеих сторонах;
- активность;
- версию;
- назначение;
- область действия;
- безопасный режим;
- изменение содержимого;
- применимость.
Расхождение по версии, активности или содержимому обычно имеет смысл считать критическим.
Проверку применимости можно запускать отдельно. Используется платформенная проверка возможности применения расширений.
При этом я бы не воспринимал её как абсолютную гарантию, что расширение потом нигде не упадёт. Например, проблемы в коде с &ИзменениеИКонтроль могут проявиться уже во время выполнения.
То есть здесь логика та же: получить хороший технический сигнал, но не пытаться заменить им полноценное тестирование.
Рис. 6. Сравнение расширений
Паспорт базы
Кроме того, что непосредственно участвует в сравнении, в снимок попадает небольшой паспорт информационной базы.
Например:
- блокировка начала сеансов;
- состояние динамического обновления;
- актуальность индекса полнотекстового поиска;
- количество сеансов;
- распределение сеансов по имени приложения.
По сеансам мне не нужны фамилии пользователей и IP-адреса, поэтому сохраняется агрегированная информация.
Для клиент-серверной базы можно дополнительно собрать часть информации о кластере: используемую СУБД, сервер базы данных, блокировки регламентных заданий и начала сеансов.
Параметры подключения к RAS для этого нужны только во время текущего сеанса и в файл снимка не сохраняются.
Паспорт специально отделён от обычного diff. Это скорее возможность быстро открыть снимок и понять, в каком состоянии находилась база в момент его создания.
Рис. 7. Информация о снимке / паспорт ИБ
Размер данных
Ещё одна небольшая вещь, которую добавил уже по ходу работы, размер данных информационной базы.
Не размер файла .1CD и не размер конфигурации, а объём данных в таблицах ИБ.
Проверка опциональная и по умолчанию выключена, потому что на большой базе это уже не та операция, которую стоит запускать просто «за компанию».
Размер показывается отдельно и на процент соответствия не влияет.
То есть если TEST внезапно в несколько раз меньше или больше образца, это видно, но само по себе не превращает результат сравнения в ошибку.
Можно сохранить сам результат сравнения
Результат можно:
- вывести в табличный документ;
- сохранить в JSON;
- потом снова открыть этот JSON в BaseDiff.
В сохранённый результат не нужны полные локальные пути вида:
C:\Users\...\Client\prod.basediff
поэтому в источнике остаются только имена файлов.
Например:
prod.basediff
test.basediff
Это мелочь, но переносимый технический отчёт не должен без причины рассказывать, как у меня называется пользователь Windows и в каком каталоге лежит проект.
Что с паролями и другими секретами
Это был отдельный вопрос, потому что часть настроек без повышенных прав вообще нормально не прочитать, а в некоторых объектах рядом с полезными параметрами лежат пароли.
Создание снимка поэтому разрешено только пользователю с административными полномочиями.
Но сами значения паролей, токенов и ключей в .basediff не сохраняются и не хешируются.
Для секрета достаточно знать:
заполнено
или:
не заполнено
Например, для сравнения двух почтовых учётных записей чаще всего не нужно знать пароль. Важно заметить, что на одной стороне он настроен, а на другой нет.
Query-параметры и fragment URL при сохранении адресов отбрасываются. Учётные данные вида user:password@host также не должны попадать в снимок.
При этом есть принципиальная граница, которую полностью автоматически не решить: некоторые сервисы могут положить секрет прямо в путь URL.
Условно:
https://service.local/webhook/SOME_SECRET
Путь endpoint нужен для сравнения, поэтому перед передачей снимка кому-то ещё его всё равно стоит просмотреть.
Вообще .basediff я бы относил к служебному файлу. В нём могут быть имена и полные имена пользователей ИБ, e-mail, имена серверов, баз данных, узлов обмена и другая информация об инфраструктуре.
Поэтому production-снимок точно не тот файл, который стоит бездумно прикладывать к публичному Issue.
Где это может пригодиться
Для себя я вижу несколько нормальных сценариев.
Перед разбором проблемы на TEST
Вместо вопроса:
«А тест вообще сейчас похож на PROD?»
сначала сравнить состояния и убрать очевидные расхождения.
После обновления или технических работ
Сделать снимок до, второй после и посмотреть, что изменилось кроме того, что планировали менять.
Когда несколько тестовых контуров
Сохранить один образец PROD и прогнать по нему TEST1, TEST2 и TEST3.
Особенно удобно вместе с профилями ожидаемых отличий.
Перед передачей задачи на тестирование
Не для того, чтобы формально поставить галочку «базы одинаковые», а чтобы быстро увидеть, не забыли ли на тесте нужное расширение или настройку.
Разбор «у меня работает»
Классика: разработчик открывает свою базу, пользователь рабочую, и оба смотрят вроде на одно и то же решение.
Снимки хотя бы позволяют начать с объективного списка отличий.
Чего BaseDiff не делает
Здесь лучше сразу обозначить границы.
BaseDiff:
- не заменяет сравнение и объединение конфигураций;
- не анализирует построчно исходный код модулей;
- не доказывает, что два контура полностью идентичны;
- не гарантирует применимость расширения во всех сценариях выполнения;
- не заменяет нагрузочные или функциональные тесты;
- не является системой мониторинга.
Это именно инструмент сравнения состояния и окружения базы в конкретный момент времени.
На мой взгляд, в таком виде он полезнее, чем попытка сделать из одной внешней обработки ещё один универсальный комбайн на все случаи жизни.
Что сейчас проверено
На текущем этапе я проверял обработку на:
- платформе 8.3.27.2130;
- управляемом приложении;
- файловом варианте информационной базы;
- 1С:ERP;
- 1С:Бухгалтерии.
Минимальная версия платформы для обработки 8.3.24.
Клиент-серверный вариант в логике предусмотрен, в том числе отдельный сбор части информации о кластере, но как полноценно проверенный сценарий я его пока не заявляю в процессе тестирования.
Перед первым использованием на рабочей базе в любом случае лучше иметь актуальную резервную копию и сначала посмотреть поведение обработки на тестовой.
Исходный код BaseDiff
Исходный код BaseDiff, документация и инструкция по сборке опубликованы в открытом репозитории BaseDiff на GitHub.
Проект распространяется по лицензии MIT. В репозитории также можно посмотреть историю изменений и сообщить о найденной проблеме.
В репозитории есть исходники внешней обработки, руководство по использованию и инструкция по сборке BaseDiff.epf. Там же можно следить за изменениями проекта и сообщать о найденных проблемах.
Спасибо за прочтение!
Если попробуете BaseDiff и найдёте интересный сценарий, ошибку или идею для развития буду рад обратной связи!
Вступайте в нашу телеграмм-группу Инфостарт