150 способов коллективной разработки на 1с

[MuI_I_Ika]

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

Как разрабатывают без использования хранилища.

Берется конфигурация. Копируется на всех разработчиков. Каждый работает со своей базой. Разработчики на берегу договариваются кто какие объекты изменяет. По окончании работ все конфигурации объединяются.
Очевидные минусы такого подхода:

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

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

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

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

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

Использование хранилища. Рабочая конфигурация не подключена к хранилищу. Обновление боевой производится накатыванием cf файла. Боевая база находится на поддержке конфигурации хранилища.

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

Здесь уже соответственно процесс выкладывания изменений разработчиком отделен от процесса накатывания на боевую базу тем что еще нужно зарелизить cf файл. То есть, тестировщик (один человек, команда, или просто алгоритм) тестируют на стабильность готовую программу и уже по результатам создают cfник или не создают.

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

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

[TreeDogNight]

Используем 3й вариант, но без использования поддержки. Вручную перекидываем cf на сервер заказчику, и делаем Сравнение и объединение

[mixqn]

пользуемся вторым

[pumbae]

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

[MuI_I_Ika]

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

[pumbae]

вот это я бы назвал пятым вариантом

Да, согласен, т.к. тут еще добавляется релиз менеджмент, тестирование(корректность авто-merge, без тестирования очень трудно проверить), развертывание.