Всем доброго дня
Извиняюсь за нубский вопрос, но только недавно начал работать с хранилищем конфигурации и вот сейчас возник вопрос обновления доработанной типовой бух 3.0 через хранилище.
Если я накачу 2 релиза (c 52.39 на 54.20 и сразу на 57.10) на тестовой базе и потом выгружу такую конфу в хранилище и обновлю рабочу из хранилища - все пройдет ок?
Обновление нормально отработает для обоих релизов? Кто-нибудь так обновлялся?
Немного смущает процесс который запускается после обновления релизов - дополнительные процедуры обработки данных.

(0) процедуры обновления отработают. вопрос в другом: при работе с хранилищем необходимо будет снять с поддержки ;)

(1) нет

(1) О_о
вот это сюрприз)
то есть получается надо обновлять отдельно от хранилища и потом пересоздавать хранилище?

(2) я так понимаю мнения разделились, да?)
кажется будут делать на двух тестовых и потом отпишусь сюда как и что)

(4) Не надо отключаться от хранилища.

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

(6) вот это круто конечно)

(0) >>Если я накачу 2 релиза (c 52.39 на 54.20 и сразу на 57.10) на тестовой базе и потом выгружу такую конфу в хранилище и обновлю рабочу из хранилища - все пройдет ок?

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

а зачем в схеме из (0) вообще хранилище?

А зачем так делать - вот этот момент не понятен? Зачем типовую конфу обновлять через хранилище - какой в этом цимес для тебя?

ну и да, рабочая не должна быть подключена к хранилищу

хранилище нужно как раз в базе для разработки

(9), (10) я почти каждый день делаю свои доработки. Соответственно делаю это на тестовой, там все проверяю и накатываю на рабочую через хранилище
Теперь нужно обновить и основую - то есть накатить новый типовой релиз. Хотелось это тоже сначало сделать на тестовой, все проверить, и потом в один клик перенести на рабочую.

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

А конфа поставщика у тебя при таком раскладе обновляются тоже?

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

у тебя поток continuos integration как-то неправильно построен

(15) не уверен, что понял вопрос, но попробую ответить)
вообще с хранилищем начал работать месяц назад. Конфу поставщика с тех пор еще не обновлял.

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

(19) а нафиг тогда хранилище? сохраняй .cfы и все

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

(21) я так и думал, что тебе лень потом через cf накатывать. Ну, если ты перешел вообще уже на полный ручник, то тогда только тестируй и читай журнал регистрации. Или - не ленись, а делай свою подливу в хранилище до выхода очередного обязательного релиза. Тогда обезопасишься от тягостных дум. Ну и конечно, совет на все случаи жизни - беги оттуда, беги с фикси, развивайся и будь щастлив!!11 Не благодари.

(22) ну я тоже фикси, но читать документацию и статьи для развития это мне не мешает

а для понимания, что и зачем, советую почитать https://habrahabr.ru/post/106912/ . Оно про Git, но можно провести множество аналогий. Например сама конфигурация хранилища похожа на мастер ветку, захваченные объекты - это "ветки", которые сливаются при помещении их в хранилище. Соответственно, ну и основная типовая поставка - это параллельная ветка, изменения которой переливаются в "ветки" захваченных объектов, которые потом помещаются в "мастер"

ну а из мастера делается уже свой "релиз"

учитывая возможный переход на EDT + git это все равно надо будет изучить :)

(26) ЕДТ ещё сырой! )

(27) он не просто сырой, он мокрый. я жду пресс релиза о выпуске новой версии БСП целиком на EDT. тогда начно пользоваться. Но принципы GIT и прочих систем распределенной разработки надо изучить не только из-за EDT, но и в принципе для саморазвития