Переход на новую версию платформы 1С — это всегда ответственный шаг, который требует взвешенного подхода. Ситуация осложняется, когда речь идет о переходе на тестовую сборку, такую как 8.3.23.1437. В этой статье мы проанализируем, оправдано ли внедрение «сырой» платформы в продуктивную среду, разберем причины, толкающие администраторов на этот риск, и найдем альтернативные способы решения проблем совместимости с современными конфигурациями.
Основным триггером для обновления часто выступают требования новых релизов типовых конфигураций. Например, «1С:Документооборот 3.0» в последних обновлениях начал требовать версию платформы не ниже 8.3.22.1709. У многих специалистов возникает логичный вопрос: стоит ли ставить промежуточный релиз ветки 8.3.22 или лучше сразу «прыгнуть» на новую ветку 8.3.23, чтобы получить все исправления и новые функциональные возможности?
Разберем ситуацию, когда текущая версия (например, 8.3.22.1704) имеет критические баги. В частности, в этой версии была замечена ошибка: стандартная функция «Управление расширениями конфигурации» при команде «Проверить возможность применения» игнорирует проверку модулей. Такие «мелочи» могут существенно осложнить жизнь разработчику, заставляя его искать спасения в более свежих сборках.
Давайте проанализируем, почему опытные коллеги советуют проявлять осторожность. Статус «Тестовая сборка» (Beta) для платформы 8.3.23.1437 означает следующее:
rphost в первых сборках новой ветки часто ведут себя непредсказуемо, завершаясь аварийно при специфических нагрузках или сложных запросах.Важно помнить: использование версии с окончанием на «первые сотни» (как .1437) фактически делает вашу компанию бета-тестером. Для продуктивной среды лучше дождаться выхода 3–4 корректирующих релизов внутри ветки.
Если мы все же рассматриваем переход ради «плюшек», давайте выясним, что именно предлагает платформа 8.3.23:
Rosetta 2.Однако для типовых задач того же «Документооборота 3.0» эти новшества не являются критически необходимыми для повседневной работы.
Если ваша конфигурация (например, ДО 3.0) отказывается запускаться на текущей платформе, требуя 8.3.22.1709, а переходить на тестовую 23-ю страшно, проанализируем «обходной маневр». В 99% случаев это требование можно отключить в коде.
Рассмотрим, как это сделать. Как правило, проверка версии зашита в процедурах начала работы системы. Вы можете воспользоваться механизмом расширений, чтобы переопределить поведение системы:
&Вместо("ПроверитьМинимальноДопустимуюВерсиюПлатформы")
Процедура Мой_ПроверитьМинимальноДопустимуюВерсиюПлатформы()
// Просто ничего не делаем или выводим предупреждение,
// но позволяем системе работать дальше
Возврат;
КонецПроцедуры
Часто такие проверки носят рекомендательный характер, и если в коде конфигурации не используются методы, которые появились только в новой версии платформы, система будет работать стабильно.
Давайте сопоставим варианты действий для системного администратора и программиста 1С:
Проанализируем «типовой ноябрьский набор» платформ: 8.3.17.2760, 8.3.18.1959, 8.3.19.1726, 8.3.20.2184, 8.3.21.1624, 8.3.22.1709. В этих версиях нет революционной функциональности. Основная причина их появления — исправление критических ошибок безопасности и лицензирования. Поэтому, если ваша задача — просто запустить обновленную конфигурацию, переход на 23-ю ветку является избыточным и опасным.
Подводя итог нашему анализу, можно сделать следующие выводы:
Во-первых, переход продуктовой среды на тестовую версию 8.3.23.1437 крайне не рекомендуется. Риск получить нестабильную систему перевешивает любые потенциальные выгоды от новых функций.
Во-вторых, если конфигурация требует новую платформу, проверьте, не вызвано ли это требование просто политикой вендора. В большинстве случаев достаточно обновиться до последнего стабильного релиза ветки 8.3.22.
В-третьих, всегда тестируйте обновление на копии базы. Если вы все же решились на 23-ю ветку, убедитесь, что у вас настроены регулярные бэкапы и есть план быстрого отката на предыдущую версию платформы.
Рассматривайте обновление платформы не как самоцель, а как инструмент решения конкретных задач. Для стабильной работы предприятия надежность платформы всегда должна стоять на первом месте.