Вопрос теоретический: можно ли базы, запускающиеся на разных платформах, использовать с одним хранилищем конфигураций (доступ по локальной сети, не серверное)?
Точнее: у нас есть несколько тестовых на 8.3.15.1869 и боевая на 8.3.15.1830, подключены к одному хранилищу конфигураций (файловому). В боевых ничего не разрабатывается, разрабатывается все на тестовых и затем идет получение объектов в боевой.
Напрягает, что версия платформы, на которой боевая, ниже, чем на тестовых. А поскольку мы аутсорс, убеждать клиента где-то менять платформу - это непросто.
Не приведет ли это к каким-то глюкам впоследствии, кто-нибудь сталкивался?

А что, тестовую такую же, как у клиента, поставить - Кришна не позволяет?

(1) вся работа на серверах клиента.

(2) Иииии?

(3) Предлагаете вести разработку локально у себя? Может, еще dt себе стащить, не? Или без тестовых данных работать? Вместо нескольких тестовых завести себе локально пустую базу - да ну нафиг.

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

(4) Я не понимаю, почему у клиента две разные версии платформ. Пусть сделает одну.

Собственно, тем и вызван мой вопрос: а надо ли вообще все это начинать. Теоретически - надо. Фактически - хз.

(5) видимо, ему потребовалось для каких-то других баз, я хз.

странно что-то... как может "хранилище конфигурации" быть локально у Разработчика и одновременно быть у Заказчика. И что это за рабочий комп, который где-то у разработчика, но вне локальной сети заказчика?

Не сталкивался, но мне кажется что проблемы маловероятны.

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

(8) не локально. На серверах клиента все базы, пишу же. У клиента на сервере папка сетевая с хранилищем.
Просто тестовые стоят на одном сервере с одной платформой, боевые - на другом.

(8) кто-то из нас кого-то не понимает, удаленно мы на серверах заказчика работаем.

(9) спасибо за ответ

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

(14) работает все, уже в боевых можно получать изменения, сделанные на старшей версии, так уже пару недель работали. Отличия версий не сразу заметила. Фактически ошибок никаких не было.

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

(14) Лучше узнай у клиента зачем ему две версии платформы одной редакции. Юзайте все последнюю редакцию и не будет проблем

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

(15) не, ты не поняла. У вас 8.3.15.x. Ты не сможешь получить из хранилища ничего, как только кто-нибудь закоммитит под 8.3.16, .17, .18 и т.д. При этом, ты с .15 сможешь помещать, но не получать. В рамках одной редакции .15, конечно ты будешь и получать, и коммитить.

Хождение в файловую базу разными версиями платформы - к развалу базы

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

(17) аааа. Не, ну 16, 17, 18 и т.д. там вряд ли вообще без предупреждения влепят (хотя я теперь уже ни в чем не уверена).

Всем спасибо, аргумент из (18) навел на мысли, что эту фигню точно надо исправлять. Буду мучить клиента

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

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

(21) не совсем понятно, зачем мучить клиента.

Серверная база подключена к хранилищу конфигурации только для того, чтобы _замещением_ получить объекты из Хранилища в _текущую_ конфигурацию

Можно просто загрузить в текущую конфигурацию из cf файла и все. Радикального требования о подключении боевой базы к хранилищу нет.

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

(23) Это сработает только если запускается клиент с пользовательским режимом.
Конфигуратором насрать в хранилище можно и без этого, и никакая проверка не защитит. А вот сервер хранилища (служба) решает этот вопрос.

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

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

Но в любом случае разные платформы не оставим.

(22) вернее, не на совсем новую, а на максимально стабильно работающую новую

(26) его не надо "сравнивать" - если вы сравниваете боевую с конфигурацией из хранилища, то тогда вы действительно "сравниваете", только это идентично тому, что сравнение происходит с CF-файлом. Разработчикам до поры до времени действительно удобно не выгружать готовый CF, а заниматься эквилибристикой в виртуальном пространстве :-)

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

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

(27) Зачем он редакцию платформы поменял - это очень легко догадаться.

У Заказчика-Клиента на этом же сервере работает БП 3 Типовая и обновление типовой БП 3 выдала ему требование на смену подредакции платформы. И вся так называемая инертность его пошла лесом.

(29) пока платформу не сменят, я и так планирую боевые отключить.

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

(31) При использовании Хранилища для разработки преимущество только версионность снимков отдельных объектов метаданных, их история.

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

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

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