При работе в команде из нескольких разработчиков 1С часто возникает классическая проблема: общее хранилище конфигурации, каждый захватывает свои объекты, но процессы пересекаются. Проанализируем типичную ситуацию. Допустим, первый программист захватил общий модуль, внес в него объемные изменения, но сдача задачи затягивается. В этот момент второму программисту прилетает срочный багфикс, требующий правок в этом же самом модуле. Первому разработчику приходится "отпускать" объект, а затем мучительно восстанавливать свои недоделанные изменения и пытаться понять, какая именно дельта кода была изменена им, а какая — коллегой.
Рассмотрим подробнее, как решаются подобные проблемы в мире 1С. Разберем по шагам как классические инструменты, так и современные подходы с использованием систем контроля версий и CI/CD.
Если ваша команда использует стандартное Хранилище конфигурации 1С, технические ограничения можно нивелировать правильной архитектурой процесса. Посмотрим на основные правила, которые спасают от конфликтов блокировок.
Справочник1, помещается в хранилище, и корень отпускается. Далее разработчик спокойно захватывает только свой новый справочник и пишет в нем код, не мешая остальной команде обновлять метаданные.Разберем элегантный способ решения проблемы срочной задачи без необходимости дергать коллегу, захватившего основной модуль. В современных версиях платформы 1С для этого идеально подходят расширения.
Если второму программисту нужно срочно внести правки в захваченный объект, он вообще не трогает его в основной конфигурации. Вместо этого он создает расширение, заимствует нужный модуль или форму, и пишет свой код, используя аннотации &Вместо, &После или &Перед.
Это позволяет первому разработчику не прерывать свою работу и не отпускать объекты. Срочная задача сдается и переносится на продуктив в виде расширения. Позже, в спокойном режиме, код из расширения может быть аккуратно перенесен в основную конфигурацию, а само расширение удалено.
Чтобы не держать объекты в хранилище "захваченными" неделями (пока идет тестирование или согласование), крупные команды используют паттерн "Feature Toggles" (программные переключатели).
Суть метода заключается в том, что любой новый, даже недоделанный код, можно смело помещать в хранилище, если он физически отключен для пользователей. Для этого в код добавляется условие, проверяющее константу или параметр сеанса.
Посмотрим на пример реализации такого подхода:
// В общем модуле
Процедура ОбработатьДокумент(ДокументОбъект)
// Старый алгоритм
ВыполнитьСтарыйРасчет(ДокументОбъект);
// Новый алгоритм Пети, который еще в разработке
Если Константы.ИспользоватьНовыйАлгоритмРасчета.Получить() Тогда
ВыполнитьНовыйРасчетПети(ДокументОбъект);
КонецЕсли;
КонецПроцедуры
При таком подходе разработчик может каждый вечер сохранять свои изменения в общее хранилище. Его код физически присутствует в базе, но не исполняется на рабочих данных. Это полностью избавляет от необходимости блокировать модули на долгий срок.
Если команда разрослась (10 и более человек), стандартного хранилища становится недостаточно. Требуется переход на технологии, применяемые в "большом" программировании. Выясним причину: в обычных системах версионирования (таких как Git) разработчики отводят от основной ветки свою (branch), спокойно пишут код, а затем система помогает автоматически слить изменения (merge).
В экосистеме 1С для полноценной работы с Git используется 1C:Enterprise Development Tools (EDT). Разберем основные преимущества этого подхода:
// Задача №12345 Иванов И.И..Если команда не готова отказаться от привычного Конфигуратора в пользу EDT, можно использовать промежуточное решение — утилиту gitsync. Она позволяет синхронизировать историю из обычного Хранилища 1С в репозиторий Git в автоматическом режиме.
Проанализируем, как это помогает: разработчик работает в обычном Конфигураторе, но вся история коммитов зеркалируется в Git (например, в GitLab). Если нужно быстро посмотреть дельту кода за последний год или найти коммит, сломавший функционал, разработчик открывает веб-интерфейс GitLab и за секунды видит изменения, вместо того чтобы 40 минут ждать формирования отчета по истории в конфигураторе.
Совместная разработка в больших командах требует автоматизации контроля качества. Рассмотрим инструменты, которые выводят процесс на новый уровень:
Самая большая проблема параллельной разработки (особенно при использовании Git) — это объединение форм. Файлы форм представляют собой сложную XML-структуру, которую очень трудно "сливать" (мерджить) в автоматическом режиме.
Опытные команды используют простое правило: минимум изменений в визуальном редакторе форм. Если нужно добавить новую кнопку или поле, элементы создаются программно в обработчике ПриСозданииНаСервере. Текст модуля формы легко объединяется любыми системами версионирования, и это полностью исключает "поломку" XML-структуры самой формы при совместной разработке.
Подводя итог, можно сказать, что совместная разработка в 1С требует дисциплины. Для небольших команд достаточно грамотного использования Хранилища, файлов CF и расширений. Для крупных проектов с высокой интенсивностью правок неизбежен переход на Git, EDT, внедрение процессов код-ревью и автоматизированного тестирования.