Задача прилетела так, как прилетают все хорошие задачи - одной строкой в мессенджере: «Переходим на 8.5». Ниже большой палец вверх и тишина.
Ниже история про то, как я пошёл проверять готовность руками, бросил, собрал инструмент и прогнал две базы. Результат оказался не тем, которого я ждал. А заодно я нашёл ошибку в собственном инструменте - способом, который стоит взять на вооружение всем, кто пишет что-то считающее.
Почему 8.5.1 нельзя накатить «как обычно»
Первая мысль у всех одинаковая: мы же меняли 8.2 на 8.3, релизы накатываем не глядя, что тут нового.
Ловушка в том, что список изменений, требующих правок в конфигурациях, копится от версии к версии. Старое из него не выкидывают. Сидите на режиме совместимости 8.3.14 - при переходе вы прыгаете не через одну версию, а через все разом. Платформа при этом не падает с понятным сообщением «здесь устаревший метод». Она молча меняет поведение.
Есть и второй слой, про который вспоминают в последнюю очередь: неисправленные ошибки самой платформы. В 8.5.1.1343 их заметный пласт, и часть касается вещей, которыми пользуются все: PDF, поле HTML-документа, расширения конфигурации, полнотекстовый поиск, работа кластера. Это дефекты не вашей конфигурации, их не найти чтением своего кода, но встретитесь вы с ними ровно так же.
Сначала я пошёл проверять руками
План был простой: открыть «Список изменений и порядок обновления» с releases.1c.ru, выписать оттуда всё, что касается нашего пути по версиям, и пройтись по конфигурации глазами.
Через пару часов стало ясно, во что я ввязался. Типовая Бухгалтерия - это тысячи объектов метаданных и тысячи модулей. Держать в голове весь список изменений и не моргать - недели работы. И результат такой проверки живёт ровно до следующего релиза платформы: он нигде не зафиксирован, через полгода всё заново.
А потом я вспомнил, что база у меня не одна.
Баз много, и это всё меняет
Одну базу ещё можно перелопатить руками, стиснув зубы. Но у меня их несколько, и они разные: разные конфигурации, разные версии, где-то расширения, где-то файловая, где-то клиент-серверная. И каждой предстоит тот же путь на 8.5.
Умножьте недели на количество баз. Потом умножьте на «через полгода выйдет 8.5.2, и надо пройти заново». Считать дальше не хочется.
Плюс ручная проверка невоспроизводима. Её не передать коллеге, не показать заказчику как доказательство, что посмотрел всё, и через месяц сам не вспомнишь, что уже проверил.
В этот момент я решил не бегать по граблям, а один раз подготовиться основательно: собрать инструмент, который прогоняется на любой базе за минуты и выдаёт список работ. Потратить день сейчас, чтобы не тратить недели на каждой базе потом.
Тем более что задача к этому располагает. Всё, что я искал глазами, - это шаблоны.
Движок отдельно, знания отдельно
Устаревший метод ищется по шаблону. Снятое свойство метаданного тоже. Режим совместимости вообще читается одной строкой. Значит, всё это можно описать данными и прогонять по конфигурации автоматически.
Правила я не стал зашивать в код. Это отдельный каталог в формате JSON: у каждого правила есть идентификатор, версия платформы, в которой случилось изменение, тип проверки, паттерн, текст рекомендации и ссылка на первоисточник. Движок только применяет их.
Сейчас в каталоге 63 правила: 24 датированы самой 8.5.1, остальные 39 распределены по версиям от 8.3.21 до 8.3.27. Источники только официальные: «Список изменений и порядок обновления» и Сервис публикации ошибок 1С.
Вторая половина замысла - кумулятивный отбор. Обработка читает режим совместимости конфигурации и применяет только правила, относящиеся к изменениям после него. База на 8.3.24 получает короткий отчёт, база на 8.3.14 - длинный. Каждый видит свой путь, а не всю документацию сразу.
Забегая вперёд: именно в этом месте у меня и оказалась ошибка. К ней вернусь.
База первая: файловая, режим 8.3.14
Бухгалтерия для Казахстана 3.0.39.2, платформа 8.3.20.2290, расширений нет.
Быстрый режим (только живая база, без чтения кода) занял секунды:
| Показатель | Значение |
|---|---|
| Предупреждения | 9 |
| Информация и чек-лист | 25 |
| Проверено, замечаний нет | 5 |
| Не проверялось (нужен код) | 24 |
Смотрите на последнюю строку. 24 правила помечены «не проверялось»: это правила по коду, а код из режима Предприятия платформа читать не даёт. Обработка не делает вид, что посмотрела туда, куда не заглядывала.
Дальше анализ с кодом, вместе с выгрузкой конфигурации:
| Показатель | Быстрый | С кодом |
|---|---|---|
| Предупреждения | 9 | 18 |
| Информация и чек-лист | 25 | 31 |
| Проверено, замечаний нет | 5 | 14 |
Половина находок живёт в коде, и в быстром режиме её не видно. Это ограничение платформы, не инструмента.
База вторая: свежая, и это не помогло
Вторую базу я брал как контрольную и ожидал чистого результата. Бухгалтерия для Казахстана 3.0.73.1 - на 34 релиза свежее первой. Платформа 8.3.27.2325, режим совместимости уже поднят до 8.3.21, подключено четыре расширения.
| Показатель | Быстрый | С кодом |
|---|---|---|
| Предупреждения | 7 | 15 |
| Информация и чек-лист | 25 | 30 |
| Проверено, замечаний нет | 4 | 10 |
Пятнадцать против восемнадцати. Разница на три пункта.
Свежесть конфигурации почти ничего не решает
Я ждал, что вторая база окажется в разы чище. Она новее на 34 релиза, стоит на 8.3.27 вместо 8.3.20, режим совместимости поднят. По всем признакам она «ближе к 8.5».
А получила почти столько же замечаний.
Разница в охвате правил есть, но скромная: первой базе применились все 63 правила каталога, второй 55. Восемь правил - это ровно изменения версии 8.3.21, которые вторая база уже прожила. Всё остальное, включая 24 правила самой 8.5.1, легло на обе одинаково.
Практический вывод. Ощущение «мы регулярно обновляемся, значит к 8.5 готовы» - ложное. Обновление конфигурации закрывает изменения прикладного кода вендора и не отменяет того, что меняется в самой платформе. К 8.5.1 вы приедете почти с тем же списком работ, что и коллега на релизе двухлетней давности.
Поднятие режима совместимости помогает больше, чем обновление конфигурации, но снимает лишь ту часть пути, которую вы уже прошли. На 8.3.21 против 8.3.14 это восемь правил из шестидесяти трёх.
Что нашлось в типовом коде
Ожидаемо было увидеть проблемы в доработках. Нашлись они в типовой поставке.
Правило R851-FORM-001: свойство поля формы ГиперссылкаЯчейки объявлено устаревшим в 8.5.1. Часть находок со второй базы, как есть из отчёта:
Catalogs/ФизическиеЛица/Forms/ФормаВычетыИПН (модуль формы), строка 86:
Если Поле.ГиперссылкаЯчейки И ЗначениеЗаполнено(ТекущиеДанные.Расшифровка) Тогда
CommonForms/РедактированиеДокументаOfficeOpen (модуль формы), строка 1675:
КнопкаНастройкиФормата.ГиперссылкаЯчейки = Истина;
CommonModules/ОбменСБанками (модуль), строка 3775:
ПолеСостояние.ГиперссылкаЯчейки = Истина;
CommonModules/РаботаСНоменклатурой (модуль), строка 10357:
НовыйЭлемент.ГиперссылкаЯчейки = Истина;
Всего таких мест семь: вычеты ИПН, обмен с банками (три вхождения), работа с номенклатурой, редактирование документа Office Open XML и редактирование табличного документа. Это код вендора, который на 8.5.1 придётся пересматривать.
Заменяется свойство так: у таблицы формы теперь ОтображениеГиперссылокЯчеек, у поля формы - ОтображениеГиперссылкиЯчейки и ВариантОтображенияГиперссылкиЯчейки.
Смысл простой: «у нас типовая, мы ничего не дорабатывали» от проверки не освобождает.
Как устроен поиск по коду, без прикрас
Скажу прямо, пока не спросили в комментариях: обработка ищет по тексту модулей, синтаксическое дерево она не строит.
Видно это по одной из находок: строка вида ФормаОбъект.Элементы, "СостояниеДиректБанк", "ГиперссылкаЯчейки", Ложь); - совпадение внутри строкового литерала в параметрах вызова, а не обращение к свойству.
Комментарии обработка отбрасывает, но ложные срабатывания на строковых литералах и одноимённых переменных возможны. Для задачи «составить список мест, куда посмотреть перед переходом» этого достаточно. Для автоматического рефакторинга - нет, и обещать такое я не буду.
Пласт, о котором забывают: ошибки самой платформы
Отдельная категория правил - известные неисправленные ошибки 8.5.1.1343 из Сервиса публикации ошибок. К вашему коду они отношения не имеют.
На базе с расширениями сработало BUG851-EXT-001: по расширениям в 8.5.1.1343 есть серьёзные неисправленные ошибки, включая игнорирование условных блоков препроцессора у методов, добавляемых расширением. Обработка увидела четыре подключённых расширения и подняла флаг.
Дальше по списку: PDF, поле HTML-документа, криптография, полнотекстовый поиск, работа кластера, конфигуратор, регистры расчёта. Показываются только те пункты, что касаются функциональности вашей базы: есть регистры расчёта - будет предупреждение про них, нет - не будет.
Починить вы это не сможете. А спланировать сможете: не тащите на 8.5.1 контур, который на такую ошибку наступит.
Как я нашёл ошибку в собственном инструменте
Теперь та часть, ради которой стоило писать эту статью.
Когда я свёл цифры двух баз в таблицу, картина была другой: 18 замечаний против 6. Втрое. Красивый заголовок и готовый вывод «режим совместимости решает всё».
Перед публикацией я сел проверять арифметику. В каталоге 63 правила. Первая база: 9 + 25 + 5 + 24 = 63, сходится. Вторая: 3 + 11 + 3 + 7 = 24. Откуда 24?
Ровно 24 правила в каталоге датированы версией 8.5.1. То есть второй базе применились только они, а все 39 правил версий 8.3.21-8.3.27 отсеялись. Но её режим совместимости 8.3.21, изменения 8.3.22 и старше обязаны были пройти.
Полез в код отбора. Метаданные.РежимСовместимости возвращает строку вида Версия8_3_14 - через подчёркивания. А мой разбор версии искал точку:
[Версия8_3_14] -> версия = [] пусто [Версия8_3_21] -> версия = [] пусто
Разбор возвращал пустоту, обработка молча откатывалась на версию платформы, и главная заявленная фича - кумулятивный отбор по режиму совместимости - не работала вообще. Отбор шёл по версии платформы: 8.3.20 у первой базы давала все 63 правила, 8.3.27 у второй - только 24.
Починка на одну строку: перед разбором заменить подчёркивание на точку. После неё вторая база получила свои 55 правил и 15 предупреждений вместо шести. Цифры в этой статье - уже после исправления.
Обратите внимание, чем эта ошибка была опасна. Она не роняла обработку и не выдавала бессмыслицу. Она давала правдоподобный результат: меньше замечаний у более свежей базы, то есть ровно то, чего интуитивно ждёшь. Не сойдись арифметика, я бы опубликовал красивый вывод, построенный на баге.
Мораль применима к любому инструменту, который что-то считает: сверяйте итог с составом. Сумма по категориям обязана сходиться с общим числом правил, строк, объектов. Одна такая проверка ловит то, чего не поймает ни один тест на «не упало».
Пять граблей, на которые я наступил по дороге
Немного технических кишок: в интернете этого нет, а ловится оно только прогоном.
Чтобы «одна кнопка» работала, обработка сама запускает конфигуратор: путь к 1cv8.exe берётся из КаталогПрограммы(), строка подключения - из СтрокаСоединенияИнформационнойБазы(), дальше DESIGNER /DumpConfigToFiles.
Первая. Я поставил ключ /DisableStartupDialogs, рассчитывая, что платформа сама спросит пароль своим окном. Этот ключ ровно это и запрещает: конфигуратор молча завершался, ничего не выгрузив. Подавлять диалоги можно, только если логин с паролем передал сам.
Вторая. Пароль в командной строке виден в списке процессов, пока работает конфигуратор. Обойти это в пакетном режиме нечем: других способов передать учётные данные платформа не даёт. Кого не устраивает - оставляйте поле пароля пустым и вводите его в окне конфигуратора на каждый запуск.
Третья. Анализ идёт на сервере, а конфигуратор работает на клиенте. В файловой базе это одна машина, в клиент-серверной - разные, и просить у администратора сетевую шару не хочется. Решение: упаковать в ZIP и передать через временное хранилище. В архив кладутся только *.bsl, Form.xml и Configuration.xml: полная выгрузка это гигабайты, а модули с формами после сжатия - десятки мегабайт.
Четвёртая. ЗаписьZipФайла.Добавить с маской каталог\*.bsl падает с «Каталог не обнаружен», если в самом каталоге совпадений нет. Рекурсивный режим не спасает, путь с маской проверяется буквально, а модули лежат в подкаталогах. Переписал на поштучное добавление - получил дубли: с относительными путями имя схлопывается до короткого, и второй RecordSetModule.bsl падает как повтор. Таких одноимённых модулей в конфигурации десятки. Рабочий вариант - поштучно и с полными путями.
Пятая. Полные пути упёрлись в MAX_PATH: внутри архива путь с клиента, к нему добавляется временный каталог сервера, суммарно за 260 символов. Windows отвечает «The filename or extension is too long». Ограничение системное, и хотя длинные пути в свежих версиях Windows включаются политикой, полагаться на настройку чужой машины нельзя. Решение нашлось в поштучном извлечении: вместо ИзвлечьВсе() идём по Чтение.Элементы и кладём каждый файл в свою короткую пронумерованную папку, а оригинальный путь берём из Элемент.Путь - он нужен, чтобы в отчёте остались нормальные имена объектов.
Что стоит сделать перед своим переходом
- Не рассчитывайте на свежесть конфигурации. База на последнем релизе получает почти тот же список работ, что и база двухлетней давности: платформенные изменения обновлением конфигурации не закрываются.
- Посмотрите режим совместимости. Он снимает часть вопросов, но только ту, которую вы уже прожили.
- Проверяйте код, а не только метаданные. На обеих базах половина находок оказалась в текстах модулей.
- Не пропускайте типовую поставку. Семь мест с устаревшим свойством нашлись в коде вендора.
- Отдельно посмотрите неисправленные ошибки 8.5.1 по своей функциональности: расширения, PDF, HTML-документ, полнотекстовый поиск, регистры расчёта.
- Проверьте версию СУБД. У 8.5.1 подняты минимальные требования, и выясняется это до обновления платформы, а не после.
Обработка
Всё описанное собрано в обработку «Помощник перехода на 8.5». Работает на 8.3.20 и выше, то есть до перехода, на вашей текущей платформе. Две кнопки: быстрый анализ живой базы за секунды и полный с выгрузкой и разбором кода. Разбирает конфигурацию, расширения и внешние обработки из справочника дополнительных обработок.
Чистый встроенный язык, без БСП и внешних компонент. К СУБД не подключается, в базу не пишет, в интернет не ходит. Подробное описание, требования и ограничения - в карточке: Помощник перехода на 1С:Предприятие 8.5.
Что я об этом думаю
Главным выводом я считаю не цифры, а то, что свежая база оказалась почти в том же положении, что и старая. Мы привыкли считать регулярное обновление конфигурации формой готовности к будущему. К смене платформы это не относится.
А самым полезным опытом - ту арифметическую сверку. Инструмент был написан, протестирован и уже выдавал красивые отчёты, в которых главная функция молча не работала. Поймала это не проверка кода, а сложение чисел в столбик.
Другие наши инструменты
- Проверка базы данных перед миграцией на PostgreSQL - что в базе помешает переезду на другую СУБД;
- Чек-ап СУБД под 1С - как сервер СУБД настроен под 1С, 40+ проверок с вердиктом;
- Карта объёмов базы 1С - из чего состоит база и что в ней растёт.
Вступайте в нашу телеграмм-группу Инфостарт