Новая возможность

В свойствах баз обновлятора (в версиях после 3 ноября 2017 года) появилась вот такая замечательная опция:

Сразу оговорюсь, что работать эта возможность будет только с платформой 1С равной или старше 8.3.8.1652. Именно начиная с этой версии 1С позволяет выполнять обновление доработанных конфигураций в пакетном режиме.

Когда она может быть полезна

Ну, например, вы регулярно обновляете одну и ту же дописанную конфигурацию и хотите облегчить себе работу.

При этом все дописки вы знаете и они у вас задокументированы.

В таком случае может быть проще и быстрее:

1. Сначала обновить конфигурацию обновлятором (установив соотв. галку в свойствах базы)
2. Затем посмотреть отчёт обновления в обновляторе (там будут указаны свойства, измененные дважды)
3. И только после этого проверить, что все доработки на месте и вернуть те, что были утеряны (об этом смотрите ниже, где я рассказываю как работает автоматическое обновление доработанных конфигураций)

При таком способе работы вам не нужно:

1. Скачивать необходимые обновления
2. Открывать конфигуратор и применять эти обновления
3. Ожидать пока выполнится обновление конфигурации
4. Ожидать пока выполнится обновление базы данных

Вы вообще можете запланировать такое обновление на ночь, а уже утром произвести контроль и доработку, если она потребуется.

И если доработки конфигурации небольшие, то в большинстве случаев вам после обновления вообще не придётся ничего делать.

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

Как работает автоматическое обновление доработанных конфигураций

Само обновление происходит при помощи того же пакетного ключика updatecfg, но при этом обновлятор дополняет эту команду специальным файлом настроек в формате xml.

Обновление происходит с приоритетом новой конфигурации, при этом:

1. Если вы добавляли в конфигурацию новый объект - обновление его не затронет.
2. Если вы добавляли в конфигурацию новый реквизит в уже существующий объект типовой (от поставщика) - обновление его также не затронет.
3. Если вы меняли в конфигурации объект поставщика, но он не изменился в этом обновлении, то он останется как есть.
4. Но, если вы меняли в конфигурации объект поставщика, и он изменился в этом обновлении, то возьмётся версия из обновления. При этом в отчёте обновлятора этот объект будет отмечен как "дважды измененный".

При этом, при настройке по умолчанию...

... обновлятор останавливается сразу после обновления конфигурации, если были обнаружены свойства, измененные дважды. Это делается для того, чтобы вы смогли сначала вернуть необходимые доработки, а уже затем запустить обновление базы данных.

Я очень надеюсь, что эта возможность позволит высвободить ещё немного часов от ручного, монотонного труда.

Если у вас есть замечания или пожелания по этой возможности - я всегда рад вас выслушать, пишите мне на helpme1c.box@gmail.com

Как настроить финальное объединение с эталонной конфигурацией

Чтобы стало понятнее о чём речь, приведу рабочий пример у одного из пользователей обновлятора.

У него 40 бухгалтерских баз. Все они содержат одну и ту же доработанную конфигурацию.

Обновлять приходится зачастую на несколько релизов и он для максимальной корректности делает это всегда последовательно с выполнением обработчиков обновления после каждого релиза.

Алгоритм работы до автоматизации у него был такой:

"В ручном режиме обновляю до последнего релиза одну базу; в последнем релизе тестирую, добавляю все изменения, которые были потеряны, в модулях форм документов, общих модулях. Затем обновляю остальные базы до последнего релиза и в конце объединяю с подготовленным cf файлом  из первой базы."

Он обратился ко мне за помощью в автоматизации всей цепочки действий кроме "в последнем релизе тестирую, добавляю все изменения, которые были потеряны, в модулях форм документов, общих модулях".

С пакетным обновлением доработанных баз до последнего релиза обновлятор (учитывая возможность, описанную выше) справляется на ура, но вот объединять конфигурацию с подготовленным cf в пакетном режиме обновлятор не умел.

И я доработал эту возможность.

Чтобы заставить обновлятор после применения обновления следом выполнить ещё и объединение с конфигурацией из файла - необходимо расположить файл с конфигурацией для объединения в папку обновления под именем MergeThisFileAfterUpdate.cf

В рассмотренном выше примере предположим, что требуется обновить все 40 конфигураций на следующие релизы (и пусть они для упрощения задачи будут ключевыми, то есть их нельзя перескакивать): 2.0.60.1, 2.0.60.2 и 2.0.60.3.

Алгоритм наших действий с учётом автоматизации обновлятором будет следующим:

1. Обновить при помощи обновлятора одну из конфигураций до версии 2.0.60.3
2. Добавить все изменения, которые были потеряны... проверить работоспособность обновлённой конфигурации.
3. Выгрузить эту конфигурацию в папку с обновлением 2.0.60.3 под именем MergeThisFileAfterUpdate.cf
4. Запустить обновление (с включенной возможностью обновления доработанных конфигураций) оставшихся 39 баз.
5. Обновлятор в этом случае для каждой из 39 баз:
   1. выполнит пакетное обновление на 2.0.60.1
   2. выполнит обработчики обновления
   3. выполнит пакетное обновление на 2.0.60.2
   4. выполнит обработчики обновления
   5. выполнит пакетное обновление на 2.0.60.3
   6. обнаружит, что в папке с обновлением 2.0.60.3 лежит файл MergeThisFileAfterUpdate.cf
   7. выполнит пакетное объединение нашей конфигурации с конфигурацией из файла MergeThisFileAfterUpdate.cf (о настройках такого объединения смотрите ниже)
   8. выполнит обработчики обновления

При этом пакетное объединение выполняется через пакетный ключик конфигуратора mergecfg и следующий файл настроек (передаётся через ключ settings):

<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://v8.1c.ru/8.3/config/merge/settings" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1">
    <Parameters>
        <ConfigurationsRelation>SecondConfigurationIsDescendantOfMainConfiguration</ConfigurationsRelation>
        <AllowMainConfigurationObjectDeletion>true</AllowMainConfigurationObjectDeletion>
        <CopyObjectsMode>false</CopyObjectsMode>
    </Parameters>
</Settings>

Такие настройки объединения позволяют нам привести нашу конфигурацию (которая всё ещё на поддержке) к конфигурации в файле MergeThisFileAfterUpdate.cf, в которую мы внесли и исправили все наши доработки.

Объединение с эталонной конфигурацией как отдельная операция

Предположим, что нам требуется выполнить массовое объединение конфигураций наших баз, чтобы внести в них доработанный функционал.

Эта возможность доступна на закладке "Скрипты" в главном окне программы.

Тип скрипта "Пакетный". Из меню следует выбрать пункт "Обновлятор"->"Методы"->"Объединить с конфигурацией из файла":

В скрипт вставится вот такой текст:

Путь к файлу, с которым нужно выполнить автоматическое объединение, у вас, конечно, будет свой.

А чтобы сразу после изменения конфигураций выполнить обновление конфигураций баз данных, допишем этот скрипт следующим образом:

Получается, что в начале мы выполняем объединение конфигураций при помощи команды обновлятора merge_cfg, а затем выполняем обновление конфигураций баз данных при помощи пакетного ключика конфигуратора UpdateDBCfg.

Вторую команду можно вставить в скрипт из меню шаблонов: