← На главную

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

Решение 1: Схема с несколькими хранилищами

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

1. Хранилище разработки (dev). Это основное хранилище, к которому подключены базы всех разработчиков. Сюда помещаются абсолютно все изменения, включая "полуфабрикаты", отладочный код и функционал, который прошел только первичную проверку автором. Это "песочница", где код может быть нестабильным.
2. Хранилище тестирования (test/QA). Когда разработчик завершает свою задачу, ответственный сотрудник (обычно ведущий разработчик или руководитель проекта) выборочно переносит готовые изменения из хранилища dev в хранилище test. Чаще всего это делается через выгрузку конфигурации в файл (.cf) и последующую загрузку с объединением. К базе, подключенной к этому хранилищу, получают доступ тестировщики и ключевые пользователи. Это изолированная среда для проверки функционала перед выпуском.
3. Хранилище продуктивное (prod/release). После того как изменения успешно прошли все этапы тестирования в среде test, они таким же образом переносятся в "чистовое" хранилище prod. Рабочая база обновляется только из этого хранилища. Такой подход гарантирует, что в продуктивную среду попадает исключительно оттестированный и одобренный функционал.

Преимущества:

• Высокая надежность: в рабочую базу не попадет случайный или недоделанный код.
• Четкое разделение зон ответственности: разработчики работают в dev, тестировщики в test.

Недостатки:

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

Решение 2: Использование расширений и "флагов функциональности"

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

Разработка в расширениях:

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

1. Основная конфигурация остается типовой или минимально измененной. Ее можно спокойно обновлять.
2. Каждая крупная доработка или набор связанных задач реализуется в своем расширении.
3. Тестирование проводится путем подключения нужной версии расширения к тестовой базе.
4. Когда тестирование завершено, расширение просто устанавливается в рабочую базу. Непротестированный функционал остается в других расширениях и никак не влияет на работу системы.

"Флаги функциональности" (Feature Toggles):

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

• Константы (например, ИспользоватьНовыйМеханизмРасчетаСебестоимости).
• Настройки в специальном регистре сведений или справочнике.
• Функциональные опции, связанные с правами пользователей.

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

Решение 3: Процесс с выделенной ролью "Интегратора"

Этот подход больше про организацию процесса, чем про технические средства. Он хорошо работает в небольших командах.

Схема работы выглядит так:

1. Рабочая база не подключена к хранилищу напрямую.
2. Есть общее хранилище для всех разработчиков. В него принято помещать только тот функционал, который разработчик сам проверил и считает завершенным (то есть, не "полуфабрикаты").
3. Тестировщик работает в своей базе, получая обновления из общего хранилища.
4. Если тестирование прошло успешно, тестировщик маркирует версию в хранилище (например, в комментарии к версии) и передает номер этой версии специальному человеку — "интегратору" или "накатывателю".
5. Только этот человек имеет право обновлять рабочую базу. Он берет указанную протестированную версию, сохраняет .cf и устанавливает обновление на "продакшн", а также закрывает соответствующие задачи в системе трекинга.

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

Решение 4: Продвинутый подход — Git и методология GitFlow

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

Ключевая идея — ветвление (branching). Процесс строится по схеме GitFlow (или ее упрощенным аналогам):

• Ветка `master` (или `main`): Содержит код, который находится в рабочей базе. В нее попадают только полностью протестированные и готовые к выпуску изменения.
• Ветка `develop`: Основная ветка разработки. В нее сливаются все готовые доработки. Ночные сборки и сборки для тестировщиков делаются из этой ветки.
• Ветки задач (`feature/имя-задачи`): Под каждую новую задачу создается отдельная ветка от `develop`. Разработчик работает изолированно в своей ветке, не мешая другим.

Как это решает проблему "зависших" задач?

Очень просто. Задача, которая ушла на долгое тестирование, просто "живет" в своей feature-ветке. Она не сливается в `develop` до тех пор, пока не будет полностью одобрена. В это же время другие, более срочные задачи, разрабатываются в своих ветках, проходят ревью, сливаются в `develop` и уходят в релиз. Изоляция веток — главное преимущество Git.

Когда задача готова, создается Pull Request (Запрос на слияние) — это формальный запрос на вливание изменений из ветки задачи в ветку `develop`. Это точка для обязательного code review (проверки кода другим разработчиком) и запуска автоматических тестов (с помощью инструментов вроде Vanessa Automation), что повышает качество кода.

Итог:

Выбор метода зависит от размера команды, сложности проекта и готовности осваивать новые инструменты. Для небольших проектов отлично подойдут схемы с несколькими хранилищами или выделенным интегратором. Для крупных и долгосрочных проектов, где важна гибкость, параллельная работа и высокое качество кода, переход на Git и DevOps-практики является стратегически верным решением.