Коллеги, привет!

Работаем с переписанной УТ 10 через хранилище конфигурации (платформа 8.3.10.2580)
Заметил такую неприятную вещь. В рабочей базе захватил общий модуль рег заданий, изменил код, обновил динамически, поместил модуль в хранилище. Все обновилось - работает.
Через пару недель, в тестовой базе подключенной к этому же хранилище захватили этот же модуль рег заданий, сделали изменения - поместили в хранилище и мои изменения 2х недельной давности пропали.
Методом тестов понял, что при захвате модуля не всегда его последняя версия берется из хранилища. Иногда почему то конфа считает - что тек версия в конфигурации = версии в хранилище (что не так)
и просто выполняет захват без обновления. А потом кладет не самую последнюю версию получается с последними изменениями в хранище.

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

Куда покопать можно, коллеги?

(0) демонически

(0) Пункт 0 при глюках с конфигурацией: снести кэш

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

бывает такая шляпа. По этому обязательно получать конфу целиком перед захватом - полезная привычка.

(0)

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

(2) (3) Ну я думаю многие ним балуются, если система позволяет. Из за каждой мелочи выгонять всех в базы не реально.
(4) Есть предположения, что при получении всей конфигурации с описным мной глюком он и не подтянет всю конфигурации, а напишет типа нет изменений.
(5) Буду думать по 1., но очень проблематично всех выгонять... Хотя когда работал в другой фирме и там при динамическом обновлении "упала" база размером 1тб и еле-еле восстановили ее - был строгий запрет на динамическое рукоблудие, по регламенту в обед на пол часа выгоняли всех и обновляли в обычном режиме.

(0)  
delete from [consolidation_eco].[dbo].[Config] where FileName = 'commit'
delete from [consolidation_eco].[dbo].[Config] where FileName = 'dbStruFinal'
--delete from [consolidation_eco].[dbo].[Config] where FileName = 'DynamicallyUpdated' --(для версии 8.3)
--delete from [consolidation_eco].[dbo].[Config] where FileName = 'dynamicCommit' --(для версии 8.3)
ничего из этого не делали с базой?

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

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

отличный план так-то. А в чем тогда вопрос?

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

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

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

(11) о, таким я не баловался ни когда, звучит красиво) Но на практике думаю так делают пару фирм из сотни...

(13)
Мы так делали, было очень удобно, просто кайф.

(11) какая разница рабочая - не рабочая. У нас с одной конфой одновременно работает 6-7 программистов, каждый решает свою локальную задачу. Хранилище предназначено для групповой разработки. И захватывать конфу целиком (4) сводит на нет сам принцип групповой разработки

(15)
Там написано не захватывать, а получать все обновления: Конфигарция - Хранилище - Обновить конфигурацию из хранилища

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

вот в таком случае не будет происходить вот эта вся дичь, что в сабже у тебя.
Вы ведёте разработку так, как ее нельзя вести, по этому и результат получаете нежелательный

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

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

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

(20) не, тут были интересные косяки в 8.3.10, именно при динамическом обновлении

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

https://partners.v8.1c.ru/forum/topic/1665522#m_1665522

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

https://bugboard.v8.1c.ru/error/000035297.html

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

Вcемирный конгресс врачей. На трибуне американский врач:
- Мы научились лечить СПИД!
Аплодисменты, крики...
На трибуне японский врач:
- Мы научились предотвращать инфаркты!
Крики, аплодисменты
На трибуне русский врач:
- А мы научились удалять гланды!
В зале недоумении, шум. Русский продолжает:
- Через жопу. Автогеном...

(26) что со срочными патчами ? Тоже через поставку на след день?
1С прямо не говорит, что до не работает и его не рекомендуется использовать.

(28) зачем поставку делать? подцепил в конфигураторе обновление из хранилища и сохранись. Затем из конфигуратора базы выйди ибо нефиг в нем сидеть.

Рабочая база НЕ захватывает ничего из Хранилища, а только получает. Ведь это же первое требование безопасного разрабатывания толпой.

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

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

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

(31) потому что в результате у тебя два путя - оно или заработает, или нет. И, если нет, то у тебя опять два путя - ты или сразу об этом узнаешь, или хрена лысого ты узнаешь сразу и тогда у тебя уже две проблемы или даже больше.

(28) в смысле "срочные патчи"? вы не тестируете ничего, что ли?

(33) Случая всякие бывают. С возрастом, конечно, все реже и реже, но бывает по-разному.

p/s Если что, глюки (0) пропали после остановки сервера 1с, чистки кэша на сервере и чистке кэша хранилища.
Но про динамическое обновление буду иметь ввиду, спасибо все кто поучавствовал в обсуждении!

(35) Какое количество активных пользователей в базе?

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