Откатить до версии хранилище 1с
Нередкая ситуация у программистов 1С – у вас новый клиент, вы начинаете с ним работать, при знакомстве с информационной базой выясняется, что решение “не обновляемое” (снято с поддержки, обновлено “криво” и т.д.). Далее возникает трудоемкая задача перевода базы в разряд “обновляемых”.
Разбираем варианты решения данной проблемы!
Вопрос
Здравствуйте! Есть доработанная конфигурация 1С:БП. Она видимо была очень “криво” обновлена. Версии поставщика и основной конфигурации совпадают, но при их сравнении возникает огромное количество различий никак не связанных с доработками. Есть предположение, что кто-то просто дообновил конфигурацию поставщика и исправил вручную версию основной конфигурации. Через поддержку совсем не идет обновление, через “сравнить-объединить” вроде получилось, но опять-таки это какое-то “кривое” решение. Вопрос в том, какие выходы могут быть из данной ситуации?
Ответ
Есть несколько предложений:
- Создаем пустую типовую базу этого же релиза, переносим в нее все доработки конфигурации. Получаем новую базу, у которой нет проблем с конфигурацией поставщика, сохранены все доработки. Теперь в нее нужно перенести данные из текущей базы. Поскольку конфигурации полностью совпадают, можно воспользоваться “Конвертацией данных”, сгенерировать автоматически правила для обмена между одинаковыми конфигурациями. При помощи этих правил можно перенести все данные из старой базы в новую. Недостаток такого подхода – перенос данных может быть достаточно долгим по времени.
- Полностью снимаем конфигурацию с поддержки (меню Конфигурация – Поддержка – Настройки поддержки). После этого выполняем сравнение-объединение с cf-файлом типовой конфигурации этого же релиза (его можно взять на партнерском ИТС или на пользовательском сайте фирмы “1С”, если для этого релиза выложен полный дистрибутив). После этого конфигурация станет на поддержку, а добавленные реквизиты или объекты метаданных останутся в конфигурации. Теперь остается только сравнить-объединить с исходной конфигурацией, чтобы перенести изменения в модулях, формах, выверить все доработки. Все данные в базе при этом должны сохраниться.
Комментарий слушателя
Воспользовался вторым вариантам. Обновление через поддержку теперь получается. Спасибо. Объекты не встали полностью на «замок», а только «редактируются с сохранением поддержки», так понимаю, что это нормальное поведение системы?
Если обновления делаются на копии. Обновляется до последнего релиза выгружается в cf , потом путем сравнить объединить конфигурацию из файла , обновляется и через поддержку «догоняем» конфигурацию поставщика. Но как быть если есть несколько ключевых релизов, делать несколько cf для каждого?
Ответ тренера
- Да, это нормально, что объекты не полностью “на замке”, а редактируются с сохранением поддержки. Чтобы все объекты снова оказались “на замке”, можно загрузить типовую конфигурацию поставщика (cf-файл из дистрибутива нужного релиза). Но тогда будут потеряны все доработки.
Еще вариант вернуть конкретный объект конфигурации “на замок” – выполнить сравнение-объединение с конфигурацией поставщика (в окне, открываемом из меню Конфигурация – Поддержка – Настройки поддержки), в открывшемся окне указать нужные настройки поддержки для конкретного объекта.
- Да, если ключевых релизов несколько, то придется несколько раз выполнить обновление.
Есть несколько способов перенести выполненное обновление из копии базы в рабочую:
Здравствуйте! Подскажите, а как можно удалить из хранилища то что не нужно обновлять? Один из разработчиков поместил в хранилище изменения для объекта, потом выяснилось что в рабочей базе это обновление не нужно применять. В рабочей базе данные из хранилища ещё не были получены.
Захватите объект, уберите изменения, снова поместите в хранилище.
Отмените захват объекта принудительно и поместите в хранилище объект из рабочей базы.
(2) Нельзя, это план счетов - в него сравнением-объединением добавили новые счета, а половина старых задвоилась и пометилась на удаление. это нельзя получать из хранилища, а то бухгалтерия четвертует и нас всех уволят нафиг))))
(4) Так и не получайте. У вас две базы, возьмите конфу из рабочей базы в тестовой захватите план счетов, объедините и замените на план счетов из файла и снова поместите в хранилище. Результатом буде план счетов в хранилище идентичный рабочей.
(1) А если просто поместить в хранилище объект из рабочей базы не захватывая? Прокатит? Сам не пробовал :-)
Выгружайте cfник из рабочей, захватывайте полностью все объекты на копии и загружайте цфник без сравнения-объединения. Потом все помещайте в хранилище обратно
Попробуйте открыть "История хранилища", выбрать версию до проблемных изменений и выполнить команду "Откатить до версии".
А можно как то удалить из хранилища, что бы вообще не получать эти объекты, как будто их там и не было? зачем все эти манипуляции
Если в хранилище конфигурации были опубликованы ненужные версии, конфигуратор предоставляет возможность отката до нужной версии хранилища. Для этого в списке версий нужно выбрать ту, до которой следует откатиться, и выбрать пункт Действия – Откатить до версии . На экран выводится вопрос-предупреждение: При выполнении отката информация об откатываемых версиях будет удалена без возможности восстановления. Продолжить? В случае утвердительного ответа будет произведен *, при котором из хранилища удаляются все версии, помещенные после указанной.
рабочая не должна быть подключена к хранилищу все обновления на продакт должны идти только под управлением ответственного человека или через объединение или через штатный механизм обновления 1с любые другие схемы работы приводят к косякам, реально приводят.
вообще, я удивляюсь олимпийскому спокойствию автора - продуктив подключен к хранилище, которое очевидно неисправно. И всем похер.
Ну вот сегодня как раз после обновления конфигурации по новой буду хранилище поднимать, надеюсь вы правы и ошибка уйдет. По Вашей логике ответственное лицо должно сидеть целыми днями и только и делать что тестировать то что накидали в храник перед накатом в рабочую (а как же общение с "бухами" и прочими "манагерами"). Мы оставили это на совести того кто заливает. Благо возможности хранилища позволяют отследить кто последний мог внести кривые изменения кому и выписывается в крайнем случае лекарство
по тому, что довольно часто возникает как банальное ресинхронизация хранилища (например кто-то восстановил средствами скуля бекап не отключив копию базы от хранилища) или в хранилище помещают изменения которые необходимы другому разработчику, но категорически недопустимы в продакте (например изменение типа измерения регистра нужно и для прога1 пишущего отчет и для прога2 который должен изменить модули проведения, при этом в хранилище помещают измененый регистр и работают оба прога, а если такой регистр накатить на продакт можно банально при приведении типов все потерять. )
ответственное лицо должен понимать во первых архитектуру решения, во вторых он должен тестировать критические обновления на копии, самый простой способ тестирования - перепроведение за 1 период (квартал/месяц) и сравнение результата с рабочей. а обновлять он должен или ночью или рано утром.
на самом деле проблема только в рассинхронизациях. Хранилища в любом случае должно быть, как минимум, два - в одном разработка, из второго обновлвения. Тех, которые разработка, может быть неограниченно много.
. банальное ресинхронизация хранилища. Согласен. Просто поднимать боевую базу из backup крайне редко приходится. . при этом в хранилище помещают измененый регистр и работают оба прога. Если я захватил регистр, то хрен его кто другой захватит. При захвате объекта он обновляется из хранилища. Есть, конечно, проблема, что один прог написал код, а другой изменил, например, регистр и код первого прога стал нерабочим. Но метод сравнения и объединения тут тоже не спасает.
"ТрансферныеЦены".. бгг знакомая конфа ) ларечные решения. У них база не позволяет так играться. Слишком большая какой смысл в двух Хранилищах? Чтобы руками переносить из одного в другое? Мегамысль
Еще раз. Как ты будешь переносить дневные изменения 5 кодеров из девелоперского в боевое хранилище. Озвучь метод плз
из архива поднимают в основном копии на которых проги работают. а бывает это как минимум раз в месяц, умножь на 5 человек и получим не так и редко про объединение - ты почему-то пропустил этап тестирования описанный в 11 который как минимум избавляет от критических ошибок. при 5 прогах по любому должен быть руководитель который обязан тестить сам (или требовать это от кого то) готовое к установке обновление в целом а не кусочками от каждого прога
в варианте с отдельным хранилищем к хранилищу продакта подключена еще тестовая база, сначала через объединение накатываем на тест и тестируем, если все в норме - кладем в хранилище. плюс такого подхода - продакт хранилище хранит только накатываемы конфы без всякого хлама. но я все равно считаю что продакт должно быть без хранилища
руками естественно. Девелоперов выводить в отдельное от обновления храилище нужно хотя бы за тем, чтобы была возможность выпускать хотфиксы в любой момент, когда надо. Без этого риск выпустить вместе с хотфиксом не протестированные изменения почти 100%. Когда разработчиков 2-3 и они в рабочее время успевают кино посмотреть, это, конечно же, избыточная мера.
руками переносят тимлиды или командир этих девелоперов, если тимлидов нет, их всего пять и начальник один.
и- таки-да - у того, кто переносит изменения в хранилище релиза, голова должна быть включена в розетку на время проведения сравнения-объединения
+17 А зачем переносить дневные изменения? Изменения переносятся в продуктовое хранилище только те, которые подготовлены и согласованы для внедрения. Кстати, это у вас нет разделения между поддержкой и разработкой. В этом случае отдельное хранилище для разработки необходимо - для того, чтобы собрать устойчивый релиз для тестирования крупных изменений.
Имеются ввиду дневные изменения выложенные в Хранилище разработчиками. А значит согласованные и протестированные ими. Зачем отдельное Хранилище, если можно подключить тестовую базу к этому же Хранилищу и получить конфу на тест. Боевая всегда подключена к хранилищу, но обновляется только по мере необходимости. Да и. Хранилище бэкапится. Главный вопрос - зачем второе хранилище, если одно прекрасно выполняет все перечисленные функции
если тебе надо выпустить хотфикс сегодня, сейчас, а в хранилище лежит какая-то хренобень, которую будут тестирвоать еще неделю и она затрагивает самый массовый документ в конфе. Что делать с одним хранилищем? Тестирование прерывать?
"рабочая не должна быть подключена к хранилищу" - так говорят только снобы которые в реальном производстве не работают, имхо.
чем реальное производство отличается от реальной торговли, или реальной "МММ" . а знаю, на реальном производстве стоят 286 под управлением DOS и на них стоит 1с 6.0 :))) зы я про производство знаю побольше многих, ибо работал станочником, наладчиком, оператором 7 лет, а потом в КБ автоматизировал техпроцессы ЧПУ (и хорошо автоматизировал).
В Хранилище не может быть хренобень. В Хранилище оттестированные и проверенные блоки. Если кто-то (какая-то) выложил хренобень, то его лечат +1 даже не спросили почему это боевая всегда подключена к Хранилищу. Да потому что подключение к Хранилищу длится часа два. А "проведение квартальчика для легкого теста" несколько суток.
странно, у меня подключение к хранилищу длится 5 минут для торговли и 10 для бухгалтерии, может Вы работаете на ноуте за 100баксов? а если проведение квартала идет более суток, то тогда его ТОЧНО нужно делать перед обновлением, ибо риски возрастают, или переходить на более прогрессивные формы автоматического тестирования, но ни в коем случае не доверять прогам этот процесс.
и по скорости проведения, 50 000 доков проводится примерно за 1. 2 час (по крайне мере у меня такая скорость) двое суток это 48*50000 = 2,4ляма доков в квартал, что примерно 10. 25 тыщ доков в день, интересно посмотреть на перца который в компании с таким документооборотом накатывает на продакт без тестирования да еще батником ночью :)) чем больше база - тем строже должны быть требования к тестированию, да и вообще к изменениям.
Ошибку я ниже привел по просьбе одного из участников. А параметры подключения к хранилищу и обновление смысла нет приводить, т.к. они стандартные. Вопрос рассчитан был на тех кто сталкивался с этим, а не для "карманных теоретиков".
Должно быть 2 хранилища как минимум. Одно боевое и одно (или несколько) для разработки. Так рекомендует сама 1с, да и вообще это бест практис из мира взрослого программирования
Это при активной разработке. Если в компании 2-3 программиста, которые не пишут ничего глобального (только ВПФ, загрузки, подписки, роли, права и т.д.) - то ничего страшного нет.
значит хренобень в тестовой базе будет в продуктив помещать будут не то, что тестировали. У тебя основной аргумент против двух хранилищ в том, что "это же руками накатывать на релиз и можно что-то потерять". При этом то, что на тестовую базу ты тоже накатываешь руками и можешь точно так же что-то потерять, ты игнорируешь.
я это и пытаюсь донести, но у некоторых тут очень деревенский туннель реальности и мы на разных языках общаемся в итоге
у меня тоже была проблема с долгим подключением к хранилищу. Это из-за большого количества записей в хранилище. Мне помогла функция хранилища "сократить до версии". Теперь подключается за 2 минуты.
-force — если при пакетном обновлении конфигурации из хранилища должны быть получены новые объекты конфигурации или удалиться существующие, указание этого параметра свидетельствует о подтверждении пользователем описанных выше операций. Если параметр не указан — действия выполнены не будут. Читайте документацию.
Каждый хочет держать под контролем свою жизнь, знать ответы на все вопросы. Так же дела обстоят в части информационных систем. Но здесь все значительно сложнее, так как ваша жизнь зависит от 3-10 человек. А в информационной системе зачастую работают 200 и 1000 сотрудников. И именно в таком потоке информации жизненно важно знать, что изменилось по сути и кто конкретно осуществил эти изменения.
Эту задачу давно ставили разработчикам 1C и вот, мы обрадованы появлением более или менее работающего механизма. Однако хранение версий в самой базе быстро приводит к ее росту. Устранению этого недостатка посвящена эта статья.
"
Версионирование 1С.
Механизм версионирования объектов используется для аудита изменений объектов информационной базы в разрезе времени и позволяет ответить на вопросы КТО, КОГДА и ЧТО изменил. В качестве версионируемых объектов могут выступать справочники и документы. Настройка механизма выполняется в форме настройки программы и доступна пользователю с ролью «Полные права». Настройка состоит из активизации механизма и настройки режима сбора версий документов и справочников.
Однако нет худа без добра. Со временем количество измененных записей по объему сопоставимо с основными данными, а потом попросту уходит в «отрыв» и превышает все разумные пределы. Что начинает существенно сказываться на объеме быстродействия системы.
Для устранения этого недостатка логично изымать эти данные и хранить их отдельно. Это тем более логично, когда информационных систем, которые необходимо подвергать аудиту, более чем одна.
Для решения этой задачи наша команда разработала программный продукт обладающий следующим функционалом:
1.Сбор данных об измененных объектах в фоновом режиме согласно расписанию. В рабочей базе остается только последнее изменение, количество «последних» регулируется. Так можно устранить «распухание» базы и одновременно можно в случае чего за секунду вернуть испорченный документ.
2.Формирование отчетов в части аудита (кто, что, когда изменил). Очень нравится «Безопасникам».
3.Все что когда либо менялось в системах.И все версии измененных объектов в одном месте в отдельной базе.Система собирает как версии так и журналы регистрации из указанных систем.
4. Но когда надо провести аудит изменений имеем полную картину.
В общем полезная система получилась. С одной стороны устраняет неопределенность изменений, а с другой дисциплинирует пользователей так как нет возможности свалить вину на «последнего».
Работа с хранилищем конфигурации
В 1с версии 7.7 совместная разработка или доработка конфигурации была настоящим мучением. Для того чтобы поддерживать одну конфигурацию даже вдвоем, приходилось делать две копии актуальной базы, затем, после внесенных изменений вручную переносить изменения из конфигурации одной копии в конфигурацию другой. Только потом можно было обновить основную поддерживаемую конфигурацию! Усугубляло положение отсутствие подсистем.
В восьмой версии 1с для совместной разработки используется хранилище конфигурации. Работа с хранилищем происходит следующим образом:
Выбираем в меню "Конфигурация"->"Хранилище конфигурации"->"Создать хранилище. "
Указываем путь к каталогу хранилища. (Каталог должен быть доступен для всех разработчиков!)
После того как хранилище создано, заходим в пункт меню "Конфигурация"->"Хранилище конфигурации"->"Администрирование" для того чтобы создать пользователей для разработчиков
. и создаем пользователей
- Подключаем конфигурации разработчиков к хранилищу конфигурации
выбираем пункт меню "Конфигурация"->"Хранилище конфигурации"->"Подключиться к хранилищу. "
Далее конфигуратор нас спросит
Так как у нас с вами копии основной базы пока идентичны, смело нажимаем кнопку "Да" и указываем путь к хранилищу, имя пользователя и пароль
Ждём, пока произойдет сравнение конфигурации с хранилищем.
Если всё прошло успешно, то справа от объектов конфигурации в дереве объектов должна появиться пиктограммка замка.
По умолчанию все объекты конфигурации имеют пиктограммку "замок". Для того чтобы изменить объект конфигурации нужно его захватить, то есть выбрать в контекстном меню объекта пункт "Захватить в хранилище"
указать настройки захвата
У объекта в дереве конфигурации появится пиктограмма
Если объект захвачен другим разработчиком, то объект в дереве конфигурации выглядит так
После того, как нужные изменения внесены, следует объект поместить снова в хранилище со сделанными изменениями. Выбираем в контекстном меню объекта конфигурайции пункт "Поместить в хранилище. "
- Если требуется отменить сделанные изменения и освободить объект от захвата, то выбираем в контекстном меню объекта пункт "Отменить захват"
- Если требуется восстановить объект из хранилища, то то выбираем в контекстном меню объекта пункт "Получить из хранилища. ". При этом внесенные изменения в то время, как объект был захвачен, теряются.
- Так же можно просмотреть историю версий и сравнить захваченный и измененный объект с объектом в хранилище.
- После того, как работа в копиях завершена(или завершен какой-то промежуточный этап), можно обновить конфигурацию основной базы для этого нужно выбрать пункт в меню "Конфигурация"->"Хранилище конфигурации"->"Обновить конфигурацию из хранилища" или "Конфигурация"->"Хранилище конфигурации"->"Сравнить/объединить конфигурацию с хранилищем".
Во втором случае произойдет более "мягкое" обновление конфигурации, то есть, можно будет посмотреть отчет по различиям объектов исходной конфигурации и хранилища.
Приятной вам разработки!
Каждая из типовых конфигураций 1С имеет свою собственную внутреннюю структуру и требует точных знаний особенностей настройки системы.
Для настройки 1С 8 заказчик составляет перечень требований, куда входят необходимые ему функции и наборы инструментов.
1Скрипт-менеджер
Выгрузка и загрузка данных. 1С7.7
Конфигурация IT-сервис.(Управляемое приложение)
Читайте также: