Руководство ИТ группы компаний поручило группе 1С нашей компании работать с программой 1С:УТ по схеме с 2мя хранилищами. Т.е. разработчики работают в одном, а разработчик-админ хранилища выгружает cf из него во второе из которого обновляет рабочую базу (у нас всего 3 человека разработчиков, но вопрос не про это).
Рабочую базу быстро не обновить. Актуальный cf быстро не получить. Насколько такая схема вообще рабочая?

Я так и не увидел хоть какой-то аргументации нафейхуа второе хранилище...

(1) лучше контролировать изменения версий хранилища, для чего хранилища нужны?) одно хорошо, два лучше)

(1) Нормальная практика.

Первое хранилище - для разработки - там все задачи и готовые к установке на рабочую и только начавшиеся. Эти задачи могут затрагивать один и тот же объект.

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

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

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

(3) А нафига, простите, не протестированный функционал в хранилище выкладывать?

(3) сколько разработчиков работают на проекте?
(5) +1, имхо такая схема (0) работает когда большие бюджеты и к тупым разработчикам не очень критичное отношение в компании

(5) Незачем.
А как внести срочные изменения, например, в документ, который захвачен разработчиком и уже модифицирован, но еще не доработан до конца и не протестирован?

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

(6) У нас было три + консультант.

(8) Ну тогда уж надо на каждую тестовую сборку хранилище делать, чё.

(7) Сохранить наработки, отменить захват. Заново захватить, Подправить документ, поместить в хранилище, обратно захватить, вернуть свои изменения с учетом правок. Вроде, ничего сложного....

фирма 1С так работает

(9) косячные разработчики значит, не тестируют что сами делают.

работал с 3-мя хранилищами: разработка, тестовое и предрелизное

(11) Что тут сказать. Будешь на похожем проекте, поймешь.