Обновление типовой через хранилище конфигурации #811472


#0 by MaiorovYury
Всем доброго дня Извиняюсь за нубский вопрос, но только недавно начал работать с хранилищем конфигурации и вот сейчас возник вопрос обновления доработанной типовой бух 3.0 через хранилище. Если я накачу 2 релиза (c 52.39 на 54.20 и сразу на 57.10) на тестовой базе и потом выгружу такую конфу в хранилище и обновлю рабочу из хранилища - все пройдет ок? Обновление нормально отработает для обоих релизов? Кто-нибудь так обновлялся? Немного смущает процесс который запускается после обновления релизов - дополнительные процедуры обработки данных.
#1 by D3O
процедуры обновления отработают. вопрос в другом: при работе с хранилищем необходимо будет снять с поддержки ;)
#2 by Fragster
нет
#3 by MaiorovYury
О_о вот это сюрприз) то есть получается надо обновлять отдельно от хранилища и потом пересоздавать хранилище?
#4 by MaiorovYury
я так понимаю мнения разделились, да?) кажется будут делать на двух тестовых и потом отпишусь сюда как и что)
#5 by Мыш
Не надо отключаться от хранилища.
#6 by Fragster
совсем по фэн шую - делаешь хранилище с типовой, из него делаешь свою поставку, делаешь релизы параллельно с типовой и накатываешь на рабочую уже свою поставку. рабочая на полной поддержке, но уже своей поставки, обновляется после бэкапа из командной строки автоматом ночью :)
#7 by MaiorovYury
вот это круто конечно)
#8 by Новиков
>>Если я накачу 2 релиза (c 52.39 на 54.20 и сразу на 57.10) на тестовой базе и потом выгружу такую конфу в хранилище и обновлю рабочу из хранилища - все пройдет ок? В общем случае нет, но скорее всего - да. Надо анализировать. Если есть желание протестить - обновляешься из хранилища и смотришь, отработают ли без ошибок все процедуры обновления. Если да - удача на твоей стороне :)
#9 by Fragster
а зачем в схеме из вообще хранилище?
#10 by Новиков
А зачем так делать - вот этот момент не понятен? Зачем типовую конфу обновлять через хранилище - какой в этом цимес для тебя?
#11 by Fragster
ну и да, рабочая не должна быть подключена к хранилищу
#12 by Fragster
хранилище нужно как раз в базе для разработки
#13 by MaiorovYury
, я почти каждый день делаю свои доработки. Соответственно делаю это на тестовой, там все проверяю и накатываю на рабочую через хранилище Теперь нужно обновить и основую - то есть накатить новый типовой релиз. Хотелось это тоже сначало сделать на тестовой, все проверить, и потом в один клик перенести на рабочую.
#14 by MaiorovYury
Сейчас уже накатываю новый релиз на тестовую. И думаю сначала перекинуть его на еще одну тестовую базу, для проверки И если все ок - уже накатывать на рабочую
#15 by Новиков
А конфа поставщика у тебя при таком раскладе обновляются тоже?
#16 by Fragster
надо делать на базе для разработки, которая подключена к хранилищу. потом из хранилища накатывать на тестовую, прогонять тесты, и, если ОК, то делать поставку. При этом в хранилище не должно быть помещено незаконченных вещей, т.е. выгрузив конфигурацию из хранилища в файл мы получаем целостную конфигурацию.
#17 by Fragster
у тебя поток continuos integration как-то неправильно построен
#18 by MaiorovYury
не уверен, что понял вопрос, но попробую ответить) вообще с хранилищем начал работать месяц назад. Конфу поставщика с тех пор еще не обновлял.
#19 by MaiorovYury
я свои поставки не делаю. То есть делаю все (и разработку и тесты) на тестовой базе и просто потом обновляю рабочую из хранилища Я фикси, если что)
#20 by Fragster
а нафиг тогда хранилище? сохраняй .cfы и все
#21 by MaiorovYury
доп проверка что в рабочей ничего не меняю))) да и как-то через хранилище быстрее и надежней кажется - не тот файл по крайней мере не выберу)))
#22 by Новиков
я так и думал, что тебе лень потом через cf накатывать. Ну, если ты перешел вообще уже на полный ручник, то тогда только тестируй и читай журнал регистрации. Или - не ленись, а делай свою подливу в хранилище до выхода очередного обязательного релиза. Тогда обезопасишься от тягостных дум. Ну и конечно, совет на все случаи жизни - беги оттуда, беги с фикси, развивайся и будь щастлив!!11 Не благодари.
#23 by Fragster
ну я тоже фикси, но читать документацию и статьи для развития это мне не мешает
#24 by Fragster
а для понимания, что и зачем, советую почитать . Оно про Git, но можно провести множество аналогий. Например сама конфигурация хранилища похожа на мастер ветку, захваченные объекты - это "ветки", которые сливаются при помещении их в хранилище. Соответственно, ну и основная типовая поставка - это параллельная ветка, изменения которой переливаются в "ветки" захваченных объектов, которые потом помещаются в "мастер"
#25 by Fragster
ну а из мастера делается уже свой "релиз"
#26 by Fragster
учитывая возможный переход на EDT + git это все равно надо будет изучить :)
#27 by Мыш
ЕДТ ещё сырой! )
#28 by Fragster
он не просто сырой, он мокрый. я жду пресс релиза о выпуске новой версии БСП целиком на EDT. тогда начно пользоваться. Но принципы GIT и прочих систем распределенной разработки надо изучить не только из-за EDT, но и в принципе для саморазвития
Тэги: 1С 8
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С