Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу про переход на платформу 1С:Предприятие 8.5 на примере сценария, который стоит разобрать перед миграцией. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

Представьте: в пятницу вечером команда ставит на сервер 8.5.1, включает новый интерфейс и прогоняет автоматический конвертер форм.

В субботу два разработчика кликают по основным документам, и всё открывается.

В понедельник в 9:15 звонит склад, в 9:40 менеджеры, а ночная сборка в CI с утра горит красным.

Ниже — все исходные данные. Попробуйте найти причины до того, как прочитаете разбор.

Рис. 1. Переход «одним рубильником»: в пятницу выглядит просто, в понедельник проявляется на складе, у менеджеров и в CI

Почему это актуально. Версия 8.5.1 включает функциональность 8.3.27, а дальнейшие функциональные изменения идут уже в ветке 8.5: версий 8.3.28 не будет. Весной 2026 года опубликована тестовая версия 8.5.4, финальной пока нет. Переход становится практической задачей, а не темой на будущее.

Контекст. Сценарий собирательный, цифры в нём условные. Дистрибьютор с интернет‑магазином, конфигурация на базе типовой торговой, сильно доработанная, около 120 пользователей. Склад работает в форме подбора с 31 колонкой, менеджеры — в форме заказа, часть полей которой создаётся кодом. Сборка и дымовые тесты идут в GitLab CI через vanessa‑runner 2.x на Linux‑агенте.

План тимлида на выходные:

1. Пятница, 19:00: поставить 8.5.1 на сервер вместо 8.3.27.

2. В свойствах конфигурации выставить режим совместимости интерфейса «Версия 8.5».

3. Запустить конвертер в режиме «Проверка и конвертация» по всей конфигурации.

4. Суббота: двое разработчиков проверяют ключевые документы.

5. Понедельник: все 120 человек работают в новом интерфейсе.

Симптом 1. Ночная сборка упала на шаге запуска тестов:

vanessa-runner v2.6.0
КРИТИЧНАЯОШИБКА - {МенеджерКонфигуратора.os / Ошибка в строке: 1823 / Неопределена версия платформы!}

Симптом 2. В форме подбора на мониторе 1920 px раньше были видны все 31 колонки, теперь без прокрутки видно 14. По наблюдениям склада, подбор заказа занимает почти вдвое больше времени: люди постоянно прокручивают таблицу и открывают карточки товаров.

Симптом 3. В форме заказа у менеджеров, которые включили тёмную тему, подсветка просроченного срока превратилась в яркое жёлтое пятно, а часть полей выглядит «как из другой программы». Эти поля создаются кодом:

&НаСервере
Процедура ДобавитьПолеСрока(ГруппаРодитель)

	Поле = Элементы.Добавить("СрокОтгрузки", Тип("ПолеФормы"), ГруппаРодитель);
	Поле.Вид = ВидПоляФормы.ПолеВвода;
	Поле.ПутьКДанным = "Объект.СрокОтгрузки";
	Поле.Ширина = 12;
	Поле.ЦветФона = WebЦвета.СветлоЖелтый;   // подсветка просрочки
	Поле.ЦветТекста = Новый Цвет(0, 0, 0);
	Поле.Шрифт = Новый Шрифт("Arial", 8, Истина);

КонецПроцедуры

Вопрос. Найдите три технические причины симптомов и процессный фактор, который позволил им проявиться одновременно. Что правильно сделать в понедельник в 10:00?

• А. Платформа 8.5 ещё сырая: откатиться на 8.3.27 и вернуться к переходу после следующей стабильной версии.

• Б. Конвертер отработал не до конца: повторно прогнать «Проверку и конвертацию», доработать помеченные формы и снова выпустить всех в 8.5.

• В. Не хватило тестирования: вернуть всех в «Такси», неделю гонять ключевых пользователей на копии базы и потом повторить переход целиком.

• Г. Изменение выкатили без стенда и поэтапной проверки: оставить 8.5.1, вернуть «Такси», починить CI и включать новый интерфейс по рабочим местам.

Остановитесь на минуту.

Выберите вариант и сформулируйте для себя три причины. Если хотите сверить ход мысли с коллегами, напишите свой ответ в комментариях до того, как прочитаете разбор.

1. Вариант А звучит разумно: весной 2026 года часть внедренцев советовала держать 8.5 на тестовом контуре, а основную работу вести на 8.3. Но ни один из трёх симптомов не вызван ошибкой платформы. Зашитые в коде цвета после отката никуда не денутся, скрипты CI не научатся находить 8.5, а через полгода команда вернётся в ту же точку, только под давлением сроков.

2. Вариант Б приписывает конвертеру слишком широкую ответственность. У конвертера два режима: «Только проверка» находит проблемные места и выдаёт рекомендации, «Проверка и конвертация» вдобавок автоматически меняет часть свойств формы. Шрифты, размеры и отступы он поправит, но WebЦвета.СветлоЖелтый внутри процедуры не тронет, а до .gitlab-ci.yml вообще не дотянется. Разработчик «1С», переводивший внутреннюю систему, отмечал, что перевода «в одно действие» нет: даже в типовых решениях формы после конвертера дорабатывают вручную.

3. Вариант В наполовину верный, и этим опасен. Неделя тестов с кладовщиками поймала бы проблему с формой подбора. Но пользователи не видят состояние CI‑пайплайна, проблему с тёмной темой обнаружит только тот сценарий тестирования, в котором эта тема действительно используется, а «повторить переход целиком» воспроизводит ту же схему «всё и сразу». Такой план закрывает один симптом из трёх.

Правильный ответ — Г.

В e‑commerce 1С для меня учётное ядро: туда приходят заказы с сайта, оттуда уходят остатки и статусы оплат. Поэтому после любого релиза на той стороне я сначала развожу симптомы по причинам и только потом что‑то чиню. Карта этого инцидента показана на рис. 2.

Рис. 2. Карта инцидента: три технические причины существовали заранее, процессный фактор позволил им проявиться одновременно

Главное, что нужно вынести из схемы: технические причины друг от друга не зависят и появились не в выходные. Незафиксированная версия платформы в CI, тяжёлая форма и зашитые цвета копились задолго до миграции. Отсутствие поэтапной проверки просто позволило всем трём проявиться в одно утро.

Лог из условия взят из реальной истории. В мае 2026 года в репозитории v8runner завели issue № 188: в нём описано поведение vanessa‑runner v2.6.0 под Unix. Запуск падал с ошибкой «не определена версия платформы», при ручном указании 8.5 всё работало, а без него автопоиск по логам выбирал самую свежую 8.3.

Опаснее соседний сценарий: если 8.3 на агенте осталась, тесты могут молча пройти на старой версии и показать зелёный. Непосредственное исправление — зафиксировать версию платформы:

# Было: платформа ищется автоматически
vrunner vanessa --settings tools/vrunner.json

# Стало: версия зафиксирована и берётся из переменной окружения стенда
export V8_VERSION="8.5.1.XXXX"   # точный номер сборки с вашего стенда
vrunner vanessa --settings tools/vrunner.json --v8version "$V8_VERSION"

# Пример для vanessa-runner 2.x. В 3.0 команда называется vrunner test vanessa,
# а настройки переехали в autumn-properties.json — см. руководство по миграции.

Отсюда более общий вывод, и это уже моя позиция, а не факт из issue. Если версия платформы в CI не зафиксирована, то, скорее всего, не зафиксировано и остальное окружение:

• OneScript;

• vanessa‑runner;

• тестовые библиотеки;

• образ CI‑агента.

Значит, подобная зависимость может выстрелить снова.

Это не гипотетический риск: vanessa‑runner 3.0 несовместим с 2.x, и незафиксированная версия раннера однажды сломает пайплайн так же неожиданно, как незафиксированная платформа.

Здесь нет бага, изменились правила. Один из разработчиков, одним из первых проверивший 8.5 на чистых базах, отмечал, что формы в новом интерфейсе строятся по другому подходу и заметно увеличились в размерах, а сложные формы придётся переосмыслять. Форма с 31 колонкой — ровно такой случай.

Для этого в платформе предусмотрены переходные режимы совместимости «Такси. Разрешить Версия 8.5» и «Версия 8.5. Разрешить Такси». В понедельник в 10:00 я бы вернул конфигурацию в режим «Такси. Разрешить Версия 8.5». Это изменение свойства конфигурации и обычное обновление, а не откат платформы.

Есть важная деталь. В пользовательском режиме выбрать вариант интерфейса нельзя: поведение по умолчанию переопределяется параметрами запуска клиента, из конфигуратора или программно через НастройкиКлиентскогоПриложения. Поэтому после переключения я бы отдельно проверил, в каком интерфейсе реально запускаются рабочие места склада.

И главное решение по этой форме.

31 колонка — это уже не «форма немного некрасивая», а другая модель взаимодействия. 1С прямо допускает сценарий, когда форма требует существенных доработок: текущую форму оставляют для «Такси», а для 8.5 делают отдельную.

В этой ситуации я бы так и поступил: склад продолжает работать в старой форме, а новую проектирую вместе с двумя‑тремя кладовщиками. Заодно правки не заденут тех, кто остаётся в «Такси»: изменения общей формы увидят пользователи обоих интерфейсов.

Светло‑жёлтый фон с чёрным текстом хорошо смотрелся в «Такси». В тёмной теме тот же фон становится ярким пятном, а Arial 8 выбивается из новой типографики.

Тот же разработчик «1С» уточнял: если элементы формы создаются программно, код придётся переписать, а статическим формам правки в коде могут не понадобиться. Здесь я бы развёл два случая.

Поле известно на этапе проектирования. Его лучше сделать статическим и настроить условное оформление в конфигураторе. Код здесь не нужен.

Поле действительно обязано создаваться динамически. Тогда условное оформление тоже создаётся кодом, цвет берётся из элемента стиля конфигурации, а признак просрочки вычисляется отдельно.

Логику сравнения я выношу в функцию, которая доступна и на клиенте, и на сервере: при изменении даты не нужен серверный вызов ради одного Булево.

// Срок отгрузки — календарная дата: заказ просрочен со следующего дня,
// а не в 00:01 того же дня. Поэтому сравниваем по началу дня.
// ТекущийДеньСеанса — реквизит формы (Дата), заполняется на сервере
// с учётом часового пояса сеанса, чтобы не брать дату с компьютера клиента.

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)

	ТекущийДеньСеанса = НачалоДня(ТекущаяДатаСеанса());

	ДобавитьПолеСрока(Элементы.ГруппаШапка);
	ДобавитьОформлениеПросрочки();
	Просрочено = СрокПросрочен(Объект.СрокОтгрузки, ТекущийДеньСеанса);

КонецПроцедуры

&НаСервере
Процедура ДобавитьПолеСрока(ГруппаРодитель)

	// Только структура: ширину, шрифт и цвета определяют правила интерфейса
	Поле = Элементы.Добавить("СрокОтгрузки", Тип("ПолеФормы"), ГруппаРодитель);
	Поле.Вид = ВидПоляФормы.ПолеВвода;
	Поле.ПутьКДанным = "Объект.СрокОтгрузки";
	Поле.УстановитьДействие("ПриИзменении", "Подключаемый_СрокОтгрузкиПриИзменении");

КонецПроцедуры

&НаСервере
Процедура ДобавитьОформлениеПросрочки()

	ЭлементОформления = УсловноеОформление.Элементы.Добавить();

	// Цвет — из собственного элемента стиля конфигурации, а не RGB
	ЭлементОформления.Оформление.УстановитьЗначениеПараметра("ЦветТекста",
		ЦветаСтиля.ЦветПросроченногоСрока);

	Отбор = ЭлементОформления.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
	Отбор.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Просрочено"); // реквизит формы, Булево
	Отбор.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
	Отбор.ПравоеЗначение = Истина;

	ОформляемоеПоле = ЭлементОформления.Поля.Элементы.Добавить();
	ОформляемоеПоле.Поле = Новый ПолеКомпоновкиДанных("СрокОтгрузки");

КонецПроцедуры

&НаКлиенте
Процедура Подключаемый_СрокОтгрузкиПриИзменении(Элемент)

	// Без серверного вызова: все данные уже на клиенте
	Просрочено = СрокПросрочен(Объект.СрокОтгрузки, ТекущийДеньСеанса);

КонецПроцедуры

&НаКлиентеНаСервереБезКонтекста
Функция СрокПросрочен(СрокОтгрузки, ТекущийДень)

	Возврат ЗначениеЗаполнено(СрокОтгрузки)
		И НачалоДня(СрокОтгрузки) < ТекущийДень;

КонецФункции

У такого подхода есть осознанное ограничение: если форму держат открытой через полночь, текущий день в ней не обновится до повторного открытия. Для формы заказа это приемлемо, для многочасового АРМ дату стоит периодически обновлять.

Вместо сорока разбросанных WebЦвета остаётся одна точка настройки — элемент стиля ЦветПросроченногоСрока. Но сам по себе элемент стиля читаемость не гарантирует: его цвет нужно подобрать и проверить так, чтобы он оставался контрастным во всех поддерживаемых интерфейсах и темах.

Один из полезных публичных кейсов — доклад Дениса Сытого о переводе на интерфейс 8.5 внутренней CRM «1С». Перед стартом он собрал ориентиры трудоёмкости у команд, которые адаптировали библиотеки и УНФ: от пары часов на простую форму списка до полутора‑трёх рабочих дней на сложный документ или АРМ. Он переводил только реально используемые формы, получил оценку около 80 часов и фактически уложился примерно в три недели. Формы БСП он сознательно не трогал, чтобы потом подтянуть обновление библиотеки.

Приложим этот порядок цифр к нашей задаче. Форма подбора и форма заказа — это несколько рабочих дней даже по оптимистичной оценке. А в плане тимлида на всю конфигурацию была одна суббота.

Практики, актуальные на момент подготовки статьи:

1. Разделите платформу и интерфейс. Сначала 8.5.1 в режиме «Такси», потом новый интерфейс. Так изолируются два класса изменений: совместимость платформы и адаптация под пользователей.

2. Начните с инфраструктуры. Production‑like стенд, зафиксированное окружение CI, скрипты развёртывания. На одной машине можно поднять несколько кластеров разных версий на разных портах.

3. Выберите методику. «1С» рекомендует дорабатывать постепенно: по рабочим местам, по самым используемым формам или по категориям пользователей.

4. Запускайте конвертер сначала в режиме «Только проверка». Так вы получите карту работ до того, как что‑то изменится.

5. Для тяжёлых форм рассмотрите отдельную форму под 8.5. Правка общей формы заденет и пользователей «Такси».

6. Не адаптируйте формы типовых библиотек вручную. Дождитесь их официальных обновлений.

7. Проверяйте по чек‑листу. Веб‑клиент в компактном и обычном режиме, светлая и тёмная темы, форма со всеми включёнными функциональными опциями, мобильный клиент и «Такси».

8. Заранее определите, когда пилот закончен. Пилотная группа небольшая, в неё входят представители каждой роли, которой касаются переведённые формы. Пилот завершается, когда пройден заранее утверждённый набор критичных сценариев и период наблюдения прошёл без превышения порогов по ошибкам и времени операций.

Интерфейс виден всем, поэтому вокруг него больше всего шума. Но для системы, которая обменивается данными с интернет‑магазином, перед выкаткой платформы я бы поставил ещё пять гейтов:

• окружение: стенд воспроизводит прод по версиям и критичным зависимостям — платформе, OneScript, vanessa‑runner и внешним компонентам, и всё это воспроизводимо устанавливается заново;

• интеграции: обмен с сайтом, платёжные сервисы, фоновые и регламентные задания;

• периферия: складское оборудование и печать;

• откат: свежий бэкап, проверенное восстановление и заранее записанные критерии отката — например, какие ошибки или какой рост времени операций считаются поводом вернуться;

• наблюдаемость: ошибки в журнале регистрации, технологический журнал и одна‑две бизнес‑метрики, например время подбора заказа до и после.

Как все шаги складываются в план, показано на рис. 3.

Рис. 3. План перехода в два трека с гейтом перед продом

Главная мысль схемы: трек интерфейса начинается только после того, как платформа прошла гейт и стабильно работает в проде в привычном «Такси».

Включение нового интерфейса для пилотной группы обратимо: пользователей можно вернуть в «Такси».

Сами изменения форм — это обычные изменения конфигурации, для них нужны контроль версий и отдельный план отката.

Не каждой базе нужен весь этот процесс. На форуме Инфостарта есть отзыв о переходе связки УНФ, БП и ЗУП, в том числе доработанной УНФ на удалённом сервере: проблем не заметили, база штатно работает уже три месяца.

Пять пользователей, одна бухгалтерия, нет CI и нет форм, которые строит код, — здесь процесс можно заметно сократить. Но проверенное восстановление и понятный план отката нужны и в этом случае: правило одно для любой базы, меняется только объём работы.

Два трека и полный набор гейтов я бы планировал, когда есть хотя бы одно из трёх: десятки пользователей в тяжёлых формах, автоматизированная сборка или интеграции, от которых зависит выручка.

Не знание того, где в конфигураторе лежит конвертер. Задача проверяла инженерное мышление при миграции: умение увидеть, что переход на 8.5 состоит из нескольких разных изменений, и развести их.

Если вы выбрали «Г» и назвали все три причины, вы рассуждаете как человек, который уже переживал такие понедельники. Если остановились на «В», вы были близко: одну причину вы увидели, но план по‑прежнему менял всё сразу.

Смена платформы, адаптация форм, окружение CI и перевод пользователей на новый интерфейс меняются с разной скоростью и имеют разные критерии готовности. Проблемы начинаются, когда их выкатывают как одно изменение. Хорошая миграция начинается с того, что эти изменения разделяют и для каждого заранее определяют, как понять, что оно готово и как его откатить.

Переход на новую версию платформы редко ломается из‑за одной ошибки. Чаще проблемы возникают там, где изменения кажутся небольшими: не зафиксировали окружение, не проверили критичные формы, не учли сценарии реальных пользователей.

На бесплатных уроках разберём практические инструменты и подходы, которые помогут повысить качество разработки:

• 29 сентября в 20:00. «Модульные тесты YaxUnit в связке с EDT». Записаться

• 22 октября в 20:00. «Оптимизация запросов 1С». Записаться

Полный список вебинаров сентября смотрите в дайджесте.