Вход | Регистрация
 

Опасности подключения рабочей к хранилищу.

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

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

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

Подскажите, какие есть риски подключения рабочей к хранилищу?
3 разработчика.
 
 
   arsik
 
1 - 16.01.19 - 12:59
никаких
   shuhard_серый
 
2 - 16.01.19 - 13:00
(0) сделай голосовалку, получишь статистику
   scanduta
 
3 - 16.01.19 - 13:09
(0) Риск есть только в возможной кривости рук.
   ЛЮС
 
4 - 16.01.19 - 13:10
Полгода назад аналогичная тема мелькала. С теми же аргументами.
Мы всегда подключали и не парились.
Насколько я понял противников подключения - риски носят организационный характер из-за сближения среды разработки, тестирования и промышленной. С единым хранилищем легко можно накатить тестовый релиз на продакшн, но тут уж сами организуйте у себя процессы разработки и тестирования.

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

С определенной регулярностью хранилище разработки сыпется и его приходится пересоздавать. 2-3 раза в год где-то.
Продуктив и рабочая стоят твердо.
   Фрэнки
 
6 - 16.01.19 - 13:56
(5) т.е. описываемая схема действий есть следствие не технических свойств хранилища, а перестраховка от проблем разработчиков. Однако, лишние перевалки уже протестированных изменений могут обломать ожидаемый эффект если разработка оказалась слишком сильно размазанной по всей конфигурации
   Фрэнки
 
7 - 16.01.19 - 13:57
Единственное оправдание таких действий - неустойчивость работы самого хранилища, если в нем топчется достаточно много людей.
   Пузан
 
8 - 16.01.19 - 14:01
(5) Хранилище надо разворачивать на платформе не ниже 8.3 и лучше сервером хранилища, а не файловой шарой. Тогда и работать все будет быстрее и рушиться оно не будет.
   Diman000
 
9 - 16.01.19 - 14:17
(8) Когда эта схема запускалась у нас конфа была на 8.2.

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

(6) Есть такое, перестраховка, согласен.
Кое-какие проблемы "перевалки уже протестированных изменений" встречаются.
Но они целиком на совести разработчика, про это в регламенте написано, что перенос разработка -> продуктив надо выполнять зряче.
Комментарии надо побольше писать и метки в хранилище ставить. С номером выполняемой задачи, тогда таких проблем почти нет.
   Alres
 
10 - 16.01.19 - 14:30
3 рабочих базы подключены к своим хранилищам под служебной учеткой для обновлений, 3-й год - полет нормальный, подключение к хранилищу позволяет быстро забирать оттуда доработки
 
 Рекламное место пустует
   Bibr
 
11 - 16.01.19 - 23:30
Спасибо всем.
   palsergeich
 
12 - 16.01.19 - 23:37
(0) Зависит от стоимости факапа.
В классической модели разработке на ответственных участках к хранилищу рабочей базы подключена только рабочая база и обновления туда накатываются через обновление поставки конфигураций поставщика \ одной из конфигураций поставщика.
Перед этим контуры разработчиков, контуры тестирования и контур сбора\доставки обновления.
   palsergeich
 
13 - 16.01.19 - 23:40
А ситуация когда разработчик случайно, вполне возможно даже не осознавая этого в храннилище поместит баг, красную ошибку, типо реквизит объекта не обнаружен, а то и неверно работающий функционал (а это самое страшное, ничего не отваливается, а через какое то время становится ясно что данные пишутся не так, например в проводки не пишется измерение etc), сильно больше нуля.
   vde69
 
14 - 16.01.19 - 23:40
(5) нормальная схема
(0) подключение к общему хранилищу разрабов и продакшен не хорошо, может пару лет работать а можете на третий день потерять какие ни будь полезные фишки
   palsergeich
 
15 - 16.01.19 - 23:44
(13) Почти 3 года проработав с достаточно сильной командой с рабочей, подключенной к хранилищу, могу сказать что факапы были, редко, но были.
   vde69
 
16 - 16.01.19 - 23:45
самая классическая ошибка с правами - это ошибка прав,

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

в результате этот левый документ у полноправного юзера будет работать а у обычного - будет выдавать ошибку...
   palsergeich
 
17 - 16.01.19 - 23:48
Этот вопрос кстати неплохо разобран в книге Методическое пособие по эксплуатации крупных информационных систем на платформе «1С:Предприятие 8»
   palsergeich
 
18 - 16.01.19 - 23:50
(16) Дадада +1
   Сергиус
 
19 - 17.01.19 - 02:21
(0)Хранилище в 1с частенько глючит(по-крайней мере так было раньше, и вряд ли сильно исправилось в последних релизах). Если хотите рискнуть рабочей базой, то конечно подключайтесь. Я бы не стал.

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует