Рассмотрим типовые примеры, которые используются в организациях:
- Один говорит – все слушают (линейный подход):
В самом простом случае один разработчик захватывает объект конфигурации, а остальные вынуждены ждать, пока этот объект освободится, иначе они не смогут внести изменений в этот объект. Делается это с той целью, чтобы не возникло конфликтов, когда два разработчика одновременно изменяют один и тот же объект конфигурации.
Естественно, это (захват объекта) может продолжаться достаточно долго, пока не завершится разработка, человек и того хуже, может уйти в отпуск, заболеть и забыть отпустить объект конфигурации, а время идет и задачу нужно решать. Если человек длительно отсутствует на рабочем месте, а объект все же нужен прямо сейчас, то выход один - отменять захват объекта администратором хранилища принудительно. В этом случае разработчик, захвативший объект, потеряет изменения, которые он вносил в объект. Мягко говоря, подход «так себе».
- Все говорят – все слушают (параллельный подход):
В более опытной команде разработчиков строится несколько иной подход, когда полностью чистая база данных подключается к хранилищу конфигурации и используется только для получения/помещения изменений, такая база используется только в режиме конфигуратора. Есть своим преимущества, более быстрая реструктуризация конфигурации БД в следствие отсутствия данных в таблицах БД, маленький объем самой базы. После получения изменений из хранилища все изменения сохраняется в файл конфигурации и уже сравнением/объединением (или полной загрузкой) конфигурации переносятся в свою тестовую копию базы с реальными данными, в которой как раз и ведется разработка. После завершения разработки конфигурация из тестовой БД снова сохраняется в файл и сравнением/объединением, с захватом объектов все переносится и помещается в основное хранилище конфигурации.
Преимущества такого подхода – никому не нужно ждать, пока захваченный объект в хранилище освободится, каждый разрабатывает свой функционал отдельно.
Недостатки – чем больше срок между получением файла хранилища конфигурации и переносом своих изменений обратно, тем больше различий в самом хранилище, которые туда уже поместили другие за время разработки, и тем сложнее переносить свои изменения в основное хранилище, особенно в тех местах где разработка пересекалась с другими коллегами в одних и тех же модулях, и объектах. Много галочек, много различий в объектах, изменилась сортировки и порою можно просидеть не один час реального времени, перенося все это, каждый объект нужно просмотреть и учесть всё, чтобы случайно не затереть помещенный ранее код коллег. Здесь принцип «кто успел, тот и съел», то есть кто поместил раньше тебя свои изменения в модуль, тому и проще, ведь это не ему придется сравнивать код двух модулей, объединять его в один и т.д. Если вспомнить, что бывают проекты по 2-3 месяца, то подобный подход при завершении проекта и переносе в основное хранилище покажется сущим адом.
Рассмотрим наиболее выгодный подход для разработчика при работе в крупной команде:
- Все говорят, но я никого не слушаю и делаю по-своему (параллельный подход с минимальным контролем).
Для более простого понимания принципа этой технологи, сначала я буду использовать надуманный пример, на основе не использующейся в реальной жизни конфигурации, код в конфигурации не будет нести какой-либо смысловой нагрузки – это будет просто «какой-то» текст, нам важно понять саму технологию, а не углубляться в понимание того, как правильно писать код или как решить ту или иную задачу с использованием тех или иных сущностей.
Имеем какую-то конфигурацию (собственную, отраслевую или от фирмы 1С не имеет значения).
В частном случае создана конфигурация из трех документов и одного общего модуля
Содержание общего модуля достаточно банальное
Для этой конфигурации создано хранилище.
Разработчик 1 будет в роли негодяя - напрямую подключился из своей тестовой базы к хранилищу и ведет разработку прямо там, мешая другим коллегам параллельно разрабатывать, захватывает объекты пока не закончит свою разработку.
Разработчик 2 устал постоянно ждать на захваченных объектах, начальник ругает, нужно делать работу, а не сидеть сложа руки. Он сохранил конфигурацию в файл и загрузил в свою тестовую базу. Ведет разработку там и не ждет Разработчика 1 или еще кого-либо. Позже перенесет свои наработки в хранилище пусть и с определёнными рисками.
Разработчик 3 пойдет по пути №2, но при этом не будет заботиться и переживать о контроле, он отдаст это механизмам 1С. Создаёт файл поставки от основного хранилища конфигурации. После чего этот файл поставки загружает в свою тестовую базу, поставив её на поддержку.
Если появится сообщением с вопросом, отвечаем положительно
Загрузив файл поставки в свою тестовую базу, видит, что все объекты находятся на поддержке или, как говорят, «на замке»:
На этом этапе технология разветвленной разработки (п. 4. Разработка технических проектов) гласит - Правило «Объект поставщика редактируется с сохранением поддержки» нужно устанавливать только для тех объектов, которые изменяются при выполнении технического проекта. Правило нужно менять как можно более точечно – например, если изменения в проекте будут затрагивать только форму, то нужно изменить правило только для этой формы, а для объекта, которому эта форма принадлежит, нужно оставить правило «Объект поставщика, не редактируется».
На самом деле это только Ваше дело, устанавливать правило «Объект поставщика редактируется с сохранением поддержки» точечно или сразу для всей конфигурации целиком. Методологически правильно делать как гласят стандарты, но это долго и, по моему мнению, избыточно, т.к. при разработке проекта часто меняется много объектов сразу. В тот момент, когда потребовалось в процессе разработки поменять, к примеру, общий модуль или модуль объекта, которые ещё на поддержке, нужно открывать окно поддержки конфигурации, пользоваться неудобным поиском, визуально находить нужный объект метаданных, менять свойство снимая с поддержки и т.д. в то время как в голове содержится информация по разработке, и она может вылететь из головы из-за того, что ты отвлекся на лишние действия. Я по своему опыту сразу устанавливаю для всей конфигурации целиком правило «Объект поставщика редактируется с сохранением поддержки», это позволяет мне не снимать точечно в том числе с поддержки те метаданные, которые я изменю в процессе разработки, но в хранилище конфигурации они «на замке» от основного поставщика конфигурации, там я как раз их сниму в процессе переноса и помещения в хранилище точечно, если уже потребуется!
Открываем настройку поддержки конфигурации
И включаем возможность изменения
Устанавливаем правила поддержки
И особо ни о чем не задумываясь начинаем разработку своего проекта или решение своих задач в тестовой базе.
Для примера мы поменяем общий модуль «ОбщийМодульДляВсегоВызовСервера» и «ДокументРазработчика3», добавим свой общий модуль и справочник.
Процедуру, которая имела вид
Мы преобразовали к такому:
В результате чего конфигурация принимает примерно такой вид:
Аналогично поступят Разработчик 1 и Разработчик 2, мы опустим этот момент, скажем лишь то, что Разработчик 1 без особых переживаний сделает это прямиком в хранилище конфигурации с захватом объектов, Разработчик 2 сохранит свой файл конфигурации и перенесет все сравнением/объединением, потратив какое-то количество времени на все это. И наступает наша очередь (мы самые последние) переносить свой проект в хранилище.
За время нашей разработки, открыв хранилище конфигурации, получив все объекты, мы видим, что конфигурация изрядно изменилась:
Но это нас не останавливает и даже не пугает, ведь мы на поддержке. Перед переносом всех изменений в основное хранилище Разработчик 3 повторяет процедуру создания файла поставки конфигурации от основного хранилища и обновляет свою тестовую базу.
Обновление базы из хранилища:
Видим следующую картину обновления
Невооруженным взглядом видно, что изменений достаточно много. Но мы все отдадим на откуп механизмам обновления 1С.
Снимаем отметку в корне конфигурации, тем самым сняв отметки со всех объектов метаданных
И устанавливаем фильтр в режим «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».
В данном режиме возвращаем отметку в корне конфигурации, отметив все объекты в этом режиме
И переключаем фильтр в режим «Показывать только дважды измененные свойства»
В данном режиме мы видим, что совместно с другими разработчиками мы изменяли только один общий модуль, объединение которого мы настроим вручную
В данном случае я вношу результирующие изменения, просто добавив их в конкретную процедуру
И на этом все! Если режим «Показывать только дважды измененные свойства» вообще не показал ничего, значит, мест, где пересекалась разработка с другими разработчиками, нет вообще и переживать тем более не о чем!
Устанавливаем правила поддержки для новых объектов, как и ранее, на свое усмотрение:
Получив результирующую конфигурацию, мы имеем в своей базе ни что иное, как "Основная конфигурация хранилища с последними изменениями всех разработчиков + все наши доработки", сохраняем её в файл и без особого труда переносим всё простым сравнением/объединением в основное хранилище конфигурации.
Там (в основном хранилище конфигурации при сравнении/объединении) мы увидим вот такую приятную картину – мы видим только те изменения, которые вносили мы:
Общий модуль:
Объединяем с хранилищем и понимаем, что мы сократили огромное количество времени и сил.
Таким способом (см. «Обновление базы из хранилища») можно обновлять конфигурацию своей тестовой базы в любой момент времени, перенося к себе изменения, сделанные своими коллегами и уже помещенными в хранилище. Это полезно при длительной разработке какого-то проекта в своей базе, вы переносите чужие изменения и сразу адаптируете свой код под новые условия.
Углубившись в проблему, мы поняли, что в большей степени каждый сам для себя выбирает пути в коллективной разработке. Но кто-то не ищет лёгких путей, а ходит «по натоптанной». Надеюсь материал был Вам полезен, и вы примете на вооружение эту полезную и нужную технологию. Удачной и, главное, легкой вам коллективной разработки. Спасибо за прочтение статьи.
UPD 08.06.2021
Рекомендация - для больших конфигураций все же лучше снимать объекты своей базы с поддержки "точечно", так трехстороннее сравнение при обновлении конфигурации из хранилища происходит в несколько раз быстрее и экономится приличное количество времени, очень хорошо описал эту проблему коллега в комментарии к данной статье "чем больше размеров конфигурация, тем более заметно вы будете это ощущать по времени её обновление".
Еще одна из хороших рекомендаций которая прозвучала в комментариях к статье - если в вашей организации практикуют захват объектов в хранилище на все время изменения, вместо технологии разветвленной разработки, то перед тем как создавать из основного хранилища файл поставки для последующего обновления им локальной базы разработки - в основном хранилище следует захватить доработанные вами объекты заранее, если это конечно возможно. Это нужно, чтобы к моменту переноса доработок на основное хранилище ваши доработанные объекты были доступны для изменения и их не смогли захватить другие разработчики под свои нужды пока вы ведете работу в своей базе.