Хранилище 1С и автообновление. Платформа 8.2.19.130 #760308

Доброго дня! Однажды мы обленились до такой степени, что по вечерам стали забывать выгребать изменения из хранилища и применять их в рабочей базе. С этой целью нарисовали батник который делает это автоматически. Но вот беда, если в "храник" добавляется новый объект (например подписка или роль), при автоматическом получении данных из хранилища вылетает ошибка. Такая же ошибка вылетает и при ручном обновлении из хранилища НО! ошибка не критичная и ругнувшись один раз обновление продолжается и успешно заканчивается. Кто-нибудь сталкивался с таким чудом? Как лечили? Может быть есть какой-то особый порядок получения и помещения новых объектов в хранилище, в справке об этом не уточняется...

Просыпайтесь =)

От лени есть хорошее лекарство

Рабочая подключенная к хранилищу? Удачи... А по сабжу - ошибку в студию...

Ну уже 3 год работаем так, все отлично, в штате 5 программистов. Ошибка: ---- Начало операции с хранилищем конфигурации —— Для выполнения операции требуется получение объектов:   ПодпискаНаСобытие.ПередачаТоваровСозданиеОстатка   РегистрСведений.ТрансферныеЦены.Форма.ФормаСписка —— Операция с хранилищем конфигурации отменена —— Ошибка обновления конфигурации из хранилища Ну для примера. Если ничего не добавляли, то все прекрасно автоматически выгребает и накатывает.

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

+100500 однажды утром вы лишитесь продуктива

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

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

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

...рабочая не должна быть подключена к хранилищу... Почему? +1.

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

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

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

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

"ТрансферныеЦены".. бгг знакомая конфа ) ларечные решения. У них база не позволяет так играться. Слишком большая какой смысл в двух Хранилищах? Чтобы руками переносить из одного в другое? Мегамысль

одно хранилище на всех - это, как ты выразился, ларечное решение

Еще раз. Как ты будешь переносить дневные изменения 5 кодеров из девелоперского в боевое хранилище. Озвучь метод плз

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

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

руками естественно. Девелоперов выводить в отдельное от обновления храилище нужно хотя бы за тем, чтобы была возможность выпускать хотфиксы в любой момент, когда надо. Без этого риск выпустить вместе с хотфиксом не протестированные изменения почти 100%. Когда разработчиков 2-3 и они в рабочее время успевают кино посмотреть, это, конечно же, избыточная мера.

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

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

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

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

у всех 5-х голова включена. прокладки не требуются. Тем более это и невозможно - см выше.

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

ни текста ошибки, ни текста батника. "У меня ошибка, памагите!"

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

чем реальное производство отличается от реальной торговли, или реальной "МММ" ??? а знаю, на реальном производстве стоят 286 под управлением DOS и на них стоит 1с 6.0 :))) зы я про производство знаю побольше многих, ибо работал станочником, наладчиком, оператором 7 лет, а потом в КБ автоматизировал техпроцессы ЧПУ (и хорошо автоматизировал)...

В Хранилище не может быть хренобень. В Хранилище оттестированные и проверенные блоки. Если кто-то (какая-то) выложил хренобень, то его лечат +1 даже не спросили почему это боевая всегда подключена к Хранилищу. Да потому что подключение к Хранилищу длится часа два. А "проведение квартальчика для легкого теста" несколько суток.

странно, у меня подключение к хранилищу длится 5 минут для торговли и 10 для бухгалтерии, может Вы работаете на ноуте за 100баксов? а если проведение квартала идет более суток, то тогда его ТОЧНО нужно делать перед обновлением, ибо риски возрастают, или переходить на более прогрессивные формы автоматического тестирования, но ни в коем случае не доверять прогам этот процесс...

и по скорости проведения, 50 000 доков проводится примерно за 1...2 час (по крайне мере у меня такая скорость) двое суток это 48*50000 = 2,4ляма доков в квартал, что примерно 10...25 тыщ доков в день, интересно посмотреть на перца который в компании с таким документооборотом накатывает на продакт без тестирования да еще батником ночью :)) чем больше база - тем строже должны быть требования к тестированию, да и вообще к изменениям...

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

Должно быть 2 хранилища как минимум. Одно боевое и одно (или несколько) для разработки. Так рекомендует сама 1с, да и вообще это бест практис из мира взрослого программирования

Это при активной разработке. Если в компании 2-3 программиста, которые не пишут ничего глобального (только ВПФ, загрузки, подписки, роли, права и т.д.) - то ничего страшного нет.

у вас там в Челябинске своя атмосфера. В остальной России некоторые вещи выглядят много иначе

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

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

надо еще и своей головой думать, а не тащить "зэ бэст практис туда", где они по факту не нужны.

ну-да, ну-да

у меня тоже была проблема с долгим подключением к хранилищу. Это из-за большого количества записей в хранилище. Мне помогла функция хранилища "сократить до версии". Теперь подключается за 2 минуты.

значит поможет и переход на 8.3 с конвертацией хранилища

Переподцепил харнилище, проблема осталась. В ручно режиме в сообщениях пишет так: ---- Начало операции с хранилищем конфигурации ---- Для выполнения операции требуется получение объектов:     РегистрСведений.ИсторияИзмененияРеквизитовОбъектов ---- Операция с хранилищем конфигурации отменена ---- ---- Начало операции с хранилищем конфигурации ---- Объект получен из хранилища: УправлениеПроизводственнымПредприятием РегистрСведений.ИсторияИзмененияРеквизитовОбъектов ---- Операция с хранилищем конфигурации завершена ---- Соответственно при автозапуске валится на первом шаге и закрывается.

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