Сценарий обновления платформы 1С:Предприятие 8 для deb-based ОС Linux для реализации простого способа обновления из установочных файлов формата производителя.
Файлы
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
На проекте сложного обновления 1С:ERP 2.4.14.181 до версии 2.5.22.106 нам было нужно уложить обновление в технологическое окно 48 часов (выходные). Исходный замер, с учетом промежуточных релизов 2.5.8.443, 2.5.12.270, 2.5.17.234, 2.5.22.106, показал требуемое время в 659 часов…
Обновление ролей в расширении 1С отличается от аналогичного процесса в основной конфигурации. Ситуация осложняется, когда доработки вносятся не в «обычное», а в поставляемое расширение.
Внешняя обработка для проверки методов расширений с директивами &Вместо, &Перед, &После и &ИзменениеИКонтроль после обновления типовой конфигурации.
Обработка анализирует файловые выгрузки старой и новой конфигурации, автоматически определяет изменившиеся типовые методы и формирует список методов расширения, требующих проверки.
Релиз в 1С может быть технически правильным, но все равно закончиться потоком обращений: пользователи не поняли, что изменилось, не нашли кнопку, не смогли провести документ или начали искать инструкцию уже после обновления. В статье — практический маршрут подготовки пользователей, поддержки и ключевых участников процесса к релизу: что объяснить, кого предупредить, как оформить инструкцию, как снизить хаос в первые часы и почему плохая коммуникация быстро превращается в деньги компании
Делюсь практикой переноса доработок при обновлении 1С:КА с 2.5.22 на 2.5.27 с помощью Claude, подключённого к конфигурации в EDT через MCP. Что у ИИ получилось хорошо, где он бессилен, что он осознанно отказался переносить — и какой главный вывод я сделал для следующего раза.
Релиз 1С часто превращается в ночной аврал: задачи собираются из переписок, внешние обработки забывают проверить, пользователи тестируют “как получится”, а после обновления команда тушит пожары. Разбираем минимальный релизный процесс для 1С-команды: состав релиза, роли, чек-листы, smoke-проверки, коммуникацию с пользователями и разбор ошибок после выпуска.
Когда доработанную 1С не обновляли годами, начинать приходится не с переноса кода, а с разбора того, что вообще накопилось в базе. Там могут быть десятки обработок, расширения, правки типовых объектов, а документации либо нет, либо она давно не актуальна. На примере реального обновления разбираем, как кодовые агенты, MCP-серверы и языковые модели помогают навести порядок в доработках, собрать план миграции, понять, где при переносе будут проблемы, и автоматизировать часть исправлений.
ВАЖНО! Обновление предназначено для технических специалистов!
Поддержка формата обмена V2 в локальном модуле ЧЗ.
Поддержка формата обмена V2 в модуле ПиоТ.
Поддержка многих видов маркируемой продукции.
