При сопровождении любой системы 1С неизбежно возникает вопрос: как организовать работу разработчиков, чтобы они могли эффективно создавать новый функционал и исправлять ошибки, но при этом не подвергать риску стабильность основной, "боевой" базы данных, в которой работают пользователи? Прямой доступ к конфигуратору продуктивной базы — это почти всегда плохая идея, которая может привести к потере данных и остановке бизнес-процессов. Давайте вместе разберем проверенные и надежные подходы к организации этого процесса, от самых простых до применяемых в крупных компаниях.
Это самый распространенный и сбалансированный подход, который является отраслевым стандартом. Его суть заключается в полном разделении сред, в которых ведется работа. Рассмотрим этот процесс по шагам.
Контур разработки (Development). Это "песочница" для программистов. У каждого разработчика есть своя локальная или серверная копия базы, подключенная к общему хранилищу конфигурации 1С. Здесь они пишут код, создают новые объекты и отлаживают свои доработки, не мешая друг другу и не затрагивая работающую систему.
Контур тестирования (Test/QA). Это промежуточное звено. На отдельном сервере разворачивается база, которая является недавней копией продуктивной базы. В эту базу по определенному графику (например, раз в день или перед релизом) собираются все изменения из хранилища разработки. К этому контуру получают доступ аналитики, ключевые пользователи или тестировщики. Их задача — проверить, что новый функционал работает корректно, а старый не сломался. Никакие изменения в конфигурацию на этом этапе уже не вносятся. Если найдены ошибки, задача возвращается разработчику для исправления в контуре разработки.
Продуктивный контур (Production). Это та самая "боевая" база, с которой работают пользователи. Доступ к ее конфигуратору для разработчиков должен быть полностью закрыт. Обновление этой базы происходит только после того, как все изменения успешно прошли тестирование на предыдущем этапе. Сам процесс обновления выполняет строго ограниченный круг лиц (руководитель отдела, старший разработчик или системный администратор).
Важный момент: для внесения изменений в продуктивную базу выделяется специальное "технологическое окно". Обычно это нерабочее время (например, вечер или выходные), когда активность пользователей минимальна. Все сотрудники заранее оповещаются о предстоящих работах. Это позволяет спокойно обновить конфигурацию и, в случае возникновения проблем, быстро откатиться на резервную копию, не парализуя работу всей компании.
Классическую схему можно значительно улучшить и автоматизировать, особенно в больших командах. Этот подход требует более высокой технической культуры, но дает огромный прирост в скорости и надежности разработки.
Системы контроля версий (Git). Вместо стандартного хранилища 1С или в дополнение к нему все чаще используют Git. Это позволяет организовать более гибкую параллельную разработку в отдельных ветках, проводить код-ревью (проверку кода другими членами команды) и легко интегрироваться с системами автоматизации.
Автоматизация (CI/CD). Это практика непрерывной интеграции и доставки. Процесс выглядит так:
.cf), выполняет синтаксическую проверку и прогоняет автоматические тесты ("дымовые тесты").Такой подход минимизирует человеческий фактор и позволяет выявлять ошибки на самых ранних стадиях.
Работа со срочными исправлениями (Hotfix). Что делать, если в рабочей базе найдена критическая ошибка, которую нужно исправить "прямо сейчас", не дожидаясь планового релиза? Для этого идеально подходит механизм Расширений конфигурации.
Разработчик создает расширение, которое содержит только минимально необходимое исправление ошибки, не затрагивая основную конфигурацию. Это расширение проходит ускоренное тестирование и устанавливается в продуктивную базу. Это быстрый и относительно безопасный способ "залатать дыру". Важно не забыть потом перенести это же исправление в основную ветку разработки, чтобы оно не потерялось при следующем большом обновлении.
Даже при наличии "технологического окна" простой в работе системы может быть критичным, особенно для компаний, работающих в режиме 24/7. Для таких случаев в платформе 1С:Предприятие существует механизм фонового обновления конфигурации. Разберем его этапы подробнее.
Этот процесс позволяет выполнить самую долгую и ресурсоемкую часть обновления — реструктуризацию таблиц базы данных — пока пользователи продолжают работать в системе. Монопольный режим потребуется лишь на очень короткое время в самом конце.
Фаза обработки. Это самый длительный этап. Он запускается администратором из конфигуратора или программно. В это время система начинает перестраивать структуру основных таблиц данных (справочников, документов, регистров). Пользователи могут продолжать работать в базе, а система будет накапливать все изменения, которые они вносят, в отдельных служебных таблицах.
Фаза актуализации. Запускается автоматически после завершения предыдущей фазы. Система короткими итерациями применяет изменения, накопленные во время работы пользователей, к новой структуре данных. Пользователи все еще могут работать в системе.
Фаза принятия изменений. Единственный этап, который требует монопольного доступа. Всех пользователей необходимо отключить от базы. Эта фаза обычно проходит очень быстро. Система выполняет финальную актуализацию данных, реструктурирует оставшиеся небольшие объекты и окончательно "переключает" базу на новую структуру конфигурации. После этого обновление завершено, и пользователи могут снова подключаться.
Использование фонового обновления позволяет сократить время полного простоя системы с нескольких часов до нескольких минут, что является критически важным для крупного бизнеса.
В заключение, выбор конкретного подхода зависит от размера компании, сложности конфигурации и количества разработчиков. Однако основной принцип остается неизменным: разработка и тестирование всегда должны проводиться на отдельных копиях, а доступ к продуктивной базе должен быть строго регламентирован и ограничен.
← К списку