Возможные проблемы при обновлении конфигурации 1С

[prent]

Всем доброго времени суток! Досталась задача - обновить нетиповую конфигурацию на приличное количество релизов. Собственно, как истинный программист, я сразу же бросился придумывать, как это лучше сделать... пришла идея выгрузить дифф между основной конфигурацией и конфигурацией поставщика (т.е. по сути сторонние доработки нетиповой конфы), обновить все релизы, а в самом конце просто накатить этот дифф на самый последний релиз. Собственно, вопрос - реально ли это сделать? Потому что механизмы у 1С, прямо сказать, не прозрачные. Решить конфликты в самом конце, все скопом и ровно один раз - я бы сделал именно так, но возможно ли?

Даже если ну никак - ладно, я смирюсь с такой кривотой и буду последовательно ставить все обновления, решая на каждом этапе конфликты. НО, меня интересует следующая ситуация (сразу оговорюсь, я не знаю 1С от слова "вообще", поэтому опишу ситуацию на псевдоязыке):
В основной конфигурации сторонними разработчиками написан класс B, который является потомком класса А (он есть в старой конфигурации поставщика). Класс А имеет публичные (никакой инкапсуляции, только хардкод) поля "name" и "surname". Где-то в коде этот класс (В) используется, например, выводится "surname". Ставлю обновление - в классе А поле surname удалено. При этом весь остальной код в новой конфигурации поставщика, естественно, использует обновленный класс А, чтобы корректно работать (ведь релиз официальный). Конфликтов в этом случае не будет: класс А успешно перекочует с полями из новой конфигурации поставщика, наш класс В, написанный в отдельном файле, будет тоже успешно перенесен. Проблема только в одном: как только мы начнем использовать вывод "surname" из объекта класса В где-то в своем коде, все упадет))
Иными словами - с какой вероятностью может возникнуть ситуация, что введенные производителем изменения нужно будет адаптировать под написанный собственноручно (не мной) код? Потому что решить конфликты - это одно, а вот чтобы все работало потом - это другое:улыб:

[cska-fanat-kz]

как обычно делаю...
на входе имеем 3 конфигурации:
1) сама измененная конфига + она же в виде цф (далее цф0)
2) цф типового релиза той же версии, что и измененная конфига (далее цф1)
3) цф типового релиза новой версии (цф2)

через "Сравнить/объединить" сравниваем измененную конфигу и цф2
параллельно дважды через "Сравнить конфигурации" выбираем
    а) цф0 и цф1 - получаем изменения с текущим типовым релизом
    б) цф1 и цф2 - получаем изменения между типовыми релизами

получаю на экране 3 окна сравнений, далее последовательно анализируешь: какие объекты поменены в измененной базе, поменены ли они в типовом сравнении и т.д...

[Luzer1C]

Рекомендации самой 1С не советуют сразу перескакивать через несколько релизов.
Я решил обновлять нашу БД с помощью файлов cfu. Т.е. последовательно от релиза к релизу.
Если так обновлять, то при этом обновляется конфигурация поставщика. Что очень важно. Причем когда появляется окно Сравнить/Объединить, то флажки ставятся только у тех объектов, которые пришли вместе с обновлением. Если поставить фильтр на "Дважды изменённые", то система покажет только те объекты, у которых есть собственные доработки.

[prent]

2) цф типового релиза той же версии, что и измененная конфига (далее цф1)
3) цф типового релиза новой версии (цф2)

Это хорошо, при условии, что есть где взять эти конфиги. Сама 1С предлагает обновления в виде CFU. Где взять типовые конфиги нужного релиза - не знаю, может, подскажете?

Если поставить фильтр на "Дважды изменённые", то система покажет только те объекты, у которых есть собственные доработки.

Я понимаю это... Вы мой вопрос про вероятность все испортить читали? Может, я криво как-то выразился на псевдоязыке.
Попробую еще раз: есть какой-нибудь Файл1, типовой, в изначальном релизе, скажем, в 1.0. Мы используем функцию из этого Файла1 используем где-нибудь у себя в коде, доработав конфигурацию под себя - например, добавили Файл2, который использует функцию из Файла1. Вышел релиз 1.1, в котором эта функция удалена. Я ставлю обновление, никаких конфликтов у меня нет (ведь я не менял Файл1): появляется измененный Файл1 из новой поставки и переносится Файл2 из моей старой конфигурации, который мне нужен. При этом я не знаю, что за изменения были сделаны производителем в Файле1, ведь их огромное множество, все изменения во всех файлах отследить нереально, поэтому и в Файле2 я ничего не трогал, перенес его таким же, каким он был. Но в нем используется несуществующая в новом Файле1 функция - следовательно, все плохо Я просто не знаю саму структуру 1С, могут ли возникнуть такие проблемы в принципе? 1С это как-то автоматически проверяет (например, весь этот бардак не скомпилировался бы на императивных языках). Или там все модули строго разделены и между ними не может быть зависимостей?
Иными словами - я хочу гарантий, что если я перенесу свои изменения (очень внимательно и корректно) поверх обновленной конфигурации, то мне не нужно будет что-либо дорабатывать и у меня ничего не поломается из-за каких-то там изменений поставщика. Переживаю так потому, что программировать на 1С не умею совершенно и даже желания вникать нет... я могу лишь сделать сравнение и перенести поверх обновленной конфы нетиповые изменения - это все, на что я способен))

[Luzer1C]

Где взять типовые конфиги нужного релиза - не знаю, может, подскажете?

В интернете все есть.

[prent]

Да ладно, для меня нет разницы, с чем работать - самими конфигурациями или обновлениями для них. Все изменения я смогу отследить, статей куча, и вы только лишь подтвердили, что можно обойтись и без них. Сама 1С же может выполнить сравнение двух конфигураций: первая: основная, вторая - типовая от поставщика, все, больше ничего не надо. Ну и обновление в виде CFU.

Меня больше интересует, что я ничего не сломаю (читать мои длинные посты выше)

[ls600]

появляется измененный Файл1 из новой поставки и переносится Файл2 из моей старой конфигурации, который мне нужен

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

[prent]

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

Это не моя функция! Она была в типовом релизе 1.0, но потом ее удалили в типовом релизе 1.1. Я этот файл даже не трогал, я просто воспользовался этой функцией где-то в своих файлах - например, в Файле2, который есть только в моей конфигурации (если это вообще возможно).

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

Какой каждый элемент? Дважды измененный? Я Вам и говорю, что в ситуации, которую я описываю, не будет конфликта, там нет "двух изменений".
Или вы прям каждый-каждый элемент просматриваете, который добавлялся/удалялся в обновлении? Да в жизни не поверю, там их десятки, сотни...
Походу мы просто о разных вещах говорим.

[cska-fanat-kz]

Это хорошо, при условии, что есть где взять эти конфиги. Сама 1С предлагает обновления в виде CFU. Где взять типовые конфиги нужного релиза - не знаю, может, подскажете?

работая во франче - об этом как-то не задумываешься

а так по идее конфигурация поставщика - это ваш цф1 - типовой текущий релиз
его восстанавливаем в параллельную пустую базу, обновляемся с помощью цфушника - получаем цф2.