Переход на 1C:EDT (Enterprise Development Tools) открывает перед разработчиком множество преимуществ, таких как работа с Git, типизация и удобный интерфейс. Однако процесс обновления типового релиза в этой среде существенно отличается от привычного «Сравнить и объединить» в обычном Конфигураторе. Если вы только начинаете своё знакомство с 1C:EDT, вы можете столкнуться с тем, что после объединения все объекты помечаются «замками» (находятся на поддержке), даже если предварительно выполнялось их снятие. Разберем подробно, почему так происходит, и проанализируем наиболее эффективные методики обновления.
В традиционном Конфигураторе статус поддержки хранится непосредственно в базе данных. В 1C:EDT ситуация иная: информация о поддержке описывается в служебных XML-файлах проекта. Когда вы выполняете сравнение и объединение с новым .cf файлом или другим проектом, EDT считывает метаданные поставщика из источника. Если в импортируемом релизе содержатся сведения о поставщике, система возвращает объекты на поддержку. Это вынуждает разработчиков выполнять утомительное групповое изменение режима поддержки, чтобы вернуть возможность редактирования. Проанализируем способы решения этой проблемы.
Рассмотрим самый простой, но трудоемкий метод, который подходит для небольших проектов или при возникновении трудностей с инструментами EDT. Его суть заключается в подготовке «чистого» исходника.
.cf..cf в новый временный проект 1C:EDT.Для автоматизации снятия с поддержки можно использовать утилиту 1C:Enterprise Ring. Однако, как показывает практика, команда disableSupport не всегда корректно отрабатывает, если проект уже загружен в EDT. Рассмотрим пример правильной последовательности команд:
/ManageCfgSupport - disableSupport -force
Важно понимать, что если вы применяете это к .cf файлу, то после этого проект нужно заново импортировать в EDT, чтобы индексы и служебные файлы метаданных обновились. Если выполнить команду над уже существующим проектом, EDT может не сразу «подхватить» изменения в XML-структуре.
Это наиболее профессиональный и эффективный метод работы в 1C:EDT. Посмотрим на алгоритм действий, который используют опытные команды, применяя проверенные приемы быстрой работы в EDT и Git:
vendor (ветка поставщика).vendor до этого релиза.develop) и выполняем команду git merge vendor.В этом случае Git сравнивает текстовые файлы. Те объекты, которые вы не меняли, обновятся автоматически. В случае конфликтов EDT предоставит удобный трехсторонний редактор, в котором доступно объединение модулей в разрезе методов. Это гораздо быстрее, чем вручную прокликивать дерево метаданных.
В современных версиях 1C:EDT реализован штатный механизм обновления. Разберем, как им пользоваться:
.cf или .cfu.Важный нюанс: Перед запуском мастера убедитесь, что в edt.ini выделено достаточно оперативной памяти для Java, иначе процесс может прерваться на этапе анализа метаданных. Для контроля качества после обновления пригодится автоматическое регресс-тестирование бизнес-процессов.
Проанализируем ситуацию, когда обновление (например, для ERP или КА) длится слишком долго или завершается ошибкой. Чтобы минимизировать риски, после завершения слияния крайне важно выполнить анализ конфигурации на наличие ошибок и уделить особое внимание поиску «битых» запросов, которые могли возникнуть из-за изменения структуры метаданных поставщиком — для этого подойдёт архитектурный анализ конфигурации и проверка запросов.
Рассмотрим настройки, которые помогут ускорить процесс обновления тяжелых конфигураций:
edt.ini установите параметры -Xmx10G и -Xms4G.-XX:+UseG1GC.EDT может зависнуть из-за конкуренции потоков за доступ к файлам.Мы рассмотрели несколько подходов к обновлению конфигураций в 1C:EDT. Для разовых задач можно воспользоваться первым способом (через Конфигуратор), но для постоянной разработки наиболее правильным будет освоение методологии Git и использование веток поставщика — есть готовая автоматизация обновления баз и слияния через Git. Это избавит вас от проблем с «замками» и позволит полностью контролировать историю изменений каждого объекта метаданных.