При работе с доработанными конфигурациями 1С, особенно когда они подключены к хранилищу конфигурации, процесс обновления может вызывать затруднения. Одна из частых проблем, с которой сталкиваются разработчики, — это недоступность кнопки "Загрузить конфигурацию из файла". Давайте разберемся, почему это происходит и как правильно обновить нашу конфигурацию, сохраняя все доработки и поддерживая связь с хранилищем.
Когда наша конфигурация подключена к хранилищу, система 1С ожидает, что все изменения в конфигурации будут управляться через механизмы самого хранилища. Это сделано для обеспечения целостности и контроля версий при командной разработке. Прямая загрузка конфигурации из файла .cf минует эти механизмы, что может привести к потере истории изменений, конфликтам и другим проблемам. Именно поэтому кнопка "Загрузить конфигурацию из файла..." в такой ситуации становится неактивной.
Чтобы иметь возможность вносить изменения в объекты метаданных, их необходимо предварительно "захватить" из хранилища. Это может быть сделано для каждого объекта по отдельности, но при масштабных операциях, таких как обновление конфигурации, предпочтительнее и эффективнее захватывать все объекты рекурсивно.
Стандартный и рекомендуемый способ обновления конфигурации, подключенной к хранилищу, заключается в использовании команды "Конфигурация – Поддержка – Обновить конфигурацию" (если обновление выполняется из файла обновления .cfu или через шаблоны поставщика) или "Конфигурация – Сравнить, объединить с конфигурацией из файла" (если используется полный файл конфигурации .cf).
Рассмотрим по шагам общий порядок действий, который поможет нам успешно обновить доработанную конфигурацию, подключенную к хранилищу:
Создаем резервную копию информационной базы. Это критически важный шаг, который никогда нельзя игнорировать. Перед началом любых работ по обновлению обязательно убедимся, что у нас есть полная и актуальная резервная копия нашей информационной базы. Это наша страховка на случай непредвиденных проблем.
Блокируем ветку хранилища. Если мы работаем в команде, то перед началом масштабного обновления рекомендуется заблокировать ветку хранилища, в которой будут производиться изменения. Также необходимо предупредить других разработчиков, чтобы они не совершали коммитов в эту ветку на время нашего обновления. Это позволит избежать возможных конфликтов и обеспечит чистоту процесса обновления.
Захватываем все объекты конфигурации рекурсивно. В нашей локальной конфигурации необходимо захватить все объекты метаданных рекурсивно. Это позволит нам вносить в них изменения в процессе обновления и разрешать потенциальные конфликты. Для этого мы можем зайти в меню "Конфигурация" -> "Хранилище конфигурации" -> "Захватить все объекты".
Выполняем обновление или сравнение/объединение. После захвата всех объектов мы можем приступить к самому процессу обновления. У нас есть два основных сценария:
Обновление с помощью файла обновления .cfu или через шаблоны поставщика: Используем команду "Конфигурация – Поддержка – Обновить конфигурацию". Этот способ предпочтителен для последовательного обновления. Система сама предложит нам файл обновления или найдет его в шаблонах.
Обновление с помощью полного файла конфигурации поставщика .cf: Используем команду "Конфигурация – Сравнить, объединить с конфигурацией из файла...". Этот метод часто используется, когда мы пропускаем несколько релизов или хотим обновиться сразу до конкретной версии, имея на руках полный .cf-файл нужного релиза.
В процессе сравнения и объединения нам потребуется внимательно анализировать различия и разрешать конфликты. Наша главная задача — сохранить сделанные нами доработки, но при этом применить все изменения, внесенные поставщиком. Этот этап требует особого внимания и глубокого понимания структуры конфигурации.
Проводим тщательное тестирование. После успешного обновления конфигурации в локальной базе и перед ее помещением в хранилище, нам необходимо провести исчерпывающее тестирование. Убедимся, что все наши доработки функционируют корректно с новой версией типовой конфигурации, а стандартный функционал работает без ошибок.
Помещаем обновленную конфигурацию в хранилище. После успешного обновления и тестирования, обновленную конфигурацию следует поместить в хранилище. Обязательно добавим соответствующий комментарий, который будет отражать версию обновления и кратко описывать внесенные изменения. Например: "Обновление конфигурации до версии 2.3.15.22".
Запускаем информационную базу в режиме "1С:Предприятие". Для окончательного завершения обновления и выполнения всех обработчиков обновления данных (например, обработки по изменению структуры регистров, переносу данных) нам необходимо запустить информационную базу в режиме "1С:Предприятие". Это важно для корректной миграции данных и подготовки базы к полноценной работе.
Вопрос возврата объектов на поддержку очень актуален, особенно если мы хотим сохранить наши доработки, но при этом иметь возможность получать обновления от поставщика для этих же объектов. Эксперимент, упомянутый в дискуссии, показывает, что простое снятие конфигурации с поддержки и последующее объединение не вернет объекты в режим поддержки автоматически.
Если мы хотим вернуть объекты на поддержку, сохраняя при этом внесенные доработки, или изменить правила поддержки для отдельных объектов, то это делается через окно "Настройка поддержки". Мы можем найти его, выбрав меню "Конфигурация – Поддержка – Настройки поддержки".
В этом окне перед нами откроется возможность установить для каждого объекта метаданных нужный режим поддержки. Например, мы можем выбрать режим "Редактируется с сохранением поддержки". Этот режим позволяет нам изменять объект конфигурации, но при этом он все еще считается находящимся на поддержке поставщика. Это означает, что при следующем обновлении система будет уведомлять нас о изменениях в типовом объекте, и мы сможем выбрать, какие изменения от поставщика применить, а какие оставить за нашими доработками.
Важно помнить, что включение возможности изменения конфигурации (через "Включить возможность изменения") не снимает ее с поддержки полностью. Оно лишь меняет статус конфигурации с "Типовая" на "Нетиповая", тем самым предоставляя нам возможность вносить изменения в метаданные.
Таким образом, для возврата на поддержку с сохранением доработок, наш путь следующий: "Конфигурация – Поддержка – Настройки поддержки", далее "Сравнение, объединение с конфигурацией поставщика", где мы выбираем режим поддержки для каждого измененного объекта, например, "Редактируется с сохранением поддержки".
В дискуссии был затронут очень важный момент, касающийся рисков пропуска промежуточных релизов. Это особенно актуально, когда мы обновляем конфигурацию, которая претерпела значительные изменения, как в случае с ERP или даже "Розницей", в которой постоянно появляются новые функции и исправляются ошибки.
Пропуск промежуточных релизов сопряжен со значительными рисками по нескольким причинам:
Изменения в структуре данных: Обновления 1С включают не только изменения в программном коде, но и модификации в структуре объектов данных. Это могут быть добавление или удаление реквизитов, изменение типов данных, создание новых регистров и таблиц. Если мы пропускаем релиз, в котором происходили такие изменения, то наша база данных может оказаться в неконсистентном состоянии, что приведет к ошибкам.
Перенос данных: Между релизами часто выполняется перенос данных из старых структур в новые. Например, если какой-то регистр удаляется, а его данные переносятся в другое место. Эти операции обычно выполняются специальными обработчиками обновления, которые запускаются при первом запуске базы в режиме "1С:Предприятие" после обновления конфигурации. Пропустив эти релизы, мы пропустим и выполнение этих обработчиков, что может привести к потере данных или некорректной работе функционала.
Инкрементальные изменения: Файлы обновлений (.cfu) обычно содержат только инкрементальные изменения, произошедшие между двумя конкретными версиями. Если мы пропустим несколько версий, то эти инкрементальные изменения не будут применены, что приведет к рассинхронизации конфигурации и потенциальным ошибкам при попытке обновить базу до более поздней версии.
Ключевые релизы: Некоторые релизы являются "ключевыми" и содержат фундаментальные изменения, без которых дальнейшее обновление или корректная работа системы невозможна. Пропуск таких релизов особенно критичен.
Хотя иногда возможно обновить базу одним .cf-файлом, перескочив несколько релизов (особенно если изменения в промежуточных версиях минимальны и не затрагивают структуру данных критически), этот подход не рекомендуется для доработанных баз из-за высокого риска потери данных, возникновения нестабильной работы и сложностей с последующими обновлениями. Если у нас возникла необходимость обновить базу через несколько релизов, и мы не можем сделать это последовательно, нам необходимо быть предельно внимательными и провести очень тщательное тестирование после такого "скачкообразного" обновления.
В любом случае, последовательное обновление (релиз за релизом) является наиболее безопасным и рекомендуемым способом, особенно для сложных и активно развивающихся конфигураций.