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

Почему выбор схемы работы с хранилищем важен

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

Подход 1. Работа с одним хранилищем

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

Рис. 1. Схема работы с одним хранилищем

В упрощенном виде процесс выглядит так:

1. Разработчик обновляет свою базу разработки из хранилища.
2. Вносит изменения, моделирует необходимые ситуации и работает с кодом в своей базе.
3. Тестирует доработку на базе разработки.
4. После завершения работы помещает изменения в хранилище.
5. Из хранилища изменения переносятся в продуктивный контур - напрямую в рабочую базу или через предпродуктовую базу, если она предусмотрена процессом.

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

Подход 2. Разделение на хранилище разработки и хранилище продуктивного контура

Во второй схеме процесс разделен на два контура. В контуре разработки используются базы разработчиков, хранилище разработки и предпродуктовая база. Отдельно существует контур внедрения -с базами переноса, хранилищем продуктивного контура и рабочей базой.

Рис. 2. Схема работы с двумя хранилищами

В этом случае последовательность действий расширяется:

1. Разработчик обновляет базу разработки из хранилища разработки.
2. Вносит изменения в своей базе и моделирует необходимые ситуации.
3. Тестирует доработку на базе разработки.
4. После завершения очередного этапа помещает изменения в хранилище разработки.
5. Из хранилища разработки изменения попадают в предпродуктовый контур и тестируются на данных, приближенных к данным рабочей базы.
6. После успешного тестирования разработчик получает задачу на перенос изменений в контур внедрения.
7. Для переноса он обновляет отдельную базу переноса из хранилища продуктивного контура.
8. Переносит в эту базу свои изменения и помещает их в хранилище продуктивного контура.
9. Из хранилища продуктивного контура доработки переносятся в рабочую базу. При необходимости перед этим может выполняться дополнительная проверка на отдельной базе, подключенной к тому же хранилищу, чтобы проверить целостность переноса.

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

Какие риски возникают при работе с одним хранилищем

Незавершенные изменения требуют особенно внимательного контроля

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

Ошибка в одной доработке может повлиять на выпуск всего набора изменений

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

Какие ограничения появляются при работе с двумя хранилищами

Перенос между контурами становится отдельной задачей

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

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

Параллельные изменения в одном модуле усложняют слияние

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

Нужно сохранять синхронность хранилищ

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

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

Одно или два хранилища: ключевые различия

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

	Одно хранилище	Два хранилища
Функции разработчика	Разработка кода	Разработка кода; перенос кода в хранилище продуктивного контура
Когда доработка   помещается в   хранилище	Когда функциональность готова к внедрению	Когда разработана отдельная атомарная функция; далее изменения переносятся между контурами
Релиз	Релиз отдельных доработок; при подготовке релиза может потребоваться остановить помещение новых изменений в хранилище	Релиз пакетами доработок
Тестирование	До помещения в хранилище -на базе разработчика; после помещения -на базе, приближенной к рабочей, для проверки функциональности	До помещения в хранилище разработки -на базе разработчика; после помещения в хранилище разработки -на базе, приближенной к рабочей; после помещения в хранилище продуктивного контура -дополнительная проверка целостности на базе, приближенной к рабочей

Как выбрать подход для проекта

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

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

Статья была полезной?

Еще больше новостей в нашем Telegram-канале t.me/dialog_it - анонс вебинаров, бизнес-новости, лайфхаки по 1С 

Для того, чтобы купить, установить, настроить программы и сервисы 1С, а также по всем вопросам позвоните нам по номеру +7 (812) 317-00-07 или напишите it@dialogit.ru