Розница 2,2 с нашими доработками. Не РИБ. Как реализовать обновление всех баз при доработках функционала и обновлении типовой части от 1С, может кто встречал статьи или описания в инете. Пока копаю в сторону стандартной системы обновления, просто в качеств обновлений будем ему подсовывать наш файл *.cfu. Понимание всей этой системй идет с трудом, как поддерживать, что снимется с поддержки, что поствить какие, как правильно настройки поставки сделать.

(0) cfu - норм тема, там не все так сложно.
Работал в федеральной розницы - 4к точек цфу обновлялись и было ок.
Только перед обновлением - снимайте бекап.

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

(1) если на своей поставке, то можно через обновлятор

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

(2) тоже вариант. А автоматизировать процесс - можно посмотреть как сделано в АПК

Для автоматизации достаточно типового механизма. Он вроде из БСП

(4)
1) Правильно ли я понимаю, что та база с которой я собственно буду выпускать обновления, должна быть снята с поддержки полностью, и я как бы выпускаю свою конфу и нумерацию версий уже веду свою? То есть конфа на местах не будет и не может никак быть связана с розницей 2.2 от 1С

2) Каждый раз когда выходит обновление от 1С я просто заливаю его в эту свою конфу но уже через сравнить/объединить и выпускаю новую версию обновления. А когда команда делает доработки то они подтягиваются из хранилища и тоже попадают в очередной новый релиз. После чего мы выкладываем рализ на HTTP и отдаем команду на обновление типовым способом с нашего источника.

(7) 1) Да
2) Да

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

(9) Что бы не дай бог рабочие базы не получили то, что еще не готово, но уже есть в хранилище

(8) ХМ а я думал что 1С Розницу можнокакто сохранить на поддержке, ну типа чтоыб самим лишний раз не запариваться с обновлением.

3) Чем отличаются комплект поставки от файлов поставки. Комплекты это когда установочные файлы с пустой базой, демо базы а файлы  поставки это cf И cfu и в принципе последнего достаточно.

(11) Можно, например перенести все изменения в расширение.
А вот расширение обновлять из хранилища.

(11) Я уже не помню что есть что, но суть ты понял верно

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

(11) можно конечно.
у тебя по сути 2 конфы будет: для разработки и продакшн.
для разарботки будет на поддержке розницы, продакшн на твоей

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

(14) обновлятор ставится на конечную точку и обновляет свою базу, cfu берет из шары\фтп\придумайсам.

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

(15) (16) Правильно ли я понял, что файл поставки обновлений на каждую такую конфу свой должен быть и выпускать я могу только свою часть обновлений, а обновлений от 1С:Розницы должен брать из их файлов обновлений? Или можно один общий формировать.

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

(18) еще раз. устанавливаешь обновлятор с автостартом НА КОНЕЧНЫХ ТОЧКАХ.

(19) нет, не правильно.
там связь не прямо 1 ко многим, а 1 к 1, но с каждым шагом добавляется еще одна конфига.
например, БСП - Розница - МояРозница.

(19) про хранилище... скорее всего как ты подумал не получится. смотри как делает сама 1с : https://its.1c.ru/db/v8std#content:709:hdoc
вкратце - база для сборки релизов живет отдельно от хранилища.

(0) Поставить на всех точках яндекс.диск, куда выкладывать cf. Ночью - батник с загрузкой конфы.

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

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

(25) "обновления уйдут ли они туда, или они в принципе не будут выгружаться" - кто уйдет, куда уйдет. нипонятна.

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

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