Обновления ставлю так: качаю обновление на свой компьютер, обновляю демо базу, сохраняю cf, им обновляю копию рабочей конфигурации, переношу свои изменения, тоже сохраняю cf. Оба cf переношу на рабочий сервер. Сперва рабочую базу обновляю 1-м cf - обновляю конфигурацию поставщика, затем 2-м cf - свои изменения. Если сразу 2-м cf, то получаю сообщение: Файл не содержит доступных обновлений. Хотелось бы в один прием обновлять рабочие базы.
Файл конфигурации содержит только одну конфигурацию: поставщика или основную?

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

(1) Работаю удаленно. На рабочем сервере делаю только необходимое.

(2) НЕт отдельного разработческого сервера с копиями баз? Ну блин, пичалька, тогда только страдать

(1) Очень плохо подключать рабочую базу к хранилищу. Лучше сделать механизм файлов поставок

(4) Чем плохо? Обоснуй.

(3) Лучше ответе на вопрос темы: Файл конфигурации содержит только одну конфигурацию? Если Да, то тема закрыта.

(5) Это сигнал того, что нет налаженного DevOps, нет code review и всё такое...

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

(6) Файл конфигурации содержит конфигурацию поставщика, но при объединении она не используется (игнорируется).

При правильном подходе достаточно загружать готовую конфигурацию в рабочую базу. Но тут зависит от способа "переношу свои изменения".

(9) Бывает даже типовые удаляют данные в документах по колонкам таким образом.

(9) Почему не находит, почему пишет сообщение: Файл не содержит доступных обновлений? В чем правильность в "переношу свои изменения"?

(11) >>почему пишет сообщение

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

>> В чем правильность
Если ты копипастишь метаданные, или даже переносишь их в копию объединением, то загружать такую конфигурацию нельзя.
Правильно: свежую копию обновить(через поддержку), полученный cf можно загрузить в рабочую.

(12) > Правильно: свежую копию обновить(через поддержку), полученный cf можно загрузить в рабочую.
Вроде так и делаю: свежую копию базы обновляю через Поддержка/Обновить конфигурацию... cfu или cf. Обновляется конфигурация поставщика, затирается часть моих изменений. Их восстанавливаю, и сохраняю в файл: Сохранить конфигурацию в файл... Переношу этот файл на сервер, пытаюсь им обновить рабочую базу через Поддержка/Обновить конфигурацию... И получаю сообщение: Файл не содержит доступных обновлений. Что ни так?

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

(13) полученный cf просто загружай в рабочую (не "обновить" и не "сравнить")

(13) >> Обновляется конфигурация поставщика, затирается часть моих изменений.

Ты что, не способен при обновлении оставить свои изменения?

Рукалицо...


Обновляешь копию, изменения не затираешь, проверяешь, сохраняешь cf, заливаешь в рабочую.
Делов то.

(14) Для маленьких изменений 2.4.11.71 - 106 так и делаю, обновляю cfu. А последнее обновление 2.4.13.64 тяжело шло.
(15) Через Загрузить конфигурацию из файла - как-то рискованно...

(14) 2.4.12.64

(17) >>как-то рискованно…

Если ты не понимаешь, что ты делаешь, то конечно рискованно.
Если понимаешь, объясни в чем риск.

А почему просто не обновлять рабочую базу стандартным обновлением, убирая из обновления свои доделки, части кода? Потом как что если из доделок не работает - просто смотришь и корректируешь.

(20) Так данные же убить можно.

(17) Если "как-то рискованно"(с) - то да, лучше не надо. Особенно если "как-то" так, но "не в курсе" как - это не для тебя :))
PS: только так и обновляю рабочую базу-через загрузку. Никогда не было проблем. Просто нужно быть аккуратным и внимательным при обновлении.

(20) Что значит "стандартным обновлением", cfu что ли? Иногда делаю (17).

(20) >> Потом как что если из доделок не работает

Это не серьёзный подход.

(8) Если в рабочей базе ещё есть распределёнка, то потом начинается...

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

(13) тебе надо открыть для себя пункт меню :"Конфигурация -> Поставка конфигурации".

+ к (26) перед манипуляциями есть состояние типовая старая + твои допилки. объявляешь это поставкой, присваиваешь номер версии.
собираешь файл поставки (это тоже CF, но не как у тебя). заливаешь в рабочую базу, ведь ничего не поменялось кроме служебных сущностей?
потом начинаешь свои очередные пляски с обновлениями, как умеешь.
и вместо "сохраняю в файл: Сохранить конфигурацию в файл" - пишешь следующий номер версии. собираешь файло поставки с обновлениями.
в рабочей делаешь одно телодвижение - обновить из файла. это будет настолько просто на конечной точке, что это можно автоматизировать или доверить самому бухгалтеру.

(22) Не в этом смысле "рискованно". Иногда бывает, что кто-то внес свои изменения в конфигурацию после того, как я снял копию для обновления, не поставив меня в известность. Методом "Загрузить конфигурацию из файла" я затру их.

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

(28) ну и риск этот закрывается сравнением с эталоном перед загрузкой конфигурации.

(27) Предлагаешь в качестве конфигурации поставщика иметь конфигурацию поставщика с моими дописками?
(30) Как это? Поподробнее...

(31) Ты являешься поставщиком для своих клиентов

(21) Как они убьются? По умолчанию все добавленные реквизиты и объекты при обновлении не предлагаются к удалению.

(30) Эталоном является конфигурация поставщика. Сейчас это сравнение-обновление мой 1-этап обновления.
(32) Слишком громко сказано - всего лишь технарь-исполнитель.

(31) перед загрузкой конфигурации сравниваешь с конфигурацией "как было" на момент снятия копии.
Вообще если идёт групповая разработка, наверное, и инструменты должны соответствующие применяться.

(35) Нет, групповая разработка не ведется. Но мало ли...

(36) А что в (28)?

(37) фиксики набежали и натоптали, не иначе.

(34) Тогда сделай поставщиком ИТ-службу предприятия, и всё станет на свои места. Ты войдёшь в неё как внешний субподрядчик.

(37) Ну не кто-то, а сам внес, да забыл...
Никто определенно не ответил на вопрос темы (6).

ответили же. См. (9) (12) (26)

(41) Да, в (9) не четко, почему игнорируется. Оказывается достаточно Включить возможность изменения, и сохранённые конфигурации "Файл не содержит доступных обновлений".

(42) Что не четко?
При сравнении игнорируется потому что так устроена платформа.
При загрузке замещаются обе конфигурации по той же причине.

Причем здесь "Включить возможность изменения" вообще непонятно.
Почему "Файл не содержит доступных обновлений" - потому что обновления это специально подготовленные поставки.

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

(44) Теперь понятно о чем ты. Да, пока включил изменения, сохраняемая конфигурация и есть "поставка". После включения изменения её (конфигурацию поставщика) можно получить через меню настройки поддержки.
Но это всё про первый пункт, который ты на демобазе делаешь. К переносу изменений(обновлений) между копией и рабочей это отношения не имеет.

Вывод такой, если нет уверенности в правильности заготовленного обновления (если есть, то Загрузить конфигурацию из файла), то действовать по старому: 2-мя cf для конфигураций поставщика и основной. Будет в процессе обновления еще раз проанализировать, если что ни так, отменить.

+ в процессе обновления возможность...

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

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

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

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

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

Если у каждого разработчика своя база,то нужна ещё одна база для тестирования,куда будут грузиться все результаты для проверки взаимного влияния и всестороннего тестирования.

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

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

(50) Тогда просто снимут с поддержки и всё.

(53) Перед обновлением нужно сделать архив. И стараюсь как можно меньше действий осуществлять на рабочем сервере.