Вопрос выбора базы для разработки — пустая или наполненная данными — является фундаментальным для любого 1С-программиста. От этого решения зависят скорость отладки, качество кода и удобство коллективной работы. В данной статье мы проанализируем накопленный опыт профессионального сообщества, разберем различные сценарии использования Хранилища конфигурации и рассмотрим современные инструменты автоматизации процесса разработки.
Разберем три основных подхода к наполнению баз данных, которые используют разработчики в зависимости от сложности задач.
Для надежной работы команды необходимо разделение сред. Рассмотрим классическую схему организации контуров:
Контур разработки (Dev): У каждого разработчика должна быть своя личная база. Это позволяет проводить эксперименты, не мешая коллегам. Личная база каждого программиста подключается к общему Хранилищу конфигурации.
Контур тестирования (Test/QA): Отдельная база, в которую изменения попадают только после помещения их в Хранилище. Здесь аналитики или тестировщики проверяют работоспособность задачи на «чистых» данных или свежей копии «прод-базы».
Рабочий контур (Production): Живая база предприятия. Крайне не рекомендуется подключать рабочую базу напрямую к Хранилищу конфигурации разработчиков. Обновление продуктивной базы лучше производить через файлы поставки (.cf) или отдельное «релизное» хранилище.
Выясним причины, по которым работа с Хранилищем часто вызывает трудности, и как их избежать. Главное правило: никогда не используйте файловое хранилище через общие сетевые папки. Это ведет к повреждению базы данных хранилища и крайне низкой скорости работы.
Рекомендуемые настройки Хранилища:
crserver.exe).tcp://.Для интеграции с системами учета задач (например, Jira), можно использовать скрипты, которые запрещают помещение изменений без указания номера задачи. Посмотрим на пример структуры комментария при помещении в хранилище:
// НомерЗадачи: #12345
// СутьИзменений: Добавлена проверка заполнения реквизита "Склад" в документе "Реализация".
// Разработчик: Иванов И.И.
Проанализируем ситуацию, когда несколько разработчиков одновременно работают над одной подсистемой. Основная проблема Хранилища 1С — блокировка объекта при захвате одним пользователем. Если объект (например, модуль общего назначения) захвачен на неделю, работа всей команды может встать.
Методы решения конфликтов:
Расширения конфигурации для изоляции правок по конкретным задачам. Это позволяет вести разработку, не захватывая основные объекты в Хранилище.Разберем переход от классического Хранилища к более мощным инструментам, таким как Enterprise Development Tool (EDT) и Git. Это позволяет использовать механизм веток (branches). Каждый разработчик создает свою ветку под задачу, вносит изменения и делает Merge Request. В этом случае вопрос «пустая или полная база» решается автоматически: под каждую ветку можно быстро развернуть временную базу с помощью скриптов автоматизации.
Проанализируем преимущества связки 1С + Git:
CI/CD (например, GitLab CI или Jenkins) может автоматически запускать дымовые тесты на пустой базе.SonarQube позволяет автоматически находить ошибки в коде еще до начала тестирования.Если мы выбираем путь разработки в «пустых» базах, нам необходим инструмент для быстрого наполнения их данными. Рассмотрим Vanessa Automation. Этот инструмент позволяет описывать сценарии создания данных на языке Gherkin. Например:
Сценарий: Создание тестового контрагента и договора
Дано: Я открываю форму списка справочника "Контрагенты"
И: Я нажимаю кнопку "Создать"
Тогда: Я заполняю поле "Наименование" значением "Тестовый Поставщик"
И: Я нажимаю кнопку "Записать и закрыть"
Такой подход позволяет разработчику работать в легкой пустой базе, а все необходимые для теста данные генерировать программно за несколько секунд.
Выяснив все плюсы и минусы, сформируем итоговый чек-лист для организации среды разработки:
Хранилище конфигурации через tcp.EDT и Git. Разработка в легких базах с использованием скриптов для генерации тестовых данных.обезличивания данных при работе с копиями рабочих баз.Хранилище или Git. Вся история изменений должна храниться в системе контроля версий.Помните, что время, затраченное на настройку качественной среды разработки, окупается многократно за счет снижения количества ошибок и ускорения процесса выпуска обновлений.