На тестовой работало, на рабочей база встала: фиксируем окружение 1С

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

Почему возникает расхождение между тестовой и рабочей базой 1С 🧩

Пятница, 17:40. Разработчик выкладывает правку в подбор скидок. У него всё считается, на тестовой базе тоже. Через десять минут менеджеры пишут в чат: реализации не проводятся. Вечер уходит на откат, причину находят в понедельник. Тестовую базу снимали с рабочей полгода назад, до того как подрядчик поставил расширение с тем же обработчиком записи, а платформа на тестовом сервере новее рабочей на пару релизов. Правку проверили, но не там, где она работает.

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

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

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

Что входит в окружение 1С и как его зафиксировать

Фиксировать окружение значит хранить его так, чтобы его можно было собрать, а не прочитать. Разница видна на каждом слое.

Связку платформы, ОС и СУБД сверяйте с системными требованиями 1С при каждом обновлении любого из компонентов: описание о выходе из поддерживаемой связки не предупредит.

Чем крупнее система, тем дороже расхождение. При внедрении 1С:ERP расширений и обменов с внешними системами больше, и вручную сверить контуры не получится: нужен скрипт.

Как исправить: собираем воспроизводимую линию в шесть шагов 🔧

Порядок не зависит от размера базы. Начинайте с первого шага и не перескакивайте.

1. ✓Выгрузите конфигурацию и каждое расширение в файлы и положите в Git-репозиторий. Это делается из Конфигуратора командой пакетного режима или в 1С:Enterprise Development Tools. Выгружайте то, что работает на рабочем сервере сейчас, а не то, что лежит у разработчика.
2. ✓Запишите точный номер сборки платформы в файл репозитория и ставьте её на все контуры из одного дистрибутива.
3. ✓Вынесите настройки базы в скрипт: константы, функциональные опции, роли, тестовых пользователей. Скрипт запускается после загрузки копии и приводит базу в рабочее состояние.
4. ✓Добавьте в тот же скрипт отключение исходящих обменов: почтовые учётные записи, рассылки, адреса веб-сервисов контрагентов. Туда же поставьте обезличивание. Копия рабочей базы остаётся обработкой персональных данных по 152-ФЗ, а тестировщику паспортные данные сотрудников и контрагентов не нужны.
5. ✓Напишите скрипт сборки: он поднимает пустую базу, загружает снимок, применяет конфигурацию и расширения из репозитория и запускает скрипт настройки. Прогоните его на чистой машине. Если с первого раза не вышло, в окружении есть то, что нигде не записано, и вы только что это нашли.
6. ✓Выкладывайте на рабочую базу только то, что собрано этим скриптом, из репозитория и с меткой версии. Метка нужна и для отката: вернуть вчерашнее состояние значит собрать вчерашнюю метку.

С чего начать, если репозитория нет

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

Как сверить рабочую базу с репозиторием

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

Что делать, если ошибка повторяется 🔁

Если после исправления ошибка вернулась, поправили симптом, а разошедшийся слой остался. Проверяйте по порядку.

1. ✓Номер сборки платформы на сервере, где ошибка есть, и на контуре, где её не удалось воспроизвести. Если номера разные, дальше можно не искать.
2. ✓Список расширений и их версии на рабочей базе против репозитория. Лишнее или недостающее расширение хорошо объясняет фразу «у меня не падает».
3. ✓Настройки базы: константы, функциональные опции, регламентные задания.
4. ✓Журнал регистрации рабочей базы. Он показывает, когда и под каким пользователем менялась конфигурация. Если запись есть, а коммита в репозитории нет, источник расхождения найден.

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

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

Как предотвратить расхождение окружений 🛡️

Дрейф возвращается без дисциплины даже при хорошем скрипте сборки. Четыре правила держат его в границах.

• ✓Конфигуратор рабочей базы закрыт для правок. Изменения попадают туда выкладкой из репозитория, а право менять конфигурацию остаётся у одного ответственного.
• ✓Платформа и релиз конфигурации обновляются в одном порядке: тестовый контур, затем рабочий, на одной сборке. Если вы откладываете обновление 1С, запишите номер релиза, на котором стоите, и причину отсрочки.
• ✓Тестовая копия пересоздаётся по расписанию, например после закрытия каждого месяца, а не когда о ней вспомнят.
• ✓Новое расширение или обмен от подрядчика принимают, только если они лежат в репозитории и собираются скриптом. Раз в квартал скрипт сверяет рабочую базу с репозиторием и присылает список расхождений.

Сколько стоит настройка линии и как это делаем мы 💬

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

Работы считаем по часам: сопровождение 1С и системное администрирование стоят 3800 руб/час. Сколько часов уйдёт, зависит от числа расширений и обменов и от того, насколько рабочая база ушла от типовой. Оценку называем до начала работ, после просмотра конфигурации и списка расширений.

Тестовые контуры можно держать на вашем сервере или на арендованном: сервер 1С стоит от 1 100 ₽/мес за пользователя. Рабочая и тестовая базы при этом остаются на одной сборке платформы, а доступ к копии с настоящими данными ограничен.

Доработки, которые мы пишем, идут через ту же линию: доработка 1С попадает на рабочую базу только из репозитория, с меткой версии и планом отката. Если система только запускается, линию проще заложить на старте как часть внедрения 1С, чем разбирать расхождения через год.

❓ Частые вопросы

Что такое воспроизводимая линия разработки на 1С?

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

Почему описание окружения 1С не работает?

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

Сколько стоит настроить линию разработки 1С?

Работы считаем по часам: сопровождение 1С и системное администрирование стоят 3800 руб/час. Количество часов зависит от числа расширений, обменов и от того, насколько рабочая база ушла от типовой. Точную оценку даём после просмотра конфигурации и списка расширений, до начала работ, чтобы вы заранее знали порядок затрат.

Можно ли держать тестовый контур 1С на арендованном сервере?

Можно. Тестовый и рабочий контуры должны стоять на одной сборке платформы, а железо может быть разным. Арендованный сервер 1С стоит от 1 100 ₽/мес за пользователя. Тестовую копию обезличивают при развёртывании: с настоящими ФИО и паспортными данными она остаётся обработкой персональных данных по 152-ФЗ.

Что делать, если ошибка воспроизводится только на рабочей базе?

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