Добрый день!
Начали пробовать использовать в своей работе хранилища, однако столкнулись с рядом неудобств, часть из них, на наш взгляд, критичная.
Общая схема — отдельно сервер 1С, отдельно БД, отдельно файловое хранилище конфигураций. Само хранилище 1С расположено на файловом. Сеть вся 10Gbit/s. 4 программиста, к хранилищу подключено 7 баз (боевая, 2 тестовые, 4 программистов). Каждый работает под своими паролями.
Были готовы к тому, что само использование хранилища будет нести дополнительные временные нагрузки, но они оказались очень существенными.
Помещение конфигурации в хранилище после обновления конфигурации поставщика занимает около 3-х часов, причем происходит блокировка всех объектов, и другие программисты просто не могут работать. Либо им приходится отключаться от хранилища на это время, но обратное подключение также длится порядка 1,5 часа.
Можно ли как-то оптимизировать данную процедуру (в одной из статей читали, что как вариант боевую базу отключить от хранилища и обновлять через поставки), но при этом все равно будет заблокирована работа всех программистов и других операторов контура разработки.
Как в случае необходимости принимать динамические правки (исправление ошибок) в боевой базе в тех объектах, над которыми также продолжается работа (захвачены программистами в тестовых базах). Знаем, что это плохо, но жизнь иногда заставляет.
Как вести разработку длительных блоков, спринты которых могут занимать недели. Держать их захваченными или постоянно освобождать/захватывать? Второй вариант несет дополнительную нагрузку на разработку.

конфа какая?

(0) две типовые ошибки:
- использование файлового хранилища
- подключение тестовых баз к хранилищу

(0)
Рабочую базу отключить от хранилища, перевести на файлы поставки.

Длительные блоки вести в конфигурациях, отключённых от хранилища.

Динамические обновления запретить (или максимум 1 в день)

Отказаться от ERP, написать свою маленькую конфу с нуля.

(0) Развернуть сервер хранилища

(1) ERP УХ
(2) не могу найти информацию по хранилищам на основе БД, или какие еще варианты имелись в виду?

тестовые базы используются для контроля работы программистов, или только боевая + разработчики должны быть в нем?

Установка сервера хранилища конфигураций 1С
https://sysadminchik.ru/str/liversi_result.php?search_id=111
https://wiseadvice-it.ru/o-kompanii/blog/articles/hranilishhe-konfiguracii-v-1s-8-3-ustanovka-i-nastroika/

(5) https://its.1c.ru/db/v8324doc
Пункты 2.6.1.5 и 2.6.1.6

так же https://its.1c.ru/db/v8324doc#bookmark:dev:TI000001124@5fc8a29d
Пункт 33.4.4

(4) нашел информацию, вечером сделаю.
но он все равно будет работать с дисковым хранилищем, просто через веб (или я что-то не так прочитал)?
получается, что хранилище лучше всего будет развернуть на том же самом сервере, где и сервер 1С находится?

(8) Хранилище лучше всего разворачивать ближе к базам которые будут подключаться. Какие это базы будут - решать вам.

(8) Лучше на другом.

(9) что тут понимается под базами? могу развернуть на сервере БД (MS SQL), могу развернуть на сервере 1С предприятие, могу развернуть на отдельном файловом хранилище.
все сервера висят на одном свитче, Cisco, медь, 10G

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

(12) а как тогда проверять разработку? или получается что само хранилище будет только для слияния и обновления? а как быть, если какой-то модуль одновременно решается 2-3 программистами (например, один программирует объекты, а другой использует их в бизнес-процессе.


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

(13) Пригласите девопс-инженера.

(5) только боевая + разработчики

(13) проверять на выделенной копии с данными на которую накатили изменения.
да хранилище только для слияния и объединения.
"если модуль меняется 2-3 программистами", то вы в любом случае не смогли бы это сделать, если бы они захватывали объекты в момент начала разработки. А так кто первый стал того и тапки. Остальные будут адаптировать свой код самостоятельно в момент помещения.

(11)

ЕРП 2.5 (актуальная версия на начало весны)

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

(3) +100

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

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

(2) >> ошибки: ... — подключение тестовых баз к хранилищу.

Я бы не был так категоричен.
Подключение тестовых баз к хранилищу, считаю, допустимо.
Только при соблюдении двух условий:
1. Они подключаются к хранилищу разработки, а не к хранилищу продуктива. Хранилище продуктива (если оно вообще существует) должно быть отдельно и никак не связано с хранилищем разработки.
2. Тестовые базы должны быть подключены в режиме «только для чтения» — для получения изменений из основного хранилища разработки. Никакой разработки, захватов объектов и изменений объектов в тестовых базах быть не должно. Потому что они, сука, ТЕСТОВЫЕ.

(0) >> Помещение конфигурации в хранилище после обновления конфигурации поставщика занимает около 3-х часов, причем происходит блокировка всех объектов, и другие программисты просто не могут работать.

Поэтому:
1. обновление конфигурации поставщика надо планировать заранее, с учётом всех текущих задач, находящихся в разработке. На период подготовки обновления все разработчики должны будут либо поместить сделанные изменения в хранилище, либо отпустить захваченные объекты. А значит, кому-то придётся похерить свои разработки. Отсюда возникает необходимость ведения длительных доработок отдельно от основного хранилища (можно в каких-то отдельных хранилищах, если разработка задачи ведётся не одним программистом). Либо дробление длительных разработок на короткие этапы. Что требует грамотного планирования на этапе написания ТЗ (как сделать так, чтобы отдельные части разработанного функционала можно было последовательно по мере готовности переносить в продуктив, не ломая основную конфу, в условиях, что задача ещё в процессе разработки и, разумеется, не оттестирована как единое целое).
2. Автоматизировать скриптами такие рутинные процессы, как:
— создание новой базы разработки;
— подключение новой базы разработки к хранилищу;
— обновление разработочных и тестовых баз из хранилища;
— разворачивание копий рабочей базы и их подключение к хранилищу;
— какие-то прочие длительные операции.
Заранее планировать эти операции на нерабочее время. Запускать вечером, уходя домой. При необходимости из дома проверять и перезапускать, если что-то пошло не так.

(0) >> Как в случае необходимости принимать динамические правки.

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

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

Бури в стакане воды.

(19) Умножьте потерянные часы на ставку программиста и кол-во программистов. Это охренительные убытки и демотивация

(19) не поддерживаешь ты терабайтные ERP с УРБД.
у нас график тех.релизов и релизов 1С на год вперёд согласован =)

(20)

(13) Если ставятся задачи на один и тот же модуль, то нужен Git и EDT. Либо муторные костыли с переносом доработок между хранилищами через поставки. Впрочем, что проще, пока не оценивал.
Знакомые в одном интеграторе рассказывали, что у них на проекте с ERP УХ юзается локальный GitLab и, соответственно, GitLab-flow модель, адаптированная к 1С. Как это в деталях, пока не расспрашивал, мне бы вебинары осилить из серии "Парк аттракционов". )

(18)[В особо сложных случаях можно сделать для этих целей отдельную базу ПредПрод]
о да, Препрод наше всё, на нём отсекается 95% багов функциональным и интеграционным тестированием

(23) Да круто делать умышленно конфликты, чтобы потом специально обученный товарищ эти конфликты ручками разрешал. Интересные занятия.
(2) Вы используете файловые хранилища - это ужасно!
- Так в 1С других нет.
- Не используйте 1С и никаких проблем)))

(25) >> чтобы потом специально обученный товарищ эти конфликты ручками разрешал.

Практика показывает, что при количестве разработчиков более одного, нужен кто-то, кто будет выполнять такого рода работу.
Собирать продуктив, переносить доработки в продуктив, разруливать конфликты и т.д. и т.п.

Можно выгружать в xml и использовать Git.

(26) >> Практика показывает, что при количестве разработчиков более одного, нужен кто-то, кто будет выполнять такого рода работу.
Работа ради работы? Но это же не выгодно. Сколько работаю в командах, никогда таких дармоедов не держали.

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

(28) >> никогда таких дармоедов не держали.

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

(30) перевод в прод одним человеком который не полностью в контексте - это потенциальный источник ошибок

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