gifts2017

Технология обновления типовых конфигураций с изменениями

Опубликовал Никита Долгих (Nik_1c_bitrix) в раздел Программирование - Практика программирования

Данная статья написана для программистов начального уровня, но уже имеющих представление о объектах системы и их функциональных возможностях. И так Вам поставлена задача: «Обновить типовую конфигурацию, в которую кто-то, когда-то вносил изменения».

Первое что необходимо сделать, это внимательно изучить статьи на данную тему. Например, вот эти: http://infostart.ru/public/18562/, http://infostart.ru/public/18596/ , http://infostart.ru/public/141359/. В них подробно и понятно объясняются ключевые моменты обновления типовых конфигураций.

Чего там нет? Собственно самой технологии обновления. То есть поэтапного описания действий при анализе Основной конфигурации и Обновления. Попробуем описать этот процесс в виде алгоритма:

  1. После того как вы сделали копию информационной базы, запустили механизм обновления. Появится окно сравнения, объединения конфигураций.
  2. Понять какие объекты были изменены в конфигурации до Вас. Это можно сделать при помощи установки фильтра:  Показывать отличия основной конфигурации от старой конфигурации поставщика(не забудьте при этом проверить текущий релиз конфигурации поставщика).
  3. Понять какие объекты должны будут изменены в ходе обновления. Это можно сделать несколькими способами. Первый способ, использовать файл описания изменённых объектов который можно найти в каталоге обновления либо на сайте users.v8.1c.ru. Второй способ, отключить фильтр, установить шаблон в значение «Показывать все». В этом случае все изменённые объекты будут содержать отметку о изменении объекта напротив соответствующего объекта в колонке (зеленый карандаш).

  4. На следующем шаге необходимо обратить внимание на объекты, которые были изменены до Вас и которые необходимо изменить в ходе обновления. Для этого установим фильтр: Показывать только дважды измененные объекты. С этими объектами необходимо разбираться в первую очередь. Итак, если объект изменен,  это означает что изменилось одно из следующих составляющих:
    1. Изменено какое-либо свойство объекта;
    2. Изменены реквизиты объекта или реквизиты табличной части объекта;
    3. Изменён макет объекта;
    4. Изменён модуль объекта;
    5. Изменена форма объекта.
  5. По каждой составляющей необходимо принять решение о объединении.
    1. Если свойство объекта изменено в основной конфигурации и не изменяется в обновлении, то в этом случае необходимо установить соответствующий режим объединения этих свойств: «Объединить с приоритетом основной конфигурации».
    2. Если свойство объекта не изменялась в основной конфигурации (нет зеленого карандаша рядом с свойством в колонке «Основная конфигурация») в этом случае необходимо установить режим: «Взять из загружаемой конфигурации».
    3. Если свойство объекта было изменено в основной конфигурации, и должно быть изменено в ходе обновления: В этом случае можно устанавливать одно из возможных вариантов объединения. Примем за основу тот факт, что при обновлении необходимо максимально сохранить доработанный функционал, при этом добавив обновление в конфигурацию. В этом случае в зависимости от того что изменилось Модуль объекта, модуль формы или свойство, реквизит, макет, элементы формы будет разная стратегия обновления. Итак, если изменения коснулись модуля: Можно принять решение о каждом конкретном изменении, при этом существует 4 различных варианта исхода:
      1. Взять из загружаемой конфигурации.
      2. Объединить с приоритетом основной.
      3. Объединить с приоритетом загружаемой конфигурации.
      4. Отключить объединение модуля.

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

  1. Взять из загружаемой конфигурации.
  2. Объединить с приоритетом основной
  3. Объединить с приоритетом загружаемой конфигурации.
  4. Отключить объединение объекта.

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

5. В целом для объектов, которые остались нетронутыми можно установить такие режимы объединения. Если объект был изменен по сравнению  со старой конфигурацией поставщика, то его не нужно вообще обновлять. То есть необходимо снять флаг объединения. Если объект нужно обновить, необходимо установить режим в значение: «Взять из загружаемой конфигурации». Более детально о том какой результат объединения получится в результате установки того или иного режима для различных объектов можно почитать.

6. После настройки режимов обновления необходимо нажать кнопку «Выполнить».

7. Иногда возникает проблема в ходе обновления, что ссылка на какие-либо объекты использующиеся в других объектах не участвуют в обновлении при этом система выводит соответствующее сообщение. Необходимо вернуться в режим сравнения и объединения и выбрать вариант объединения этих объектов.

 8. Еще одна ситуация к которой необходимо отнестись с вниманием, это вот такое сообщение:

(смотри картинку анонса:)


Коротко говоря: «Вы сотрете доработки конфигурации». Нужно вернуться и еще раз все проверить, или же осознано выполнить замещение объектов.

9. Желаю удачи!

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Евгений Сосна (pumbaE) 22.05.14 21:40
0. Сделать копию.
Дмитрий74Чел; 3762515; gigaline; ПиН; oninfostart; Mi4man; lamp; GATTUSO; alanto23; k_zanna; wolfsoft; +11 Ответить
2. Дмитрий Елисеев (w-divin) 23.05.14 12:50
Хорошо описано. Плюс. Мне кажется стоило бы добавить, что в процессе обновления стоит пересмотреть все изменения в модулях и по возможности максимально вынести их в сторонние обработчики (подписки на события, общие модули обработки объектов), чтобы облегчить себе и другим дальнейшую поддержку...
3. aleks (maldinitaly) 28.05.14 11:30
Спасибо, все хорошо написано. Никогда не хватало времени все это описать по пунктам.Автору плюс.
4. Serg (Sykoku) 28.05.14 11:34
У меня несколько иной подход.

1. Существует база "Пустышка". Это копия рабочей базы со всеми необходимыми изменениями, но без данных.
2. Создается "Копия" текущей базы.
3. Обновляется "Пустышка". Обновление происходит по возможности с объединением с приоритетом загружаемой, т.к. существуют документы, модули, обработки, разделы меню и т.д., для которых уже установлены Права и Роли. Раздавать их заново долго и неправильно.
4. Происходит экспорт конфигурации "Пустышки" в файл.
5. Сравнивается конфигурация "Копии" с "Пустышкой". Здесь основная работа: поиск отличий и внесение этих отличий в "Пустышку". Для удобства работы каждое изменение кода помечено маркерами начала и конца. В первую очередь поиск идет по маркерам.
6. По окончании всех работ еще раз экспорт конфигурации "Пустышки".
7. Объединение рабочей конфигурации с "Пустышкой".

Все телодвижения занимают часа 2 для УТП 1.2.
В последний раз был глюк при обновлении до релиза 20.08 - 1С наконец-то включила поддержку драйверов от Арт-Софт (3 года упорно доказывали, что это не их глюк, а виноват поставщик драйверов, касса или инсталятор) и при запуске отвалилась касса. Проблема решилась еще за полчаса.
5. Andrey Andriyashin (andr_andrey) 28.05.14 14:59
(4) Sykoku,
"7. Объединение рабочей конфигурации с "Пустышкой". "
А как потом обновляете конфигурацию поставщика?
6. Денис Vvv (EvilDoc) 28.05.14 15:14
(5) а зачем? просто хранить типовую актуального релиза. я сравниваю свою конфу с такой же типовой, сравниваю 2 типовых и сравниваю текущую с типовой на которую нужно обновить. Все в разных базах. Благо 2 моника
7. Andrey Andriyashin (andr_andrey) 28.05.14 19:28
(6) EvilDoc,
просто так легко "потерять" конфигурацию поставщика. Пустышку надо бэкапить (хранить как зеницу ока), помнить и передавать любому новому 1Снику, а если конфигурация поставщика в рабочей базе есть, то ежедневно бэкапится all-in-one.
Рекомендую задавать себе вопрос "Если меня не станет завтра, как будет "жить" решение". Если возможны нюансы, надо сделать более просто и лаконично.
8. Денис Vvv (EvilDoc) 29.05.14 01:44
(7) Да, типовую конфу текущей версии приходится хранить. Ну а если она потеряется или новый сотрудник ее не найдет - всегда можно скачать релиз и обновить до текущей версии. Да долго, ну а чего делать. Но пока-что продлем не было - и мне передали все и я храню все. И соответственно передам
9. Леонид Павлиенко (PLAstic) 29.05.14 07:13
Пункт 3 убрать из текста вообще. При фильтре из п.2 мы итак видим объекты, изменëнные по отношению к конфигурации поставщика, но не все (как если бы сравнивать конфигурацию поставщика и основную через пункт меню "Сравнение конфигураций"), а только те, что меняются в новой конфигурации поставщика. Именно этот фильтр позволяет провести оценку "что менялось мной и что изменено авторами".
10. Александр Антоненко (alanto23) 29.05.14 08:57
Статья неплохая. Только не полная. Не освещен, на мой взгляд очень важный, последний шаг - когда делаем "Объединение объекта с приоритетом основной" в код модулей добавляются фрагменты изменений. По умолчанию они закомменчены и выделены символами {{MRG[ < - > ] или {{MRG[ < - ] или {{MRG[ - > ]. Стрелка указывает какая конфигурация была изменена. Основная, поставщика или обе. Такие символы ставятся в начале и конце измененного блока.
И вот последний шаг: Открываем конфу в конфигураторе, делаем глобальный поиск по символам: {{MRG[ и анализируя изменения, принимаем решение - поменять блок кода или оставить все как есть.
Если выбираем пункт "Объединение объекта с приоритетом поставщика" - смысл тот же, только комментариями становятся измененные блоки кода основной конфигурации. А изменения от поставщика вставляются в рабочем состоянии.
И нужно не забывать удалять этот отработанный мусор. Иначе, если пару тройку раз обновиться с "Объединением" - потом в модулях сам чёрт ногу поломает! :)
mairon; Дмитрий74Чел; Csar; artbear; suggestive; +5 Ответить 1
11. Александр (Trinitron) 30.05.14 15:22
спасибо большое за статью, как начинающему, было очень полезно прочитать, возьму на заметку данную статью
12. mic auto (4ur) 01.06.14 17:19
все правильно, только как бороться с внедренцами, которые не придерживаются никаких требований при внесении изменений в конфигурацию. К сожалению таких достаточно много, и хотят они таким образом максимально привязать клиента к себе. У нас просто внедряют УПП, внедренцев выбирал фин. дир., никто с ИТ не советовался, вот теперь приходиться за ними, как мусорщики, с совком и веником, все подчищать...
13. mic auto (4ur) 04.06.14 20:20
На сайте http://www.gilev.ru/author/admin/ есть рекомендация - отключать режим совместимости с 8.2.13 для повышения производительности базы на SQL, никто не может подсказать, как при таком отключении будет проходить обновление конфигурации?
14. ффф ыыы (zqzq) 24.06.14 08:17
(10) alanto23, более удобно попроцедурно настраивать режим объединения модулей (справа от модулей через лупу), часто нетиповые и типовые изменения в разных процедурах и достаточно расставить режимы объединения, тогда и постобработка не нужна.
Очередная статья, которая на эту неочевидную для новичков фишку не обратила внимания. Кстати, в 8.3 обещают kdiff прикрутить и сразу редактировать объединение.

Также была статья, затерявшаяся на просторах инфостарта. Там почерпнул полезную контрольную проверку - выгрузить в текст полное описание изменений Поставщик-Основная до обновления и после. Далее эти 2 файла сравнить (через kdiff, штатный не очень). Сразу все косяки обновления обнаружатся + кое-что полезное.
daho; suggestive; +2 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа