Каталог решений - Обновление изменённой типовой конфигурации 1С 8.2/8.3

Инструкций по обновлению изменённых типовых конфигураций платформы 1С — очень много. Поэтому, чтобы не увеличивать сущности, не буду полностью описывать весь процесс. К тому же — предполагается, что этот текст для человека, который уже обновлял изменённые конфигурации и знает основные моменты и «подводные камни». Данный метод лишь упрощает этот процесс, по сути предлагая использовать автоматизированное сравнение изменений конфигурации и внесения изменений в модулях на уровне сравнения текстовых файлов. При таком подходе, сильно уменьшается вероятность ошибок («затирание» обновлением важных изменений из-за невнимательности), связанных с «человеческим фактором».

ЛЮБОЕ обновление конфигурации начинается с выгрузки ИБ. Это «золотое правило», это надо помнить всегда, это надо делать при любом методе (даже если там про это забыли сказать). Далее, можно пойти двумя способами: либо обновлять в тестовой базе, либо обновлять в рабочей базе. Тут важный момент в следующем: обычно изменённые конфигурации обновляют не на каждый релиз (как это можно легко делать с типовыми), а сразу на несколько, поскольку этот процесс трудозатратный. В первом способе (обновлять на тестовой базе) — предполагается итоговый перенос обновления на рабочую базу через загрузку cf-файла. В этом случае могут произойти ошибки, связанные с удалёнными реквизитами (об этом можно найти множество статей). Стало быть — есть некоторые риски, но зато во время обновления (которое может занять целый день и даже дольше), пользователи могут спокойно работать, изменяя базу данных. Во-втором способе (обновлять на рабочей базе) — эти риски исключены, но на всё время обновления ключевые пользователи не смогут работать в этой базе. В форумах есть достаточно обсуждений, какой метод чем хорош и стоит-ли переносить обновление через файл конфигурации. Могу лишь сказать: исходя из опыта работы по первому способу, подобных ошибок не случалось при загрузке cf-файла. В любом случае — по бэкапу можно восстановить базу. Здесь будет рассматриваться именно первый способ, но на суть метода это не влияет и при желании можно действовать по второму способу, используя предложенный метод.

Итак — развернув тестовую базу по свежему бэкапу, производим последовательные обновления релизов до последнего. После каждого релиза запускаем «Отладку», для сохранения изменений в конфигурации и реорганизации данных. Во всех диалоговых окнах жмём ОК/Далее/Принять/Да/Продолжить…

Таким образом, мы обновили конфигурацию на тестовой базе до последнего релиза, но необходимо проверить, не затёрли-ли мы какие-нибудь изменения и если затёрли, то надо их перенести на этот релиз. Теперь начинается самое интересное, поэтому опишу это пошагово. Каждый шаг будет с некоторым пояснением: то есть, сначала описана суть, а далее — более подробное описание. Если суть понятна, то описание можно опускать.

1. Сохраняем в текстовых файлах изменения конфигурации ДО и ПОСЛЕ обновления. Открываем в режиме Конфигуратора рабочую и тестовую базы. Открываем в них конфигурации. И в обеих базах запускаем обработку сравнения конфигурации («Конфигурация — Сравнить конфигурации…»). ВАЖНО: в обеих базах одинаково выбирать конфигурации:

Далее, в окне результата сравнения кликаем правой кнопкой мышки по названию конфигурации (самая верхняя строка), выбираем «Отчёт о сравнении объектов…» и сохраняем в виде текстового файла:

Причём сохраняем следующим образом: в рабочей базе (где конфигурация ДО обновления) — в файл с окончанием «old», а в тестовой базе (где конфигурация ПОСЛЕ обновления) — в файл с окончанием «new».

2. Внесение утерянных изменений в обновлённую конфигурацию. Переходим к ключевому этапу метода. Поскольку это основной пункт, то для небольшого пояснения происходящего немного мат.части. На платформе 1С 7.7 файл обновления представлял собой полную конфигурацию. И обновление в 1С 7.7 заключалось в загрузке новой конфигурации и реорганизации базы данных под эту конфигурацию. Таким образом, и конфигурация, и обновление по сути были одним и тем же md-файлом.  В отличии от платформы 1С 7.7, на платформе 1С 8.x: конфигурация передаётся через cf-файл, а обновление — через cfu-файл. Отличие этих файлов в том, что cf-файл содержит все объекты конфигурации, а cfu-файл — только те, которые изменяются данным обновлением. И, таким образом, при обновлении на платформе 1С 8.x затрагиваются только те объекты конфигурации, которые реально изменились в новом релизе. В результате, если такой объект изменялся нами, то после обновления он полностью заменится на типовой, и нам будет необходимо повторить в нём те изменения, которые были у него до обновления так, чтобы этот объект содержал и наши изменения, и изменения нового релиза, одновременно. Но зато если изменённый нами объект конфигурации не затрагивался обновлением — в нём останутся наши изменения после обновления. Чтобы проще это понять — изображу это в виде схемы:

На данной схеме изображена некоторая типовая конфигурация в процессе изменения и обновления. Строки — это её объекты (документы, справочники, обработки и так далее). Сначала (под номером I) — это просто типовая конфигурация: все объекты без каких-либо изменений. Потом, под номером II, мы уже видим типовую изменённую конфигурацию: некоторые объекты были изменены и эти изменённые объекты обозначены красным цветом. Под номером III — это очередное обновление для типовой конфигурации: по сути оно содержит только затронутые изменениями нового релиза объекты, которые обозначены зелёным цветом, но для наглядности я дорисовал и все остальные объекты. И нам требуется получить обновлённую типовую конфигурацию (изображённую на схеме I), но с изменениями и схемы II, и схемы III. На данном примере — эта конечная конфигурация изображена под номером IV и содержит один объект, который был изменён и нами, и обновлением. Остальные изменённые нами объекты, очевидно, остались нетронутыми данным обновлением. Теперь вопрос: как внести ВСЕ наши изменения в объект, который был затронут обновлением? Очевидно, что нам надо сделать два шага: во-первых, отыскать этот объект, а во-вторых — найти в нём места, где должны быть наши изменения и внести их заново. Замечу, что, естественно, таких объектов может быть несколько и требуется их всех найти и исправить. Итак, приступим к этому последнему этапу обновления. На данный момент, у нас должна быть открыта тестовая база в режиме Конфигуратора. Если там ещё открыт результат обработки сравнения конфигураций или ещё какое-нибудь окно — закроем их всех, чтобы не путаться. Далее — мы открываем рабочую базу в режиме Конфигуратора (на время обновления тестовой базы можно было закрыть её) и запускаем там сравнение конфигураций. И описание последних двух шагов (найти и исправить) я помещу в отдельные подпункты:

2.1. Поиск объекта, с затёртыми обновлением изменениями. Самое время вспомнить про txt-файлики с окончаниями old/new. На самом деле, в этих файлах отражены все изменения конфигурации (относительно типовой) ДО и ПОСЛЕ обновления соответственно. Таким образом, если мы какое-то изменение затёрли обновлением, то оно будет только в файле «ОтчетОСравнении_old.txt». То есть — поиск необходимых объектов конфигурации сводится к сравнению этих двух файлов. Сравнивать эти файлы мы будем с помощью файлового менеджера Total Commander и его встроенных инструментов. Думаю, что здесь не нужно пояснять, что такое Total Commander, где его брать и как им пользоваться… Тем не менее, требуемые этапы его применения здесь кратко буду описывать. Итак, запускаем Total Commander. Если язык интерфейса английский (главное меню и так далее), то можно сменить на русский: «Configuration — Options…», в диалоговом окне выбираем в левом столбике раздел «Language», в списке ищем/выбираем «Russian (Русский)» и жмём «OK». Далее, через Total Commander ищем txt-файлы отчётов, выделяем их («Insert» или «правым кликом мышки») и запускаем сравнение файлов: «Файлы — Сравнить по содержимому…» (в английском интерфейсе: «Files — Compare By Content…»). В открывшемся окошке слева/справа отображается соответственно содержимое файлов, кнопки «Следующее отличие»/»Предыдущее отличие» позволяют искать различия. Этот инструмент позволит быстро найти интересующие нас объекты.

Замечание: может случиться и обратная ситуация — в конфигурации ПОСЛЕ обновления появились различия, которых не было ДО обновления. Это означает, что релиз обновления удалил из конфигурации соответствующие объекты. В принципе, эти объекты можно просто пропускать в наших исправлениях, посколько в этих объектах не было изменений.

2.2. Внесение изменений в обновлённые объекты. После того, как мы нашли объект с затёртыми изменениями, надо определить, где именно были эти изменения: в модуле (программном тексте), диалоговом окне (на форме) или иных настройках. Здесь я буду разделять два случая: изменение в модуле и все другие изменения. И рассмотрим эти два случая отдельно.

2.2.1. Затёртые обновлением изменения были в модуле. На самом деле, это основной случай (такое встречается намного чаще) и этот случай как раз в нашем примере: изменение удалились в модуле «УчётНДС». Как выше мы уже напоминали, что в Конфигураторе рабочей базы у нас открыто окно сравнения конфигураций. Ищем там необходимый нам объект. На самом деле, его положение в дереве конфигурации описано в нашем текстовом файле, а именно: «ОбщийМодуль.УчетНДС.Модуль». Именно так и ищем в окне сравнения. Разворачиваем дерево подчинённостей пока не найдём нужный модуль — с левого края напротив него должен быть зелёный карандаш, показывающий, что объект изменён по сравнению с конфигурацией поставщика. По найденной строке кликаем правой кнопкой мышки и выбираем «Показать различия в модулях…»:

После этого откроется окно сравнения модулей:

Здесь, в верхней части указаны процедуры и функции, в которых имеются изменения (в нашем случае — это одна процедура «ВывестиСчетФактуруВТабличныйДокумент»), а в нижней части — тексты выбранной процедуры или функции с выделенными изменениями. Нам нужно эти изменения перенести в нашу тестовую базу. Но при этом не удалить изменения от обновления. Автоматизировать это можно следующим образом. Устанавливаем курсор в левую нижнюю часть (где текст выбранной процедуры с нашими изменениями) и жмём последовательно Ctrl+A (выделить всё) и Ctrl+C (копировать выделенное в буфер). Затем создаём файл с условным названием «old_izm.txt», открываем в текстовом редакторе и жмём Ctrl+V (вставить содержимое буфера). То же самое делаем для правой нижней части (где текст выбранной процедуры из типовой конфигурации необновлённого релиза) — в результате создаём файл с условным названием «old_type.txt». После этого переходим в Конфигуратор тестовой базы (он должен быть открыт рядом, но без каких-илбо окон внутри, чтобы не путаться в этих двух конфигураторах) — и в конфигурации ищем наш модуль (в данном примере это «ОбщийМодуль.УчетНДС.Модуль») и в нём необходимую процедуру (в данном примере это «ВывестиСчетФактуруВТабличныйДокумент»): выделяем её всю и копируем в новый текстовый файл с условным названием «new_type.txt». Таки образом, у нас появилось три файла («old_izm.txt», «old_type.txt», «new_type.txt»), на основе которых нам нужно создать четвёртый файл — «new_izm.txt». В этом четвёртом файле как раз должны содержаться наши изменения, но с учётом обновления. Его мы будем формировать последовательно сравнивая имеющиеся три файла. Для начала определим, имеются-ли в этой процедуре следы изменений обновления? Для этого мы сравниваем через Total Commander (см. выше) файл «old_type.txt» и «new_type.txt». Если сравнение показало, что файлы идентичны или различие в количестве пробелов или знаков табуляции — это значит с этим куском изменений нам повезло и перенести изменения можно просто скопировав содержимое файла «old_izm.txt» и вставив в открытый модуль тестовой базы, удалив перед этим соответствующую процедуру (проще говоря — заменив её). Тут важно аккуратно следить за пробелами до и после процедуры, чтобы не было лишнего в дальнейшем сравнении: на функциональность это, конечно, не повлияет, но слегка затруднит проверку. Если же сравнение «old_type.txt» и «new_type.txt» показало, что есть реальные различия — это означает, что в этой процедуре имеются как наши изменения, так и изменения обновления. Чтобы упростить задачу переноса: сначала можно визуально оценить, каких изменений больше — от обновления или наших. Для этого опять же через Total Commander последовательно сравниваем «old_type.txt» с «new_type.txt» и «old_izm.txt». И смотрим, где изменений больше: в сравнении «old_type.txt» и «new_type.txt» или в сравнении «old_type.txt» и «old_izm.txt». Если изменений больше в первом сравнении (обновление сильнее изменило функцию), то легче исправлять файл обновлённый, внося наши изменения, то есть — изменяем «new_type.txt». Условно назовём это первый случай внесения изменений. Если изменений больше во втором сравнении (у нас было больше изменений), то легче исправлять наш файл, внося изменения обновления, то есть — изменяем «old_izm.txt». Условно назовём это вторым случаем внесения изменений. Теперь, как именно быстро и точно перенести изменения. Для этого мы создаём четвёртый файл и, как уже договаривались, называем его «new_izm.txt». С учётом оптимизации переноса исправлений, копируем в этот файл содержимое либо «new_type.txt», либо «old_izm.txt» (соответственно, для первого или второго случая внесения изменений).
Теперь открываем сразу два окна сравнения файлов. Для первого случая внесения изменений — это сравнения для файлов «new_izm.txt»/»old_izm.txt» и «old_type.txt»/»old_izm.txt». Для второго случая — это сравнения файлов «new_izm.txt»/»new_type.txt» и «old_type.txt»/»new_type.txt». В окне сравнения есть кнопка «Редактирование»: нажмём её в сравнении первой пары. Теперь поясним, что мы видим. В первой паре сравнения видны объекты и от нашего изменения, и от обновления. В соответствии, какой у нас случай, нам надо перенести изменения только наши, либо только обновления. Во втором окне сравнения — как раз видны только те изменения, которые мы должны перенести. Если обратить внимание — в обоих случаях, второй файл и первого, и второго сравнения — один и тот же. Поэтому мы ориентируемся на строки в этом файле, и по строкам во втором сравнении, вносим изменения в окне первого сравнения: нажатая кнопка «Редактирования» как раз позволит нам это сделать.

Для «наглядности» изобразим графически действия при переносе в первом случае (изменяем обновлённый файл, внося наши изменения):

Действия во-втором случае — абсолютно аналогичны и принцим действия ровно такой-же.

Самый сложный и неприятный случай — когда наши изменения и изменения обновления — в ОДНОМ месте. То есть реально на одном сегменте кода были два изменения. В таком случае требуется вмешательство программиста. Так же вмешательство программиста, но в меньшей степени, требуется, если, например, обновлением изменены имена переменных, которые используются в наших изменениях. Стоит заметить так же, что в файле «old_type.txt», либо «old_izm.txt» могут быть пустые строки — это «следа» наших измений. Переносить надо так, чтобы в конечном файле их не было. На функциональность это не влияет, но в дальнейших сравнениях (при последующих обновлениях) — это немного затруднит анализ действий. Итак, после того, как мы сформировали четвёртый файл, перенеся все изменения — надо его содержимое скопировать в конфигурацию. В Конфигураторе тестовой базе, должен быть открыт нужный модуль на новом месте: удаляем существующую процедуру и вставляем содержимое нашего конечного файла, с учётом всех пробелов между предыдущими/последующими функциями. Таким образом мы перенесли изменения ОДНОЙ процедуры найденного объекта. У нас (рис. 6) эта процедура действительно одна. Если таких процедур несколько — описанные действия надо проделать для каждой. Если процедура новая (только в левой половинке) — то просто добавить её в соответствующий модуль в тестовой базе (для корректности дальнейшего сравнения — нужно сохранить порядок процедур, как в соответствующем модуле рабочей базы, где ещё старый релиз).

2.2.2. Затёртые обновлением изменения были НЕ в модуле. Для переноса таких изменений подобное сравнение никак не упростит работу, поэтому переносятся изменения просто визуальным сравнением объектов в рабочей и тестовой базах.

Таким образом — переносим изменения для каждого объекта, где наши изменения затёрлись обновлением. Чтобы проверить, насколько мы верно перенесли все изменения — сохраняем конфигурацию в тестовой базе, выгружаем сравнение конфигураций в файл «ОтчетОСравнении_new2.txt» и сравниваем с файлом «ОтчетОСравнении_old.txt». Если всё идиально, то будет сообщение «Файлы идентичны». Если обновлением были удалены какие-то объекты — то при правильном переносе изменений будут видны только эти объекты в различии. Правильным будет если в сравнении будут видны только пробелы/пустые строки/табуляции, но в таком случае лучше это вычищать и добиваться сообщения «Файлы идентичны». Таким образом, после сохранения изменений в тестовой базе, выгружаем сравнение в файл и сравниваем с изменениями в старом релизе — повторяем это до тех пор, пока сравнение не покажет, что мы перенесли все требуемые изменения.

3. Переносим обновлённую конфигурацию из тестовой в рабочую базу. На предыдущих этапах мы обновили тестовую базу до последнего релиза, проверили и перенесли необходимые изменения и сохранили полученную конфигурацию. Теперь мы её выгружаем в cf-файл и загружаем в рабочую базу. Перед загрузкой — необходимо сделать копию рабочей базы и снять с поддержки конфигурацию. ВСЁ. Пользователи «бездельничали» только в начале, когда мы выгружали базу, и в конце, когда мы снова выгружали базу и загружали конфигурацию.

На этом обновление полностью завершено.

Оригинал статьи находится на сайте  get-prog.ru