Имеется допиленная УТ 11.4
Хочу автоматически обновить через все необходимые релизы, но чтобы это произошло в автоматическом режиме.
Т.е. загружается обновление, галочки при сравнении объектов оставляются по умолчанию, обновляется, запускается предприятие с обработкой данных и так до последнего релиза.
Существует что-то подобное?

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

(0) Обновлятор 1с?

(2) посмотрим
спасибо!

А я хочу не ходить на работу, а деньги чтобы приходили на карту...

(4) это называется коронавирус

(0) для нетиповых это все херня, не ведись

ОФФ:Вспомнился сценка Райкина, когда его персонаж приносил пользу отсутствием на работе. )

В чем проблема то?
Подготовил cf и обновляй обновлятором или скриптом

(0) Так конфа ж переписанная. Там ведь всё вкривь-вкось пойдёт.

(0) а зачем промежуточные обновления? Найдите полный дистрибутив последней версии, возьмите оттуда .cf и один раз обновите.

(10) Нельзя. Там ведь в промежутках куча обработок запускается, которые данные переворачивают туда-сюда. Например, 1С-ники решили вместо одного регистра сделать два. Создают 2 новых регистра и при обновлении обработки переносят в них данные, а старый помечается как удаляемый. В следующем обновлении помеченный регистр удаляется.
В общем не желательно перескакивать через релизы

(0) Подготовить обновления можно в рабочее время, на специально для этого сделанной копии. А сами КФ обычно накладываются достаточно быстро. Только проблема может быть, если в обновлениях будет реструктуризация какого-то документа и программа в режиме Предприятия начнет их все обрабатывать. А так - обновлять по вечерам-ночам - обычное явление, например, для торговли. Если лень сидеть в офисе - согласуй возможность подключения из дома.

(12)+ А автоматически нетиповую конфу обновлять - скорее сломаешь. Разве что там из доработок только те, которые никак не влияют на типовой функционал (отдельные документы и отдельные модули для доработок). Ну а если хочешь ускорить обновление - пробуй перевести все доработки в расширения.

(11) В типовых можно перескакивать через релизы. Они и пишутся в предположении такой возможности. Не могу припомнить обновления, в котором бы _удалялись_ метаданные (а не переименовывались). Вот отраслевки и нетленки - особый случай..

(14) тут высказывалось предложение взять чисто КФ от последней и обновить до нее

(14) несколько раз натыкался на эти грабли при обновлениях старых версий. крайний случай - обновление ДО 1.2 до 2.1 релизы примерно за 3 года.
почти месяц заняла подготовка обновлений, тестирование что можно пропустить что нельзя, перенос отдельных обработок обновления в собственные, доработка этих обработок, там не все чисто проходило. в итоге весь список сократился до 7 промежуточных релизов, которые уже нельзя было пропустить или объединить в один. ну и само обновление на рабочей базе 2 выходных.

(16) Нуу, если речь про смену мажорного релиза - тут да, надо быть внимательным. Потому что там часто радикально меняется структура данных, и как правило в релиз нотесах прописано, с какой версии можно прыгать.

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

+18 хотя можно попробовать прыгнуть с 11.4.9.98 сразу на последний релиз

(18) это пока дело до дела не дошло

рекомендую делать все на копии и просить ее полностью протестировать по завершении процесса.
то есть с выполнением ВСЕХ хозяйственных операций и отчетов.

(10) // полный дистрибутив последней версии, возьмите оттуда .cf и один раз обновите.

Ты же понимаешь, что это не универсальный рецепт? И чтоб его советовать, нужно знать точно через какие промежуточные релизы будет скачок из начала в конец.

(14) "Не могу припомнить обновления, в котором бы _удалялись_ метаданные" - а как насчет обновления, в котором бы _добавлялись_ метаданные? Довольно часто так бывает, что в этом же обновлении новые метаданные заполняются данными обработками обновлений и в последующих обновлениях более не изменяются. Имхо, перепрыгивая через обновления, можно не только потерять данные от их исчезновения, но и по причине их не заполнения :)

(14) // В типовых можно перескакивать через релизы.

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

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

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

Впрочем, все это очень очевидно.

PS: теоретически можно реализовать желаемое автором на нетиповой конфигурации. Если заранее последовательно обновить копию рабочей базы "как обычно" (т.е. не в автоматическом режиме), с выгрузкой промежуточных версий конфигурации в файлы CF...

(23) Процедуры заполнения выполняются каскадно, со всеми промежуточными релизами. Если без багов - то всё будет нормально. В типовых.

(14) >> Не могу припомнить обновления, в котором бы _удалялись_ метаданные
Помеченные на удаление разве не удаляются? Прям вот копятся и копятся и копятся????? Просто я то при обновлении удалаю всё то, что удаляется, не разглядывая, что это было, поэтому и удивлён. Что-то же удаляется иногда. Прям видел какие-то галочки

(28) Количество объектов метаданных с префиксом Удалить в типовых оцените!
При обновлении метаданные удаляются, но только те, которые не хранят первичные данные и аналоги которых полностью заполняются процедурами обновления.

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

(1)  "проблема в том, что организация работает без выходных и сидеть всю ночь тыркать обновления очень не хочется.
Делать промежуточные обновления тоже очень не охота."


да ладно, все будут только рады, и пойдут пить чай, если 1сник займет базу.

(31) 99% - да, а 1 сотрудник вечно бегающий с платежками будет крайне недоволен :) Т.к. ей надо набить документы в 1С и потом всех обойти подписи собрать.

(29) Нифига. Прямо сейчас сравнил ЗУП 1.61 с 13.146. Там столько всего удалено, что просто жесть, жуть и даже шок. Вот прям везде и даже в начислениях!
Короче, пусть я буду занудой, но всё равно буду накатывать обновления только по списку разрешений, дожидаясь отработки всех механизмов. И да, эти знания пришли после первых же люлей, когда пользователи сильно злились.

(32) Семеро одного не ждут!

(33) иногда (но не всегда) можно объединять несколько релизов, склеивая обработки первого запуска в одну. но опять же - не всегда это работает, и требует анализа того что выполняется после обновления.
в случае автора - либо делить обновление на части и обновляться промежуточными релизами по рекомендуемым 1с версиям, либо провести доп работу и попытаться склеить готовую конфу которую можно будет натянуть на рабочую базу сразу и обработку, которая выполнит все что должны были проделать все промежуточные обработки перехода.

(35) >> иногда (но не всегда) можно объединять несколько релизов, склеивая обработки первого запуска в одну
И сколько готовить такой бутер? Не проще ли просто накатывать обновления по разрешённому списку? Оно быстрее, минимум ошибок и косяков.
Вот честно не понимаю зачем такие сложности

(36) быстрее? иногда это спорно.
Но мало того - это не всегда гарантирует успех, если это все, как сказано в топике, для "нетиповой конфы" - мы здесь степень этой самой нетиповости будем телепатировать или как?!

(37) А вдруг там грамотные доработки, которые в отдельных подсистемах и внешних модулях? Надежда - наше всё!

(36) я же писал выше. случай был примерно как у автора - когда не хочется работать по ночам а в дневное время всех выгнать надолго нельзя.
в этом случае "оффлайновая" подготовка обновления с пропуском нескольких релизов и процедур обновления - оправдана.
хотя понятно что суммарно затраченное время выше чем просто по очереди накатить необходимую последовательность релизов с запусками между обновлениями.

(39) Я готовил отдельно все ЦФ-ки, перенося в них глупые и даже тупые изменения. Потом каждую ЦФ-ку накатывал на тестовую, проверял, что ничего не отвалилось. Выкладывал в хранилище и потом уже рабочую обновлял как человек-метеор

(37) (38) самое главное - оставить инфу в измененных\добавленных реквизитах, а модули в последнем обновлении накатить

(0) недавно делали так:

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


(11) +100
(14) не всегда получается, даже если есть возможность... сталкивалась, когда релиз позволял на него перескочить, а потом при открытии предприятия - засада... поэтому копии наше всё...
параллельно при обновлении я пробовала  несколько вариантов, чтобы потом на рабочей сократить время обновления... корректно отработал только вариант - пройти через все релизы...

(41) >> самое главное - оставить инфу в измененных\добавленных реквизитах, а модули в последнем обновлении накатить
Проходили уже. Горекодер понавтыкал в стандартные объекты свои куски кода, которые срабатывают при записи, обновлялка понаперезаписывала всё то, что ей надо, а на утро злые пользователи идут в бой, потому что их данных и нет.
А ещё часто бывает так, что после обновления не работает куча функционала, потому что горекодер скрестил свою логику со стандартной, а злые 1С-ники поменяли последнюю. Как это было с ЗУПой в позатом году, когда поменялся алгоритм расчёта резерва по отпускам и все франчиевые дописки (за дофига денег) пришли в негодность. В итоге я вынес всю эту кашу в подсистему организации и вся стандартная логика по резервам стала замороженной. Глупо? Очень глупо! Но заказчик не готов был платить франям каждый раз по столько денег за одну и ту же работу

(43) вроде заказчик всегда платил. Это называется абонентское обслуживание. каждый месяц платит абонентскую плату, 10 или там 20 тысяч, франи каждый месяц приезжают и делают одну и ту же работу. Почему сейчас заказчик не готов платить?

(44) Увы, в моём случае ежемесячно просили сотни тысяч. Один раз сделали супер-мега-разработку, заказчик и рад. Когда всё перестало работать, показал им, что каку просили, каку и получайте. Франчи, потирая руки и пуская слюни, готовились к очередной крутой работёнке, но мы приняли решение, которое описал выше и все остались довольны на пару лет. Даже и не знаю, может и сейчас используют этот костыль