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

Итак, допустим, у нас есть команда из нескольких разработчиков, и некая «кучка» проектов в разработке, давайте представим, как в реальности будет происходить разработка в подобной ситуации:

Вариант А
Непосредственная разработка или «по-живому».

Решение довольно простое, но сразу скажу — крайне не рекомендуемое. Применять такой вид разработки можно только когда разработчиков мало (в идеале один) и/или разработка носит «разовый» характер (да и в этом случае лучше использовать вариант Б).
У каждого из разработчиков имеется «своя» отладочная ИБ в которой они независимо ведут разработку. Ну и есть рабочая ИБ в которой работают пользователи и в которую разработчики независимо и самостоятельно вносят изменения.
Плюсов у такого решения ровно один и довольно незначительный — относительная простота, а вот минусов множество и они, на мой взгляд, перевешивают.
Минусы:
— нет контроля разработки, т.е. мы не знаем кто и что в какой момент изменяет сейчас или изменял в прошлом (немного могут помочь в этом комментарии, но это довольно слабый контроль)
— нет контроля целостности изменений, т.е. мы не можем быть уверены в том, что пока один разработчик вносит изменения в какой-либо модуль, его уже не изменил другой
— нет истории изменений, мы не знаем как менялся код со временем (немного могут помочь бэкапы, но скорость такого «анализа» неприемлема)
— нет контроля результирующей разработки, т.к изменения внесённые одним разработчиком (а он тестирует свой вариант отладки), без учета разработок «соседей» могут просто-напросто сделать рабочую ИБ нерабочей.

Вариант Б
Использование хранилища конфигурации.

Типовое, предлагаемое 1С решение состоит в том, что в некоей общей области создается вспомогательная база данных, служащая агрегатором и хранилищем изменений. К этой базе (далее — хранилищу) подключаются конфигурации разработчиков, после чего изменения в подключенных конфигурациях синхронизируются с хранилищем. Схема известная и довольно распространённая в силу своей простоты. Есть варианты с использованием промежуточной «тестовой базы». Почти все минусы из варианта А тут устранены и превращены в плюсы. Из недостатков можно отметить необходимость в постоянном (и довольно требовательном) соединении с хранилищем «онлайн», так называемая «централизация», исходя из которой, требования к хранилищу в плане безопасности и отказоустойчивости повышены (поскольку в случае выхода его из строя разработка становится не возможна).
Плюсы
— контроль разработки, система сама следит кто, когда и какие изменения вносит или вносил в прошлом
— есть контроль целостности, это одновременно и плюс и минус, т.к система не позволит одновременно редактировать один модуль нескольким разработчикам.
— история разработки, ведется подробная история с возможностью анализа и «отката» на любую точку в истории
— целостность результирующего кода, система следит за тем, чтобы отладочные базы разработчиков были в актуальном состоянии
Минусы
— требуется подключение к хранилищу (каналы связи)
— нет возможности одновременной работы над одним модулем/объектом
— повышенные требования безопасности к центральному узлу

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

Усложненный вариант Б, применяющийся в относительно больших и удалённых командах, из плюсов — для разработки не требуется постоянного «онлайн» соединения с удаленным хранилищем, т.к. изменения можно «накапливать» локально и синхронизировать с ИБ разработки по мере возможности и необходимости. К плюсам также можно отнести и некую «централизацию разработки» в итоговом хранилище, которую в идеале осуществляет один ответственный разработчик-администратор (некий код-ревью в ИБ разработки). А к минусам — сложность по сравнению с предыдущими вариантами и дополнительные временные затраты (инертность разработки) на синхронизацию отладочных ИБ и «спускание» изменений в центральное хранилище. Ну и поскольку централизация никуда не делать, то требования к безопасности и отказоустойчивости главного хранилища по прежнему высоки.

Вариант Г
Разработки с использованием GIT.

Подводя итог, можно сказать что, по своей сути вариант Б — это централизованная система контроля версий (СКВ), а вариант В — наполовину децентрализованная СКВ (вариант А можно даже не рассматривать как СКВ, т.к никакого контроля там нет). Минусы централизации очевидны — это уязвимость «центральной системы», в случае сбоев или отсутствия связи с которой останавливается вся разработка. Как бы мы далее не усложняли или не видоизменяли СКВ, тот факт что она базируется на хранилище, не даст нам избавиться от всех минусов централизованной СКВ. Поэтому остается только :
Вариант Г — использование децентрализованной СКВ, такой как GIT, обладает всеми плюсами предыдущих вариантов, при этом не имея их минусов, при этом он менее сложный по своей структуре и способам реализации. Минусами можно считать использование дополнительного программного обеспечения и необходимость обучения работе с этим ПО.
К счастью, 1С уже давно выпустила и активно поддерживает среду разработки нового поколения 1C:Enterprise Development Tools (1C:EDT) в которую уже интегрированы средства для работы с GIT, которые делают командную разработку с использованием децентрализованной СКВ более удобными и комфортными.
Плюсы:
— все плюсы предыдущих вариантов
— не требует постоянного подключения онлайн
— полная копия (клон) всех изменений и истории изменений (в случае выхода из строя любого из узлов, данные по разработке не потеряются)
— возможность соединения с несколькими СКВ одновременно в рамках единого подхода к разработке
— гибкая настройка разработки, версионирования и жизненного цикла разработки
Минусы:
— дополнительное ПО и обучение работе с ним

Это в общих чертах все наиболее распространенные способы командной разработки. Какой вариант использовать в каждом конкретном случае — зависит от множества факторов. Вариант А, как и было сказано выше, лучше не использовать никогда. Вариант Б — подходит для небольших команд и/или для небольшого объема разработки. Вариант В — напротив, в случае больших, распределённых команд, там, где требуется администрирование разработки, при этом вариант Г там трудно реализуем.
Ну и вариант Г — на мой взгляд оптимален, как для небольшого числа разработчиков (даже для 1го), так и для огромных и разветвленных команд. Но для того, чтобы полностью использовать его преимущества, потребуется, правильная организация и настройка жизненного цикла приложения и структуры СКВ. О том как это сделать и поговорим в дальнейших статьях.