Доброго времени суток! Вопрос как обновлять конфигурации с большим количеством правок на несколько релизов. Обновлять рабочую базу не вариант совсем - у клиента работа встанет. Обновлять копию? То есть тогда неважно, обновлю я пошагово конфигурацию релиз за релизом или накачу последний cf? На рабочую базу все равно натягивать итоговый cf с правками. Как делаете вы?

Всю жизню бухию обновляю путем загрузки финального CF

(1) Ну, не от большого.... опыта такие действия.

(2) Ну я к тому что за 10 лет проблем небыло. Но это в бухии и в ЗУП. Но поговаривают что в УТ были с этим проблемы, т.е. cf не всегда содаржит полный набор обновлений для предыдущих версий и скачки могут привести к проблемам. Но у меня опыта с УТ/КА/УПП/ERP нет, поэтому не могу ничего сказать. А вот бухия и ЗУП спокойно переживает такие скачки через несколько релизов

(3)>> т.е. cf не всегда содаржит полный набор обновлений для предыдущих версий и скачки могут привести к проблемам
Это не так. Файл cf это полностью вся конфигурация. Там не может чего-то не быть или быть что-то лишнее. Если файл обновления содержит только изменения в рамках обновления, то файл конфигурации тупо содержит всю конфигурацию и ничего больше.

Вопрос можно разделить на два, так как чаще всего одно другому не мешает: "Как вы обновляете конфиги с большим количество правок" и "Как вы обновляете конфиги на несколько релизов"
Для первого 1с придумали столько инструментов для более легкого обновления, те же модификации конфигурации, расширения, для запущенных случаев создание собственного обновления
А второе встречается повсеместно, и, в подавляющем количестве случаев успешно
То есть если попытка натянуть типовой итоговый cf прошла без проблем, то этот же cf с доработками тоже натянется без проблем(если ваши доработки не особо затрагивают типовой функционал)

В общем, геморно и с большим трудозатратами, к примеру, я в УТ делал чек на основании заказа как при создании реализации, а в УТ частенько бывали заморочки с видами запасов и резервированием, в таких случаях простое обновление конфы превращалось из двух-трех часов с минимальным постредактированием в 4+ только проверки с разбором измененного функционала + финальная проверка + накатывание на продакшен

Но опыта у меня еще мало, может кто-нибудь обновляется менее геморно

+что значит "несколько релизов"? Для меня это 3-6, примерно смотрю в релизах что нового и что изменено

Можно потерять данные.
Например, в релизе 001 "Адрес" хранился в реквизите справочника.
В релизе 002, решили хранить адрес в регистре сведений. Добавили этот регистр в метаданные, и при обновлении с релиза 001 на 002 заполняют это регистр.
В релизе 003 удалили реквизит "Адрес" из справочника.
При обновлении с релиза 001 сразу на 003, потеряешь данные адреса.

Последнее время такие объекты стараются не удалять, а переименовывают как "УдалитьАдрес". Но всякое может случиться (

(5)Ты отвечаешь на вопрос который я не задаал. У меня конфигурация в которой много правок со стороны стороннего разрабочика и обновление в котором много правок со стороны разработчика 1С. Перенос правок занимает несколько часов. Про анализ ВСЕХ изменений разработчика 1С я уже молчу. Только те которые затрагивают изменный функционал. Делать это с каждым релизом при наличии хотя бы 5релизов очень дорого в денежном выражении и увеличивает шанс допустить ошибку, например пропустить что-то. И как написано в (0) невозможно на рабочей базе в принципе. То есть в итоге как не крути имеет итоговый cf с правками и последним релизом. Теперь возвращаемся к (0) и читаем еще раз вопрос.

(4) Набор обновлений - это набор процедур и функций которая 1С выполняет при переходе на новую версию. Т.е. как раз те действия которые исключают (6).
Поэтому cf как может содержать эти процедуры, так нет.
БП содержит этот набор начиная с первого релиза. Т.е. если первые релизы обновить cf от последнего релиза, то 1С-ка отработает все процедуры и функции которые были между этими релизами (т.е. к примеру у нас БП релиза 3.0.40, допустим в релизе 3.0.50 1с перенесла хранение основного договора контрагента из реквизита контрагента в РС. И если мы 3.0.40 обновим до последнего релиза 3.0.60, т.е. перескочим сразу несколько релизов, то 1С корректно выполнит процедуру обновления из 3.0.50 и перенесет основной договор в РС)

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

Сталкивался в прошлом (
После этого стараюсь обновляться последовательно.

(7) У меня есть типовая 1С на замке, которую я обновляю стандартными средствами и из которой я получаю последний CF.

Дальше я натягиваю эту CF на свою пустую базу с изменениями, используя правила обновления, которое экономит кучу времени по снятию галочек с тех реквизитов и модулей, которые не надо обновлять и получаю CF с последним релизом и с моими изменениями. (мои изменения эти те которые нельзя перенести в расширение, т.е. новые реквизиты и периодичность документов)

Дальше полученный CF загружаю в рабочую базу. На старых платформах (8.2 и ранее) были проблемы с предопределенными и с изменением реквизитов. На 8.3 такой проблемы нет, т.е. при загрузки реквизиты синхронятся не по ГУИД,а  по имени. Т.е. если удалить реквизит и добавить такой же с таким же имени, то загрузка это поймет адекватно и не будет удалять реквизит

(5) Хмм, самое главное не написал, после перехода на расширения мне легче обновляться пошагово - ума особо не надо
(7) Прочитал, в конце написано "Как делаете вы?", на частично ответил выше, но ранее делал так "В общем, геморно и с большим трудозатратами"

+ Возьмите типовую конфу и накатите на нее типовую конфу перелетев 5-8 релизов. Если встало, то и ваш итоговый cf должен встать. Это я указал в (5) "То есть если попытка натянуть типовой итоговый cf прошла без проблем, то этот же cf с доработками тоже натянется без проблем"

Обычно проблема при загрузке конфы в обработчиках обновлении, то есть бывают случаи потери инфы, как указано в (6), чтобы такое предупредить я примерно смотрю в релизах что нового и что изменено, далее считалочкой решаю вопрос "накатится или нет", обычно не промахиваюсь

(9) Я с таким сталкивался один раз при переходе с БП 1.5 на БП 1.6. Там просто в РС они ресурс в реквизит перенесли, и в результате 1С ругалась на неуникальное имя.
Лечилось обновлением через промежуточный релиз (последний 1.5)

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

(11) +1

(11)Ты накатываешь cf и рекомендуешь по максимуму включать расширения. Я понял спасибо. Но если функционал который затрагивают расширения сильно меняется фирмой 1с, то расширения никак не меняют картину.

(14) Ну, по мне, чаще, функционал не будет сильно меняться с типовым, к примеру, тот же чек не будет считать себестоимость,
Я предлагаю сравнить типовые общие модули между необновленной и обновленной конфигурации, они редко меняются и вынести их в расширения с аннотацией &Вместо, а формы вынести в расширения и поменять их уже там ИЛИ в основной конфигурации создать их программно функцией и вызывать эту функцию обработчиках событий формы при создании или открытии (это даже лучше), часть кода перенести на общие модули МодификацияКонфигурации (правда там вообще не развернешься)

Сейчас у меня почти все типовые модули типовые, добавлены только реквизиты, я больше не накатываю cf, а обновляюсь пошагово

(15) + обновляюсь пошагово потому что я фиксик, иначе я бы забил на это дело :)

(15)>> Ну, по мне, чаще, функционал не будет сильно меняться с типовым, к примеру, тот же чек не будет считать себестоимость.
У меня есть другие примеры. Когда абсолютно все равно расширение у тебя или форма переписана в конфигурации. Каждый раз приходится все разбираться вручную.

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