Хотим подключить рабочую к хранилищу. Сомневаемся..
Прочитал данную тему:
v8: У вас рабочая база подключена к хранилищу конфигурации?

Есть там фразочки попугать, но без подтверждающих фактов, а-ля:
"Пробовали подключать рабочую к хранилищу. Отказались из-за рисков."
"Кто подключает к рабочим хранилище - самоубийцы со стажем. Имхо."
"Могу предположить что те кто отвечают ДА ! Они анверно и демоническим обновлением пользуются ???"

Но темка 12го года, 6 лет утекло. Вероятно ж что-то изменилось.

Подскажите, какие есть риски подключения рабочей к хранилищу?
3 разработчика.

никаких

(0) сделай голосовалку, получишь статистику

(0) Риск есть только в возможной кривости рук.

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

Подключайте.

(0) В свое время изучив ряд материалов и рекомендаций я напрямую подключать рабочую базу к общему хранилищу не решился.
Программистов 5-10 в разные периоды.
У меня организовано так:
- Есть хранилище разработки, к нему все программисты подключены.
- Из него каждый день конфа забирается в тестовую среду (несколько тестовых базы).
- Есть хранилище продуктива, к нему тоже все подключены. Как протестировано, программист в это хранилище из разработки переносит. Но это еще не подключение к рабочей базе, хотя так сделано только из-за того что это разные сетки.
- А сама рабочая база подключена к своему хранилищу, только под Администратором, чисто для ведения истории изменений. В нее из хранилища продуктива уже неглядя накатываются обновления.

С определенной регулярностью хранилище разработки сыпется и его приходится пересоздавать. 2-3 раза в год где-то.
Продуктив и рабочая стоят твердо.

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

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

(5) Хранилище надо разворачивать на платформе не ниже 8.3 и лучше сервером хранилища, а не файловой шарой. Тогда и работать все будет быстрее и рушиться оно не будет.

(8) Когда эта схема запускалась у нас конфа была на 8.2.

(7) На 8.2 мы регулярно именно это наблюдали, на 8.3 перешли полгода назад, посмотрим как будет. Пока вроде не падало.

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

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

Спасибо всем.

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

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

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

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

самая классическая ошибка с правами - это ошибка прав,

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

в результате этот левый документ у полноправного юзера будет работать а у обычного - будет выдавать ошибку...

Этот вопрос кстати неплохо разобран в книге Методическое пособие по эксплуатации крупных информационных систем на платформе «1С:Предприятие 8»

(16) Дадада +1

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