В процессе сопровождения и обновления сильно измененных нетиповых конфигураций разработчики часто сталкиваются с ситуацией, когда при очередном сравнении с новой версией поставщика обнаруживается пропажа какого-либо объекта метаданных. Например, это может быть справочник ХранилищеДополнительнойИнформации, документ или реквизит, который в вашей кастомизированной базе все еще присутствует и, возможно, содержит важные данные, а в новой конфигурации поставщика его уже нет.
Прежде чем безвозвратно удалять объект из рабочей базы, необходимо выяснить, в каком именно релизе от него отказался разработчик решения. Это нужно для того, чтобы изучить сопроводительную документацию к обновлению, понять логику вендора и корректно перенести накопленные данные в новые структуры (например, в механизмы БСП). В этой статье мы подробно разберем как классические методы, предложенные участниками сообщества, так и современные высокотехнологичные подходы к решению этой задачи.
Проанализируем все доступные варианты — от простых ручных действий до автоматизированного анализа версий.
Этот способ является классическим и наиболее надежным, если у вас под рукой есть доступ к дистрибутивам прошлых обновлений или возможность их быстро скачать. Рассмотрим его алгоритм по шагам.
Представим, что у вас установлена рабочая конфигурация версии 2.1.2.5, в которой объект еще присутствует, а вы обновляетесь до версии 2.3.8.12, где его уже нет. Между этими версиями выпущено, например, 30 промежуточных релизов.
.cf) в пустую файловую базу. Для этого даже не обязательно устанавливать шаблоны, достаточно распаковать файлы обновления.ХранилищеДополнительнойИнформации).Этот метод гарантирует 100% точный результат, однако требует времени на скачивание и разворачивание конфигураций.
Выясним, как получить нужную информацию быстрее, не тратя трафик и время на установку баз. Портал обновлений 1С хранит подробное описание изменений для каждого релиза.
Разберем, как воспользоваться этим ресурсом:
releases.1c.ru под своей учетной записью ИТС и перейдем на страницу конфигурации (например, «Аптека»).Ctrl + F), введя имя нашего справочника.ХранилищеДополнительнойИнформации), мы можем посмотреть, в каком релизе нашей конфигурации обновилась версия БСП. Затем, зная версию БСП, мы легко найдем новость на сайте ИТС о том, в какой именно версии БСП данный справочник был выведен из состава библиотеки.Если вы регулярно администрируете и обновляете базы данных, на вашем сервере или локальном компьютере уже установлены десятки прошлых обновлений. Все они по умолчанию распаковываются в единый каталог шаблонов. В операционной системе Windows этот каталог обычно находится по пути: %APPDATA%\1C\1cv8\tmplts.
Каждое обновление сопровождается текстовыми файлами описания: ReadMe.txt, НовоеВВерсии.htm, UpdInfo.txt. Мы можем запустить глобальный поиск по содержимому этих файлов, не открывая конфигуратор:
tmplts.ХранилищеДополнительнойИнформации..htm и .txt во всех подпапках всех релизов за несколько секунд.Если в вашей компании внедрены современные стандарты разработки, конфигурация выгружается в файлы XML (с помощью стандартной команды платформы DumpConfigToFiles, инструмента gitsync или среды разработки 1С:EDT) и хранится в репозитории Git. В этом случае задача решается буквально одной командой в консоли Git.
Посмотрим на пример работы с Git. Каждый объект конфигурации при выгрузке представляется отдельным XML-файлом или папкой. Для справочника путь будет выглядеть примерно так: Catalogs/ХранилищеДополнительнойИнформации.xml.
Для того чтобы узнать, в каком коммите (и, соответственно, в каком релизе) этот файл был удален, мы можем выполнить следующую команду в терминале Git:
git log --diff-filter=D --summary | grep "ХранилищеДополнительнойИнформации"
Или, если нам нужно увидеть всю историю изменений этого объекта, включая момент его удаления, даже если файла уже физически нет в текущей рабочей директории:
git log --all -- "**/ХранилищеДополнительнойИнформации.xml"
Git вернет хэш коммита, автора изменений, дату и комментарий к коммиту. Если при обновлении конфигурации вы фиксируете номера релизов в комментариях к коммитам (например, «Обновление до релиза 2.3.5.12»), вы мгновенно узнаете нужную версию.
Фирма «1С» следует строгим стандартам разработки при проектировании типовых и отраслевых конфигураций. Согласно стандартам, объекты метаданных никогда не удаляются «на лету» без предупреждения. Сначала они переводятся в категорию устаревших:
Удалить... (например, УдалитьХранилищеДополнительнойИнформации).(не используется) ....ОбновлениеИнформационнойБазыБСП или специализированный модуль вашей конфигурации) регистрируется обработчик обновления. Этот обработчик переносит накопленные данные из старой структуры в новые объекты метаданных.Мы можем использовать этот стандарт для поиска релиза. Проанализируем ситуацию: откроем конфигурацию (желательно промежуточную, где объект еще существовал или только был помечен на удаление) и запустим глобальный поиск (Ctrl + Shift + F) по ключевому слову ХранилищеДополнительнойИнформации в модулях.
Мы найдем процедуру регистрации обработчиков обновления. Код регистрации будет выглядеть примерно следующим образом:
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "2.3.4.15";
Обработчик.Процедура = "ОбновлениеИнформационнойБазыБСП.ПеренестиДанныеХранилища";
Обработчик.ОбщиеДанные = Истина;
КонецПроцедуры
Обратим внимание на свойство Обработчик.Версия. Значение "2.3.4.15" указывает платформе, что этот код переноса данных должен выполниться при обновлении информационной базы на версию 2.3.4.15. Именно в этом релизе справочник официально перестал использоваться и был заменен новыми механизмами хранения файлов.
Если у вас на диске скопилось множество файлов обновлений (.cf или .cfu) и вы хотите автоматизировать процесс поиска без ручного открытия Конфигуратора для каждого релиза, можно написать простой скрипт автоматизации с использованием командной строки платформы 1С или OneScript.
Платформа 1С поддерживает пакетный режим сравнения файлов конфигураций. Мы можем запустить сравнение двух последовательных версий программно:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /F "C:\Bases\EmptyBase" /CompareCfg "C:\CF_Files\Version_2.3.1.cf" "C:\CF_Files\Version_2.3.2.cf" -Out "C:\Reports\Compare_2_3_1_to_2_3_2.txt"
Написав простой цикл на OneScript, мы можем поочередно сравнить все имеющиеся у нас файлы обновлений и выгрузить отчеты сравнения в текстовые файлы. Затем с помощью обычного текстового поиска по полученным файлам отчетов мы мгновенно определим, в каком именно отчете впервые появится строка:
Справочник.ХранилищеДополнительнойИнформации. Удален
Мы подробно рассмотрели целый спектр инструментов для решения этой задачи. Если вам требуется быстрое решение «здесь и сейчас» без лишних технических сложностей — используйте Метод 3 (глобальный текстовый поиск по локальным шаблонам) или Метод 2 (анализ сайта релизов ИТС). Если вы хотите выстроить надежный и технологичный процесс разработки в команде — внедряйте Метод 4 (контроль версий через Git и EDT).