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

Это продуктивные базы или локальные бзы для разработчиков, в которых они кодят код?

И несколько рабочих и несколько для разработчиков
Причем базы разработчиков лежат в сети вместе с одной из рабочих, а несколько других рабочих с другими данными но той-же конфой лежат отдельно

(2) во-первых надо вытряхнуть кашу из головы и успокоиться

для коллективной разработки существует сервер хранилища конфигурации, про него всё написано в мануале и вот еще статея из вики
http://wiki.mista.ru/doku.php?id=1c:v8:admin:server_xranilischa_konfiguracii&s[]=хранилищ

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

мы поставками не пользуемся. просто накатываем из хранилки (не подцепляя продакшен напрямую к хранилищу конечно)

РДП?

(5) Это вы напрасно

(7) И мы также делаем. А что тут такого неправильного?

(7) (4) Что плохого в таком варианте?
Какие плюсы от поставок?

мы тоже накатываем из хранилки. Что тут страшного, когда всего одно предприятие.

(10) У (4) тоже "всего одно предприятие". :)
Но я бы ему поверил на вашем месте

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

(7) и мы также, а в чем проблема?

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

тем более, что поставки позволяют на места отправлять cfu-шник, который даже сторож в состоянии применить БЕЗОПАСНО к продуктивной базе. А с хранилищем каждый новый пользователь первым делом и всегда почему-то отстёгивает базу от хранилища.

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

"произойдет гарантированно с потерей данных" = "произойдет гарантированно и при нехорошем стечении даже с потерей данных"

Если это типовая конфига, то обновляться cfu не проканывает. Особенно после типового обновления.
Мы обновляемся поставками, но готовим cf для этого.

(18) "то обновляться cfu не проканывает", хотел сказать _не_всегда_ проканывает

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

(15) (16) Спс. Это в принципе понятно, и частично решается административно. Частично риски принимаются.
(17) А вот за это особое спасибо. Принял к сведению.
(19) Порядок можете описать?
(20) 6 лет. Проблем хватает, но ответственность за них несет поставщик типовой. Взял бы все к себе, но ресурсов на полноценное тестирование не дают. А нести ответственность, за то на что не можешь повлиять, как-то не хочется.

(21) я не про ответственность. У продуктива должен быть один папа, чтобы как раз вот этого вот гемора не было "то обновляться cfu не проканывает". Комплект для продакшна должен делаться из хранилища, в котором один поставщик и все у него на замочках, а изменения запрещены к биоматери. Иначе одна сплошная морока.

(20) (21) У нас "буха корп", в хранилище она типовая с возможностью изменения. А продуктив на поддержке от нашего хранилища. Когда выходит очередное обновление 1С, мы его накатываем на хранилище.
Каждую ночь из хранилища через механизм поставки выгружается cf, которым через механизм обновления обновляется продуктив.
Обновление продуктива делается скриптом в три этапа:
1. Специальная база подключенная к хранилищу обновляется из хранилища.
2. Выгрузка cf через механизм поддержки.
3. Обновление продуктива.

+(23) пробовали готовить cfu, но там гемор с тем, что надо указывать cf который будет обновляться. Этот cf предварительно выгружался из продуктива. Это работает до тех пор пока хранилище не обновишь очередным обновлением от 1С. После этого продуктив перестает понимать твои cfu, хз почему не вникал, но догадываюсь. Чтоб исправить надо проуктив обновить разок cf файлом. Потом опять cfu понимать начинает.
Я на все это плюнул, и решил что проще каждый раз из cf обновляться.

(23) спс за инфу.

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

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

Уважаемому Лефмихалычу впору написать монументальный труд в стиле клипа "Dumb ways to die" :) Было бы всем полезно

(27) это ты о чем?

(28) Про вещи, типа (14), (15), (16) - которые не пишут в учебниках, и которые грозят больнючими шишками - они очень похожи на этот ролик.

(29) Думаю, такая книга сама по себе будет еще одним тупым способом умереть от скуки и при прочтении, и при написании

(26) у нас одно хранилище. Мы так и не пришли к тому, что хранилище для разработки и хранилище для выпуска релизов должны быть разными.