Правильное обновление доработанных конфигураций
Приветствую!
Знаю, что избитая тема, но что-то закрались сомнения у меня к той методике, что я использую.
У меня сейчас 4 базы Бухгалтерии (сейчас перехожу на 3.0), достаточно доработанные.
И при обновлении я поступаю так:
У меня есть отдельная база "Поставка".
Которую я обновляю типовым способом последовательно, записывая, какие доработки у меня затерлись.
Далее открывая необновленную базу и по списку доработок, переношу все изменения в Поставку.
Затем создаю файлы поставки Меню Конфигурация - Поставка - Создать файлы поставки.
И уже этим созданным файлом поставки обновляю все свои базы.
А сомнения у меня закрались вот какие, базу Поставки я обновляю последовательно, а вот при обновлении рабочих баз получается я разом обновляю через 3-5 обновлений (раз в 2-3 месяца).
Насколько это правильный путь?
И как будет в такой ситуации с объектами которые были удалены?
Ну и может кто поделится своим опытом обновления одновременно несколько доработанных одинаковых баз?
Знаю, что избитая тема, но что-то закрались сомнения у меня к той методике, что я использую.
У меня сейчас 4 базы Бухгалтерии (сейчас перехожу на 3.0), достаточно доработанные.
И при обновлении я поступаю так:
У меня есть отдельная база "Поставка".
Которую я обновляю типовым способом последовательно, записывая, какие доработки у меня затерлись.
Далее открывая необновленную базу и по списку доработок, переношу все изменения в Поставку.
Затем создаю файлы поставки Меню Конфигурация - Поставка - Создать файлы поставки.
И уже этим созданным файлом поставки обновляю все свои базы.
А сомнения у меня закрались вот какие, базу Поставки я обновляю последовательно, а вот при обновлении рабочих баз получается я разом обновляю через 3-5 обновлений (раз в 2-3 месяца).
Насколько это правильный путь?
И как будет в такой ситуации с объектами которые были удалены?
Ну и может кто поделится своим опытом обновления одновременно несколько доработанных одинаковых баз?
По теме из базы знаний
- Обновление доработанной Бухгалтерии предприятия. Как проверить и убедиться, что все сделано хорошо?
- Обновление типовой доработанной конфигурации для начинающих
- Как читать чужой код? Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации
- Использование внешних программных средств при обновлении конфигураций 1С
- Как не сгореть на обновлениях
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) FreeArcher, да, действительно, не желательно перепрыгивать через несколько релизов. А твоим способом как раз это и получается.
Из своего опыта(и опыта коллег) работы во франче:
- Перепрыгивание через 3-5 релизов не так страшно, есть риск, но минимален. В 1С удаляют объект очень постепенно и это может длиться долго, а не в 1 релиз.
- Если будет обнаружено, что объект был удалён, то при первом запуске, в пользовательском режиме, тебе будет выдана ошибка обновления. Восстановишь из архива базу и постепенно обновишь. Т.е., как я знаю, незаметно это не пройдёт.
Из своего опыта(и опыта коллег) работы во франче:
- Перепрыгивание через 3-5 релизов не так страшно, есть риск, но минимален. В 1С удаляют объект очень постепенно и это может длиться долго, а не в 1 релиз.
- Если будет обнаружено, что объект был удалён, то при первом запуске, в пользовательском режиме, тебе будет выдана ошибка обновления. Восстановишь из архива базу и постепенно обновишь. Т.е., как я знаю, незаметно это не пройдёт.
У меня при обновлении участвуют три базы. Одна полностью типовая, в ней новый релиз сравнивается с тем релизом, с которого обновляю. Вторая доработанная, необновленная, в ней текущая конфигурация сравнивется с конфигурацией поставщика и видны все доработки. Третья, такая же как вторая, только она через поддержку конфигурации обновляется на новый релиз. Все нужные галочки 1С ставит сама, надо только проверить, что б не затерлись доработки. По времени обновление хорошо доработанной конфигурации занимает 2 часа. После формирования файла обновленной конфигурации загружаю эту конфигурацию на все базы. Ни разу никакой ошибки не было. Только обновления не перепрыгиваю делаю все последовательно.
1)Выгружаю cf-ку до обновления и загружаю в пустую(потом сравниваю Основную конфигурацию и Конфигурацию поставщика,чтобы можно было найти все изменения)
2)Обновляю рабочую базу до последнего релиза
3)Вношу изменения из пункта 1
2)Обновляю рабочую базу до последнего релиза
3)Вношу изменения из пункта 1
На обновлениях уже собаку съел. В наличии сильно изнасилованная УПП
1. Обновляю образцовую Демо-базу, из нее получаем конфигурацию поставщика.
2. Убеждаемся, что версия основной конфигурации и конфигурации поставщика в целевой базе совпадают.
3. Создаем копию целевой базы
4. Обновляем конфигурацию поставщика, по флагам "изменено у нас", "изменено у поставщика" обновляем в первом заходе основную конфигурацию. На первом заходе берем только то, что менялось у поставщика и не менялось у нас. То что изменено и у нас и у поставщика записываем на бумажке или в блокноте Windows.
5. При ответе на вопрос о правилах поддержки советую ставить "редактирование запрещено" для объектов полностью совпадающих с поставщиком и "редактирование с сохранением поддержки" для измененных нами объектов.
6. Сохраняемся (но не обновляем ИБ), запускаем повторное сравнение с конфигурацией поставщика, подробно изучаем избранные объекты (которые выписали), смотрим как удобнее с ними быть (откуда проще взять, чтобы править ручками поменьше). Создаем пустую базу и внешнюю обработку. В ней собираем и сразу приводим в нормальное состояние процедуры, которые потом в ручном режиме придется докинуть в конфигурацию.
7. Объединяем те, объекты, которые решили брать из конфигурации поставщика, разблокируем (они будут блокированы автоматически как только станут идентичными) переносим туда наши процедуры.
8. Обновляем копию, убеждаемся что она жива, выгружаем конфу.
На реальной базе - п.4, 5 затем разблокируем все объекты, сравниваем с конфигурацией, заготовленной на копии, еще раз проверяем, что наши изменения не утеряны (при желании), сохраняем.
Сравниваем с конфигурацией поставщика, жмем объединить при снятии всех флагов (от этого на место встают блокировки полностью стандартных объектов), сохраняемся, обновляем базу.
Ну и собственно облегчают жизнь общеизвестные правила:
1. Своим собственным реквизитам и объектам не забывайте давать префиксы имен. Сам факт наличия нестандартного реквизита или объекта проблем никаких не доставляет.
2. Та самая блокировка изменения того, что не изменяли и не собираетесь. Один визитер, поставивший случайно лишний пробел для конфигуратора сразу переводит объект в разряд нестандартных. п.4 при этом будет работать не так как хотелось бы. Кроме того блокировка на объекте прекрасный ориентир.
3. Не увлекайтесь размещением своего кода вперемешку среди кода поставщика. Обычно достаточно поставить одну строку, уводящую код в наш модуль, и комментарий кто когда и зачем. Там он и не потеряется, и глаза разбегаться не будут при сравнении модулей.
4. На стандартные формы реквизиты добавляйте динамически. Для этого стоит завести отдельный модуль. Большинство форм при таком подходе вообще не требуется изменять.
1. Обновляю образцовую Демо-базу, из нее получаем конфигурацию поставщика.
2. Убеждаемся, что версия основной конфигурации и конфигурации поставщика в целевой базе совпадают.
3. Создаем копию целевой базы
4. Обновляем конфигурацию поставщика, по флагам "изменено у нас", "изменено у поставщика" обновляем в первом заходе основную конфигурацию. На первом заходе берем только то, что менялось у поставщика и не менялось у нас. То что изменено и у нас и у поставщика записываем на бумажке или в блокноте Windows.
5. При ответе на вопрос о правилах поддержки советую ставить "редактирование запрещено" для объектов полностью совпадающих с поставщиком и "редактирование с сохранением поддержки" для измененных нами объектов.
6. Сохраняемся (но не обновляем ИБ), запускаем повторное сравнение с конфигурацией поставщика, подробно изучаем избранные объекты (которые выписали), смотрим как удобнее с ними быть (откуда проще взять, чтобы править ручками поменьше). Создаем пустую базу и внешнюю обработку. В ней собираем и сразу приводим в нормальное состояние процедуры, которые потом в ручном режиме придется докинуть в конфигурацию.
7. Объединяем те, объекты, которые решили брать из конфигурации поставщика, разблокируем (они будут блокированы автоматически как только станут идентичными) переносим туда наши процедуры.
8. Обновляем копию, убеждаемся что она жива, выгружаем конфу.
На реальной базе - п.4, 5 затем разблокируем все объекты, сравниваем с конфигурацией, заготовленной на копии, еще раз проверяем, что наши изменения не утеряны (при желании), сохраняем.
Сравниваем с конфигурацией поставщика, жмем объединить при снятии всех флагов (от этого на место встают блокировки полностью стандартных объектов), сохраняемся, обновляем базу.
Ну и собственно облегчают жизнь общеизвестные правила:
1. Своим собственным реквизитам и объектам не забывайте давать префиксы имен. Сам факт наличия нестандартного реквизита или объекта проблем никаких не доставляет.
2. Та самая блокировка изменения того, что не изменяли и не собираетесь. Один визитер, поставивший случайно лишний пробел для конфигуратора сразу переводит объект в разряд нестандартных. п.4 при этом будет работать не так как хотелось бы. Кроме того блокировка на объекте прекрасный ориентир.
3. Не увлекайтесь размещением своего кода вперемешку среди кода поставщика. Обычно достаточно поставить одну строку, уводящую код в наш модуль, и комментарий кто когда и зачем. Там он и не потеряется, и глаза разбегаться не будут при сравнении модулей.
4. На стандартные формы реквизиты добавляйте динамически. Для этого стоит завести отдельный модуль. Большинство форм при таком подходе вообще не требуется изменять.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот