Есть конфигурацию, которую активно допиливали и не обновляли (украинская УТП). Есть ли какие-то рабочие методики/рекомендации как быстро обновить конфигурацию до последнего релиза.

Читал про ключевые релизы - не катит. В этой конфигурации каждый релиз накатывается на предыдущий т.е. срезать несколько релизов не получится.

Есть какие-то идеи, кроме как последовательно обновлять каждый релиз?

ну раз срезать не получится - сидите и обновляйте по 1

(1) Капитан очевидность?

нет ты можешь попробовать на свой страх и риск

20 это много...

больше 10 не накатывал

Можно взять последний релиз и допилить его

(4) По одному или какие-то фишки есть?

(0) Можно начать с выбивания бюджета под новое внедрение

(5) Тоже про это думал. На последний натянуть все дописки. По сложности получится как заново внедрить.

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

хотя может половина допилов уже не нужна, а вторая половина реализована в новых версиях типовой

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

ахаха, опытного 1Сника видно сразу: "Вам это не нужно"

на инфостарте была методика "прыжков"

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

(12) мы как то обновлялись(УТ 10.3) на релизов 10. потом месяц всплывали косяки. Пару недель была подготовка к прыжку и все выходные, чтобы это оказалось в боевой.

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

20 релизов? Мелочи жизни :) "Глаза боятся - руки делают"(цы) За неделю спокойно, без фанатизма, запросто. Обновление конфигурации с изменениями - это же рутинная операция для профи. Всего то двадцать раз повторенная :))

> Всего то двадцать раз повторенная

одного обновления хватит

(14) Ну да, косяки будут валить - это неизбежно.

(16) Вы тему читали? По 1 релизу любой дурак обновит. Вопрос в другом.

(15) Хотят всё и сразу? Выгрузка/загрузка КД.

(офф)
(17) И мне одного хватит, но за других не ручаюсь.

по одному релизу есть шанс только больше косяков нахватать по дороге

PS: Всё становиться гораздо проще, если есть "полный" CF последнего релиза.

(13) Вы про то, что если код правится тупо на месте без подписок/переопределения штатных процедур то будет амба. Да, соглашусь.

>А сейчас допилили вроде до рабочего состояния, но нужен учет ЗП со всеми изм-ми законодательства и регл. отчетами из коробки.

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

пусть сидят в отдельной базе и не кукарекают

Один вопрос только сколько денег? А остальное накатывайте последовательно...

>если код правится тупо на месте без подписок/переопределения штатных процедур то будет амба

не будет...

есть выгрузка/загрузка модулей

>Всё становиться гораздо проще, если есть "полный" CF последнего релиза.

без него тут вообще делать нех

(0)есть два числа. А и Б. предложи алгоритм обменять значения чисел без привлечения третьей переменной С.
если если алгоритм есть - смело обновляйся сразу на последний релиз.

(22) И что мне это дает? Там регистры так изменены (расчетов например) что обновление в лоб до последнего релиза тупо ложит базу намертво.

(15) А разве в УТ есть учет ЗП?

>И что мне это дает?

дважды измененные, йопта

>Там регистры так изменены (расчетов например)

руками галки натыкаете, не рассыпитесь

(30) УТП

одни 20 релизов собрались один за одним нахлабучивать

другие последний, но в лоб

страна ты моя дуремария...

(32) точно, проглядела)

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

(33) +1
"Нормальные герои всегда идут в обход"(с)
"Еще пять тысяч ведер, и считайте, почтеннейший, что ключик у вас уже в кармане"(с)

как то давно тоже надо было бп 1.6 обновить до последнего релиза. просто перенес изменения в последнюю конфу и допилилвал.

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

(38) Спасибо, дельно.

(38) помню не решился на такой эксперимент с УПП. Тогда 4 релиза обновил. Слышал, что после меня, под ФЗ.275 обновляли УПП на 20 релизов один за другим и ничего.

(40)Слыша такие истории всегда хочется спросить,а кто проверял,что ничего

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

(41) когда там ФЗ.275 вышел? - думаю, уже больше года полёт нормальный. кто проверял? пользователи и программисты. я просто не знаю, чем всё кончилось.

(42)
А, допустим, переливка с одного РС на другой?

Допустим.

(44) Если эта регламентная постобработка обновления, то она выполнится, так как в (35) обновление через все релизы.

+(35) тут наверное еще надо после каждого релиза запускать в режиме предприятия. На случай если меняют структуру одного объекта от релиза к релизу.

(46) к (42)

(28) a=a+b
b=a-b
a=a-b
И при при чем здесь обновления?

Возьми и накати cf последнего релиза.
Задрали уже с этими последовательными обновлениями.

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

(0) Ну возьми конфигурацию поставщика и доведи ее до актуального релиза. Потом обновляй не с cfu, а сразу с cf. Только смотри - переименования/удаления реквизитов могут потом не дать заполнить нужные данные.

Вот что удивительно в подобных темах, когда вваливается на форум "внезапно" кто-то и задает подобные вопросы:

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

Т.е. сейчас топикстартер мозг сломает "как обновить", затем начнет ломать мозг "как обрезать или свернуть". А можем быть лучше не ломать мозг два раза, в просто развернуть новую базу и перенести в нее и доработки (если они очень нужны до сих пор) и данные об актуальных остатках, да и все?!

(4) Разве? Около сотни - много, например с УТ10.2 до последней УТ10.3. Тут дело не сколько в количестве обновлений, а в количестве внесенных изменений. Возможно их придется полностью переписать.

(46) не наверное, а само собой, по-моему об этом даже упоминать не особо нужно

(41) что смущает?

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

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

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

" Долгое время не пользовались, потому что внедрили криво. А сейчас допилили вроде до рабочего состояния" - это какое рабочее состояние если обновления вызывают проблемы? Доработки значит кривые. Если конфой не пользовались, то берете последнюю типовую и на нее изменения свои накладываете, но с учетом того, что завтра опять обновлять