Для сохранения конфигурации из 1С в формат CF или в иерархическое дерево исходников в платформе предусмотрен запуск из командной строки. Можно ли сохранить конфигурацию минуя конфигуратор? Можно. Конфигурации находятся в отдельных таблицах SQL-базы.
А зачем это нужно?
Зачем же может понадобиться сохранять конфигурацию столь необычным способом?
- Вы хотите знать наверняка, когда и какие изменения внесены в рабочую базу и почему рабочая база не совпадает с конфигурацией хранилища (хотя и должна).
- Оперативный визуальный контроль внесенных изменений без запуска конфигуратора.
- Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен. (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)
Возможно, вы скажете, что причины надуманы и в вашей организации все процессы развертывания совершенны или близки к идеалам. А следующие утверждения иллюстрируют это и всегда (т.е. без исключений!) верны:
- Ваши разработчики ведут разработку в хранилище.
- Хотфиксы появляются в рабочей базе только из хранилища.
- Хотфиксы всегда проходят тесты (ах, да, тесты!)
- Никто никогда не вносит изменения в рабочую базу динамически.
- Если рабочая база подключена к хранилищу ее никогда не отключали по ошибке
- Никто никогда не спутал рабочий конфигуратор и не накатил туда что-то не то.
- При сравнении/объединении с новым релизом не бывает ошибки, связанной с неверным выбором файла релиза. Или альтернативное утверждение: новые релизы всегда устанавливаются из файлов поставки.
- Администраторы базы данных никогда не ошибались с восстановлением БД из других баз данных или бекапов.
- Мы все одна команда, у нас нет сотрудников, не разделяющих ценности компании, мы уверены, что никто по неведению или злому умыслу не внесет изменений, которые нарушат работу нашей системы.
Возможно, читая этот список, вы вспомнили несколько неприятных моментов, когда все было на волоске или даже хуже. Наверняка, есть еще варианты, которые вы сами можете добавить в этот перечень.
Увы, нельзя утверждать наверняка, что проблемы, связанные с изменениями конфигурации в будущем нас не коснутся, поэтому в любом случае еще один способ мониторинга изменений продуктивных баз вряд ли повредит.
Что понадобится
Кроме 1С будем использовать OneScript (начиная с версии 1.0.16), PowerShell (версии по умолчанию достаточно) и планировщик запуска.
Безусловно, нам нужны права на доступ к SQL-серверу. К нашим конкретным базам данных. Хотя бы на чтение. Исследование будет проводиться на MS SQL-серверах. Для операций будет использован Microsoft SQL Server Management Studio версии 14.0.17119.0 (хотя версия не принципиальна).
Для визуального мониторинга нам потребуется git на сервере, где будет происходить разбор на исходники и учетка в системе контроля версий.
Как хранится конфигурация в SQL
В базе данных есть как минимум две таблицы, отвечающие за хранение конфигурации: [Config], [ConfigSave]. По факту их может быть больше (рисунок из БД на MSSQL)
[Config]- конфигурация БД
[ConfigSave] – сохраненная конфигурация
[ConfigCASSave] – сохраненное системное хранилище конфигураций расширений
[ConfigCAS] –системное хранилище конфигураций расширений
В дальнейшем нас будет интересовать только первая таблица, хотя никто не запрещает анализировать происходящее и в остальных таблицах. Более подробно о том, как хранятся данные можно посмотреть на ИТС: https://its.1c.ru/db/metod8dev#content:1798:hdoc
Содержимое таблицы Config
Что же внутри Config? Выбрав первые несколько строк и взглянув на названия столбцов убеждаемся, что перед нами двоичные данные:
В процессе исследования мы выяснили, что от версии к версии платформы формат данной таблицы менялся. Для платформы 8.2 таблица имеет следующие столбцы
В платформе 8.3 добавился столбец PartNo, который позволил размещать данные неограниченно больших размеров
Разбираем на исходники
Для начала надо сохранить данные на диск. Здесь и далее используются powershell-скрипты. Разбираем двоичные данные, они представляют собой файла заголовка и собственно данные (.header, .data):
Для конфигураций на платформе 8.3 скрипт чуть усложняется за счет сбора файлов из нескольких записей.
В итоге получили папку полную запакованных файлов. С ними уже можно работать при помощи магического и всем известного v8unpack.exe (версия Сергея Батанова)
Следующая команда приводит наши файлы к готовому CF-нику:
Первая часть сделана. Мы получили CF-файл.
Разобрать его на исходники и поместить в git для последующего визуального контроля нам поможет Gitsync (библиотека для OneScript). Правда, Gitsync работает с файлами хранилища 1С, а у нас на входе есть лишь CF-ник. Поэтому саму библиотеку пришлось слегка поправить, а если быть точным, мы воспользовались уже имевшимся функционалом библиотеки, переделав команду export, убрав из нее работу с хранилищем.
На выходе мы получаем готовый к помещению во внешний репозиторий комплект исходников:
Делаем git push в заранее подготовленный репозиторий и можем смотреть на то, что изменилось за последнее время. Вот так выглядит типичный коммит после разбора очередного релиза:
Механизм получения исходников рабочей конфигурации из SQL у нас готов.
Результирующий скрипт с измененным gitsync-ом можно поставить на автозапуск обычным планировщиком с некоторым интервалом (например, раз в час). Команда запуска выглядит так:
powershell –file razbor_upp.ps1
При наличии изменений в файлах-исходниках git сам «решит», что требуется помещение и сделает его.
В таком виде мы использовали этот механизм для мониторинга изменений рабочих конфигураций. Но есть, что и улучшить!
Продолжаем автоматизацию
А что если, изменения вносятся не раз в час, а чаще? Или, наоборот, раз в день. Фиксированное время запуска будет помехой. Когда же нужно запускать скрипт? Очевидно, когда база была изменена. А как узнать, что база была изменена? На SQL-базу нужно поставить соответствующий SQL-триггер, который будет инициировать выгрузку в какую-то папку или другую базу и уже потом разбираться.
Кстати, триггер позволит точно ответить на вопрос когда изменилась конфигурация с точностью до секунд.
Но если баз для мониторинга много, наверняка, может возникнуть ситуация, когда за полчаса будет запущено много скриптов разбора и сервер просто не справится с нагрузкой. Неплохо было бы сделать очередь разбора рабочих конфигураций, балансируя нагрузку между важными конфигурациями и не очень.
Продолжение следует…
