Для сохранения конфигурации из 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-триггер, который будет инициировать выгрузку в какую-то папку или другую базу и уже потом разбираться.
Кстати, триггер позволит точно ответить на вопрос когда изменилась конфигурация с точностью до секунд.
Но если баз для мониторинга много, наверняка, может возникнуть ситуация, когда за полчаса будет запущено много скриптов разбора и сервер просто не справится с нагрузкой. Неплохо было бы сделать очередь разбора рабочих конфигураций, балансируя нагрузку между важными конфигурациями и не очень.
Продолжение следует…
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
А чо, весело и задорно! Хотя, заявленные задачи я бы решал другими средствами, но пусть расцветает сто цветов!
(1) А можно в подробностях?
Вообще, половину проблем решает подключение рабочей базу к хранилищу с минимальными правами (без возможности захвата объектов, только получение из хранилища). Тогда и шаманить в рабочей базе станет физически невозможно, и не спутаешь с тестовой, и сидеть в её конфигураторе тоже никто не будет.
Также автоматизированное обновление рабочей базы из хранилища (нединамическое обязательно) часть других проблем решает.
прямо больно до слёз! Чего не хватило в односкрипте, чтобы выкинуть из этого списка PowerShell ???
PS. Это не упрёк, а вопрос — мы же допилим, если что 🙂
(4)
К сожалению, не решает. А что помешает в конфигураторе рабочей базы отключить ее от хранилища?
(5) И во вложениях — доработанный gitsync. А что именно доработано? Может это включить в основной gitsync?
(7)
Видимо, это. То есть, гитсинк тут и не нужен, нужен мелкий скрипт с v8runner и gitrunner.
Разворчались… У меня тестовый контур, и кф файл нужен из бызы разработчика, для базы тестирования… А согнать разработчика с отладки, что бы тестировщик что-то обновил… Так что плюс однозначный…
(6) Я же написал, половину. Неадекватных и злонамеренных сотрудников не рассматриваю, это не техническая проблема, а административная. Если всё так плохо, нужно не пускать в рабочий конфигуратор, как выше писали.
(0)
перепишите скрипт так чтобы он сразу раскладывал по папкам с понятными названиями.
(9)
для этого данный инструмент необязателен.
достаточно написать скрипт создания пустой базы , копирования из рабочей конфиг в пустую, выгрузку цф.
(5)
Все просто. Задача стояла — получить из SQL cf, валидный для разбора в git. Первым по запросу «BLOB поле в файл» попался PS-скрипт. Конечно, можно то же самое реализовать в односкрипте. А если функционал будет добавлен в гитсинк, то мы первые начнем пользоваться.
Однозначно +!
За PowerShell вторую бы звезду поставил 🙂
(10) Вы наверное очень отчаянный человек, если подключаете продакшн базы к хранилищу. Я полтора года назад тоже такую ересь сотворил. В итоге когда упало хранилище, намертво и качественно, мы оказались в ситуации, когда база вроде бы работает, но в конфигуратор продакшн-базы путь заказан — не доходило даже до запроса идентификационных данных хранилища. В итоге был крайне весёлый вечер. По итогу пошли по рекомендуемому многими пути формирования поставки из хранилища. В общем — свят, свят…
(3)
Тимлид просматривает Gitlab без использования конфигуратора. Обычно, это быстрее и удобнее.
(3)
Организационный момент. Доступ в боевой конфигуратор выдается только человеку, отвечающему головой за систему. Он под своим присмотром может пустить туда разработчика на короткий срок решения авралов. Текущая разработка задач, ведущаяся на боевой системе должна быть исключена. И техническими средствами это не решить.
Один из печальных кейсов. Запустили обновление ИБ, а там — реструктуризация. Надо было срочно обновляться. Ну как обычно бывает. На тестовый прогон времени не было. А реструктуризация затянулась на несколько часов. Вот тут-то и понадобился CF, чтобы понять, что же там происходит. Прерывать и откатывать на бэкап (да-да, бэкапы перед обновлением делать надо всегда, желательно автоматизированно. Даже внешне самый безобидный деплой может стать фатальным. Ваш КО) или дожидаться реструктуризации.
Тогда обошлись ночной копией. Сейчас бы взяли версию из git/
(16) Спасибо за камент. Если что — никого не хотел обидеть. Я написал, что статья хорошая, просто я бы решал по-другому, но я не истина в последней инстанции, напротив, мы тут все делимся опытом и каждый делает для себя выжимки из чужого опыта, приправляя своим. Главное потом — не забыть поделиться результатом, чтобы в сообществе было больше разных знаний и опытов. «Пусть расцветает сто цветов» из моего первого комментария — это как раз об этом.
Спасибо за развернутый ответ.
(16) Вот не первый раз вижу как за повершел оправдываются.
Не надо. Все вы правильно делаете
(3)
божечки, какие прекрасные слова! Андрей, можно я тебя буду всем цитировать и сбрасывать на твой комментарий ссылки?)
(21) Можешь даже слать мне деньги и ключи от квартир 🙂
(22)с этим сложнее будет)
З.ы. вот я слоупок, только увидел сообщение)