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

если хранилище только одно, то, как минмум, в продуктив будут попадать новые, добавленные, но недоделанные объекты. Вы же корень долго не держите же - добавили, отпустили и потом допиливаете же, так ведь?

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

(2)+1
вообще на ИТС есть статья. там немного перекручено, чтобы эмулировать бранчи нормальных систем версионирования, но в принципе понятно и логично. если разработчик один-три - можно и одним хранилищем пользоваться, если жестко регламентировать непомещение в хранилище неработающих объектов. если же разработчиков больше - то они друг другу в одном хранилище будут мешать.

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

Естественно нужно следить , кто что кладет и подтягивать то , что согласовано.


Сейчас 15 разработчиков. Боевая подключена к хранилищу. Никаких проблем.

(3) поделись ссылкой на статью пожалуйста

В хранилище с рабочей тестовая релизов. Правки вносятся только в тестовую сравнением и объединением. В каждой группе разработчиков свои хранилища по желанию.

бывают глюки при обновлении из хранилища.
По крайней мере раньше были

(4) Одно хранилище?
т.е. х..к, х..к и в продакшн?

Как показал опыт - при активной разарботке нужна база конфа которй 1 в 1 идет на рабочую.
на которой можно потестить доработки

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

Не люблю упавшие с утра базы.

Рабочая база должна стоять на поддержке.

Должна быть ещё одна тестовая база для создания релиза обновления CF или CFU (можно без данных, чтобы была быстрая реструктуризация).

Я рекомендую всё-таки делать полные релизы (CF). Будет меньше проблем с УРБД.

сфу для локального обновления вообще не нужен

(8) Поясни зачем тебе несколько хранилищ?

(14) Ибо "нужна база конфа которй 1 в 1 идет на рабочую."

(8) Естественно все тестируется предварительно на тестовых базах, которые тоже к хранилищу подрублены.

(16) Где гарантия, что одновлени ена тестовую будет таким же как и на рабочую.
Ведь это же вручную с расстановкой нужных галочек

(15) чего?

машу вать

(19) у вас есть незаконченные доработки в хранилище?
Как вы не допускаете их в базу?

(21) В таких случаях Не подтягиваем при обновлении из хранилища. Все просто.

Список доработок которые готовы в гугл доксе ведется.

(21) в САПе, кстати, обычное дело

(22) Иногда они сами подтягиваются. Особенно новые объекты и всякие модули. Особенно при захвате/обновлении корня.

(21) они широко применяют метод игнорирования. Ну, прорвалось в продакшн, ну и кер с ним.

(0)Просто перед самим обновлением сравниваю конфигруация БД и новую конфигурацию

(22) Дисциплину нужно иметь хорошую и ничего само не подтянется. Это раз.


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

(22) Это как обновить из хранилища не подтягивкая некоторых доработок? А если это общий модуль?

(27) Можно надеятся на то что разрабы ничего не пропустят, а можно регламент выстроить так что ничего само не пройдет

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

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

(30) Вы теоретик.

Вообще один модуль не должны дорабатывать одновременно несколько человек.

Но если очень хочется то пожалуйста, отключаетесь от хранилища и дорабатывайте. Сохраняете конфу.

Потом когда объект освободиться - захватываете, и объединяете.

Удивлен , что так много народу простых вещей не знает если честно.

(32) мха-ха-ха

>>Отключайтесь от хранилища
Однако

(34) Базу разработки

Хотфиксы? Не, не слышал.

(36) Что хотфиксы то?

(37) ага, я так и сказал.

https://habrahabr.ru/company/1c/blog/280394/
в обители делают так

(5) http://its.1c.ru/db/v8std#content:2149184358:hdoc:_top:

(37) когда, косячок, проскочит все рубежи обороны, то он не знает, как экстренно это исправить.

(41) Просто пишете лучше (с)

(42) это, кстати, наиболее эффективное решение, но дорогое для работодателя

Делать или не делать хранилище для продуктива - дело хозяйское.
По сути ценность хранилища тут только в хранении некой истории изменений.
А вот разработка(и) должна(ы) делаться обязательно в хранилище(ах). Под каждую длительную разработку необходимо создавать отдельное хранилище. Мелкие исправления по текущим ошибкам или разработкам с коротким сроком можно делать в основной разработочной базе (основном хранилище разработки).
Собственно в (39) и (40) всё описано.

В чем проблема выкладывать в хранилище только протестированный функционал?
Везде с кем работал Продуктив подключен к хранилищу.

(0) >> Как показывает личный опыт подобная практика порочна, но задумавшись я не смог формализовать это очучение.

Вы уж определитесь. Есть опыт или его нет?
Откуда взялись ощущения? На чем они основаны?

>> опишите, почему не стоит подключать рабочую базу к хранилищу

То есть вывод сделан заранее, а нам предлагается его обосновать?...

(45) >> В чем проблема выкладывать в хранилище только протестированный функционал?

В разных сроках разработки и неизбежном их пересечении.
Например, одному разработчику нужен документ Поступление и он закончил разработку за два дня. Другому этот документ нужен на неделю.
Кто должен захватить этот документ, если хранилище одно?

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

(45) Все рабочие базы 1С делятся на два типа:
1. Ещё подключённые к хранилищу
2. Уже не подключённые к хранилищу.

У нас 2 хранилища - для разработки и для выката в РБ.
Когда настает пара обновлений в локальной базе, которая подключена к хранилищу РБ, захватывается все, выполняется сравнение/объединение, тестируется, что база вообще стартует после этого и кладется все в хранилище. Т.к. база файловая - обновление проходит субъективно быстрее, чем прям в РБ. Параллельно выполняется бекап РБ. Я вот не очень люблю сидеть в той базе, которая в данный момент бекапится.

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

Добавлять в хранилище только рабочие версии после тестирования или объекты не участвующие в обработке данных (новые справочники и т.д.).
В случае необходимости получать объекты точечно

(51) а, если двум разным программистам в одно и то же время надо добавить новые объекты в конфигурацию, что делать?

(52) Захватил корень добавил, положил корень. Повторить 2 раза.

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

(54) Если не ставить галочку "рекурсивно", то ничего не появится, пока сам не положишь в хранилище.

(55) а вот и нет. отсутствующие метаданные кладутся вместе с корнем.

(54)  Ну добавятся новые объекты, обычная практика. От них проблем нет никаких. Так как новые объекты добавляются в таком случае абсолютно "голыми" , как бы первоначальный образ. Связь с остальными объектами, права, обмены и прочее уже закидывается второй финальной итерацией. Насчет новых объектов и прав  - уже объяснял в (27).

И это практика, а не теория. Это уже все отлажено на системах работающих годами.

(57) что за системы? на сколько баз накатывется релиз?

(57) Ты просто решаешь дисциплиной, а во взрослом мире принято решать технически

Это как часовую игру проходить с 1 жизнью.
За раз или по уровням

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

(57) как раз практика показывает, что такие штуки, прорываясь в продуктив, могут стать причиной простоев и потерь. А теория говорит: "да, куйня, ни чего не случится".

(61) ты просто не помнишь.

(63) Возможно, настаивать не стану, т.к. давно это было.

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

(62) могут стать причиной простоев и потерь

(65) может внезапно появиться два объекта

Смешно.... сразу видно кто тут теоретик

(65) Ну мы как-то пару-тройку лет так проработали, и ничего критического не случалось. Разве что пару раз хранилище рушилось. Создавали новое - и дальше в путь. Никаких потерь и критических ошибок. А если руки кривы, то и без всякого хранилища можно весёлую жизнь устроить.

(65) А ещё бывают ошибки типа "Недостаточно прав для выполнения операции над базой данных."

А всё из-за поля типа "ЛюбаяСсылка" или "СправочникСсылка" (или субконто) и новых объектов, на которые нет доступа ни у одной из ролей, кроме Администратора. Отладка превращается в в бондиану "Поймай меня, если сможешь".

(68) А я думал Волшебник шарит

(68) В данном случае способ подключения к хранилищу непричем

(70) Если рабочая база подключена к хранилищу, то новые объекты прилетают в рабочую базу бесконтрольно. И не надо думать, что они не повлияют на работу, даже если ещё не включены ни в какие роли.

Мне кажется, scanduta слишком много выпендривается в этой ветке. Нет? Мне показалось?

(71) Требую пояснений... ))

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

(73) Вьюнош, доверься моему многолетнему опыту. Когда ты под стол пешком ходил, я уже виды расчёта в Зарплате для DOS ковырял, а когда ты 7.5 на 7.7 обновлял, я уже книжку по восьмёрке написал.

(74) Эти правила написаны кровью.

(75) При добавлении новых объектов( не окончательной сборки) они всегда у меня доступные только ПолнымПравам.

Делается для того чтобы не держать корень.

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

(76) Там ещё были разные нюансы, связанные с тем, с какого компа и под каким пользователем коннектиться из боевой к хранилищу. Но, в итоге (наступив пару раз на грабли), разработав для себя свод правил, вполне нормально работали, без критических ошибок, во всяком случае. Хотя, имхо, правильнее конечно, всё-таки не подключать боевую к хранилищу, т.к. слишком много правил приходится соблюдать :)

(72) нет, не показалось

(73) если ты добавляешь справочник и у тебя есть где-то таблица с полем "СправочникСсылка", то что будет у пользователей, которые формируют отчет, в котором есть это поле?
Хинт1: справочник есть, но ни в одной роли его нет.
Хинт2: не приведи господь - справочникСсылка в субконто или в характеристике какой-то...

(77) какие сборки? У тебя ж продуктив к хранилищу подключен (одному единственному), а значит процесс разработки - куяк-куяк и в продакшн. Окончательной сборки... тьхе...

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

(80) (81) Устал уже десять раз разжевывать .....

(83) так отдохни

(80) А ещё бывают циклы по метаданным, разные универсальные обработки, всякие СКД, которым нужны права "Просмотр", планы обменов...

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

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

Без разницы

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

(89) в поставку - может. А вот, если продуктив подключен к единственному храниищу, то новые объекты не могут в него попасть, а гарантированно будут попадать всегда и сразу

(89) Поставку можно и не делать. Например, мы по пятницам не делаем файл обновления, чтобы не портить себе выходные.

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

(92) Хранилище для разработчиков ласково называется ГНОИЛИЩЕ

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