Хранилище конфигурации к рабочей базе - это нормально? #809330

Пришел франч на наш проект (у них побочная задача наладить обмен с ихней поделкой). Подключил хранилище к рабочей базе. Это вообще как?

Это плохо.

Вот и у меня слов нет цензурных. База 500Г. Лень было копию делать

Причём тут хранилище и база 500Г?

нормально. А как еще изменения переносить? Сравнением что ли. Хранилище для этого и придумано. Вопрос только в количестве этих хранилищ. 1 или 2.

На боевой нельзя так делать. Сделали бы копию и к ней бы хоть скоько подключали.

нельзя подключать хранилище? 0_о это что за религиозные запреты. Лог изменений в рабочей вы как смотреть будете?

Проблема когда в боевую вносят неоттестированный код или правки на ходу. Хранилище в таком случае не виновато :)

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

Почему нельзя? Можно ссылку на запрет от 1с?

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

Нормально, если база самописка или не на поддержке. Отладил в тестовой- накатил на рабочую.

Может автор переносит изменения из копии вручную, как в 77?

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

Это не есть хорошо.

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

Это если регламентом предусмотрено тестирование. Но такое не везде. )

Абсолютно нормально

ну пусть тестируют вручную, как в . все равно поставка на рабочей. разница в скорости решения проблемы при настроенном тестовом контуре что с поставкой, что с "прямой правкой на проде" минут 10. в крайнем случае отказаться от поставки и делать прямую загрузку .cf, но тогда править код параллельно придется.

Мухи отдельно, котлеты отдельно

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

"То есть, с точки зрения методологии - это неправильно. " - Я уже просил ссылку на рекомендации от 1с. Спрошу ещё раз.

Из-за хранилища в боевой базе могут возникнуть проблемы, например, регистры без регистратора.

Это с какого перепуга?

В DEV-базе создали документ и регистр. В хранилище отпустили только регистр.

так не получится же, потребуется корень поместить и док тоже

Сам пробовал так сделать? Смотри - не выйдет.

Это теоретик

: , но в подавляющем большинстве случаев это избыточно

Получится. Сам сталкивался с таким не раз

Да ладно там документ и регистр. Куда чаще встречается пара "подписка на событие" и ее обработчик :)

Уж лучше гитом пользоваться, чем плодить эти хранилища)))

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

"Бест практикс" - панацея от кривых рук )

ага, типа у меня 1 раз бензин в машине закончился, машинами больше не пользуюсь, они не работают!

Бест практис - наличие тестировщика с своей базой, избавляет от кривых рук ))

Лучшая "защита от дурака" - не пускать дурака в систему.

В рабочую базу!

Ага, ошибка разработчика. Прихожу как-то утром после обновления на работу - и у меня кровь стынет в жилах: все документы "Заказ покупателя" пустые! Вот в шапке все заполнено, а ТЧ "Товары" пустая! Просто сбилась связка между табличной частью документа и табличной частью на форме. Такое повторялось не раз и не два, и на нескольких работах. И не у меня одного такая фигня.

что-то не могу представить как это?

У человека карма. Это не поддается рациональному объяснению )

Этот теоретик ловил данные кейсы не один раз и не два за последние 10 лет.

Спасибо за ссылку, но она совсем не о том.

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

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

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

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

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

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

Не везде 7 и более разработчиков.

Тогда и не нужно хранилище)))

На 2-5 рук вполне нормально с одним хранилищем )

В любом случае по теме ветки - назначение репозитория - организация групповой разработки (так в определении даже написано на сайте ИТС). Но никак не поддержка базы на продакшене.

поясню звонок по телефону "что за ... не печатает печатает печатная форма" (звонит врач на приеме) имя комьютера ... показыайте ... ок вижу поытка исключение - поместить в хранидище получить из хранилища и занимает это все примерно митуты 2-5 сколько это займет если рабочая у меня не будет подключена к хранилищу с разработкой?

неправ

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

Просто если не подключать рабочую, то надо наладить процесс выпуска поставки из, допустим, главной тестовой базы и доставку cfu-шки в рабочую инфобазу

ага время?

Вместо "надо наладить" предпочтительнее писать "можно наладить" )

Чего со временем?

В каждой избушке свои погремушки. Если обновление не связано с реструктуризацией, то логично ложить свои поделки в хранилище, связанное с рабочей базой. Время действительно экономится- накатил и все.

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

ложат - кирпичи в штаны. А в хранилище - помещают. На худой конец - коммитят.

Экономия на спичках. Зато потом потратишь 3 дня на восстановление какого-нибудь автообмена с каким-нибудь сраным филиалом.

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

В том-то и замес, что в результате реально может быть "накатил - и всё. Вообще всё".

Я запомнил первое предложение, буду применять в жизни как аргумент или просто как красное словцо :)

В оригинале "В каждой избушке свои игрушки".

В гугле соотношение игрушек к погремушкам 6350:90000

Господа? Вы пользуетесь поиском? Нет? А пора бы:

ситуации "пися не писает" вообще-то быть не должно

нормально, если разрабов больше чем никого..

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

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

Это хорошее решение. 1) Самое быстрое и дешевое. 2) Одновременно работают 2 команды программистов и нужно логировать всех. Если они поставят на свою копию то ваши действаия на боевой не будут логироваться. Это полумера. Плохое решение что на боевую вы их пустили. По хорошему ДО ФРАНЧЕЙ!!! Должна быть тестовая поднята, куда все программисты все пишут. Оттуда, после тестов, все через загрузку конфы накатывается на боевую. Но у вас этого не было. А франчи делать для вас инфраструктуру не подписывались. Если была инфраструктура то сделали бы на ней. Более того на ней уже было бы хранилище а не на боевой. Так что франчи ваши косяки инфраструктурные обходят, и делают это максимально эффективно.

Как оказалось такая карма не только у меня.

постоянно такая хрень. Причем только под одним пользователем

теоретически можно, но иногда хранилище глючит. вроде все получил, а получилось не все

1Сник и тесты - понятия несовместимые

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

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

+1