Какие изменения я внес я знаю , а вот как узнать какие внес чувак до меня ? Если он не оставил комментариев , если сравнивать основную и поставщика там вылазит куча объектов , как узнать что это бывший програмер изменил модуль ? И еще , а если обновить до последнего релиза а потом сравнить его с cf который сделали дома ? Какой смысл обновлять сначала промежуточный , затем на тот что дома сделали и так до последнего , я же знаю какие изменения были и внесу их в последний обновленный релиз .
Ильяс, сижу и думаю, почему нельзя у клиента обновиться через шаблоны обновлений до актуального релиза с затиранием конфликтных доработок, а потом объединить с приоритетом подготовленного CF Файла актуального релиза. Зачем эти карусели с промежуточными релизами доработанных CF?
Если изменения касаются только модулей, то может и есть смысл так сделать. А если изменения затрагивают данные (например, поменяли свойства реквизитов), то лучше "карусель")
@@programming_1C а что если создать у себя 2 копии исходной базы. Одну прогоняем по шаблонам обновлений до последнего релиза, теряя доработки, с запуском в пользовательском режиме после каждой итерации для отработки скриптов. Вторую копию обновляем пошагово, наблюдая, в каких объектах какие доработки утеряны, переносим утерянное в первую базу. Во второй базе соглашаемся с утерей доработок, обновляем. Накатываем на вторую следующий релиз, видим что на этом шаге затрём из доработок, переносим их в первую базу. И так далее до финального релиза.
@@programming_1C Пример: есть у меня правка в основной конфигурации в макете или форме элемента справочника или в обработке подбора товара в реализацию, зачем на каждой итерации обновления релиза вносить одни и те же изменения, чтобы следующий релиз затер мои изменения (если поставщик также исправляет данные объекты)... Я лучше до финального релиза обновлю, и только в финальном поправлю формы/макеты/обработки.
Примеров таких я приводить не стану, но это не значит, что с этим нельзя столкнуться, да вероятность может и мала, но она не нулевая. Более подробно о механизмах сопоставления идентификаторов объектов, и к чему может привести загрузка конфигурации, читайте в этой статье: its.1c.ru/db/metod8dev/content/2291/hdoc
Блог "Программирование в 1С для всех" - www.1s-up.ru
Автор очень хорошо объясняет!!! Огромное спасибо Ильясу!=)
Всё интереснее и интереснее! Спасибо!
Ваши видео прямо инструкция к действию. Огромное спасибо!
Канал просто находка! Супер серия! Огромная благодарность!
Отличный канал, отличные видео, отличная серия! Однозначно подписка!
Ильяз, спасибо за то, что делитесь с нами важными знаниями.
Очень интересно про обновление нетиповых, жду продолжения серии!
Серия огонь! Коммент в поддержку канала!
Очень интересный ролик, интересный канал! Рекомендую! спасибо за труд!
Всем рекомендую! Продолжай в том же духе!
Ильяз, благодаря за видео. Очень хорошая тема обновление нетиповой БД 1С в несколько релизов.
Очень доходчиво и понятно. Благодарю за ценную инфу
Ролик супер! спасибо за труд! Жду продолжения
Очень познавательный ролик! Спасибо за ценные знания!
Отличный канал! Спасибо, за то что делитесь с нами знаниями!
Спасибо за ролик! Комментарий в поддержку видео!
Комментарий в поддержку видео!
очень нужная вещь с работы с 1 C
Лайк и комментарий в поддержку видео.
Ильяс, продолжай в том духе, про обновления нетиповых очень мало инфы!
Какие изменения я внес я знаю , а вот как узнать какие внес чувак до меня ? Если он не оставил комментариев , если сравнивать основную и поставщика там вылазит куча объектов , как узнать что это бывший програмер изменил модуль ? И еще , а если обновить до последнего релиза а потом сравнить его с cf который сделали дома ? Какой смысл обновлять сначала промежуточный , затем на тот что дома сделали и так до последнего , я же знаю какие изменения были и внесу их в последний обновленный релиз .
Про нетиповые очень интересно, очень мало инфы по ним.
Ильяс, сижу и думаю, почему нельзя у клиента обновиться через шаблоны обновлений до актуального релиза с затиранием конфликтных доработок, а потом объединить с приоритетом подготовленного CF Файла актуального релиза. Зачем эти карусели с промежуточными релизами доработанных CF?
Если изменения касаются только модулей, то может и есть смысл так сделать. А если изменения затрагивают данные (например, поменяли свойства реквизитов), то лучше "карусель")
@@programming_1CСпасибо Ильяс! Уроки все подробные, со всеми подводными камнями. Респект тебе!
Получается на сколько релизов обновляем, столько же раз восстанавливаем свои доработки и выгружаем конфу в cf?
Да
@@programming_1C а что если создать у себя 2 копии исходной базы. Одну прогоняем по шаблонам обновлений до последнего релиза, теряя доработки, с запуском в пользовательском режиме после каждой итерации для отработки скриптов. Вторую копию обновляем пошагово, наблюдая, в каких объектах какие доработки утеряны, переносим утерянное в первую базу. Во второй базе соглашаемся с утерей доработок, обновляем. Накатываем на вторую следующий релиз, видим что на этом шаге затрём из доработок, переносим их в первую базу. И так далее до финального релиза.
@@programming_1C Пример: есть у меня правка в основной конфигурации в макете или форме элемента справочника или в обработке подбора товара в реализацию, зачем на каждой итерации обновления релиза вносить одни и те же изменения, чтобы следующий релиз затер мои изменения (если поставщик также исправляет данные объекты)... Я лучше до финального релиза обновлю, и только в финальном поправлю формы/макеты/обработки.
Всё таки лучше cf-никами не обновлять… Я всегда ими обновлял, и особых проблем ни когда не было…
Бред какой-то, а нельзя сразу cf файл загрузить сразу, а приходится делать эти лишние сравнения объединения
При загрузке cf-файла, есть вероятность потерять информацию
@@programming_1C можете привести пример такой ситуации?
Примеров таких я приводить не стану, но это не значит, что с этим нельзя столкнуться, да вероятность может и мала, но она не нулевая. Более подробно о механизмах сопоставления идентификаторов объектов, и к чему может привести загрузка конфигурации, читайте в этой статье: its.1c.ru/db/metod8dev/content/2291/hdoc
Всё интереснее и интереснее! Спасибо!
Отличный канал, отличные видео, отличная серия! Однозначно подписка!
Всё таки лучше cf-никами не обновлять… Я всегда ими обновлял, и особых проблем ни когда не было…