Технология разветвленной разработки конфигураций 1С

08.06.21

Разработка - Групповая разработка (Git, хранилище)

Вся групповая разработка любой организации, где работает более 2-х программистов, в превосходящем большинстве случаев строится вокруг хранилища конфигурации. Те из нас, кто обращался к стандартам разработки 1С как минимум раз в жизни и читал их полностью (а может, и просто слышал от коллег), наверняка знают, что существует «Технология разветвленной разработки конфигураций» https://its.1c.ru/db/v8std#content:709:hdoc но не все поняли, как на самом деле эту замечательную вещь применять на практике, а кто-то понял и вероятнее всего думает, что «это к нам не относится, командная разработка по такой технологии в нашей организации не получится в силу определённых причин и потому применять её, к сожалению, я один не могу и не буду», до конца не разобравшись во всех аспектах, но это ошибочное мнение. В этой статье я постараюсь описать свой опыт, рассказать о преимуществах использования данной технологии, дать понять, что технология разветвленной разработки конфигураций на самом деле вещь индивидуальная и каждый для себя решает сам, применять её или нет, а также внести понимание, что у вас вообще нет никакой зависимости от своих коллег, работая в хранилище конфигурации при использовании этой технологии.

Рассмотрим типовые примеры, которые используются в организациях:

  1. Один говорит – все слушают (линейный подход):

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

Естественно, это (захват объекта) может продолжаться достаточно долго, пока не завершится разработка, человек и того хуже, может уйти в отпуск, заболеть и забыть отпустить объект конфигурации, а время идет и задачу нужно решать. Если человек длительно отсутствует на рабочем месте, а объект все же нужен прямо сейчас, то выход один - отменять захват объекта администратором хранилища принудительно. В этом случае разработчик, захвативший объект, потеряет изменения, которые он вносил в объект. Мягко говоря, подход «так себе».

  1. Все говорят – все слушают (параллельный подход):

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

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

Недостатки – чем больше срок между получением файла хранилища конфигурации и переносом своих изменений обратно, тем больше различий в самом хранилище, которые туда уже поместили другие за время разработки, и тем сложнее переносить свои изменения в основное хранилище, особенно в тех местах где разработка пересекалась с другими коллегами в одних и тех же модулях, и объектах. Много галочек, много различий в объектах, изменилась сортировки и порою можно просидеть не один час реального времени, перенося все это, каждый объект нужно просмотреть и учесть всё, чтобы случайно не затереть помещенный ранее код коллег. Здесь принцип «кто успел, тот и съел», то есть кто поместил раньше тебя свои изменения в модуль, тому и проще, ведь это не ему придется сравнивать код двух модулей, объединять его в один и т.д. Если вспомнить, что бывают проекты по 2-3 месяца, то подобный подход при завершении проекта и переносе в основное хранилище покажется сущим адом.

Рассмотрим наиболее выгодный подход для разработчика при работе в крупной команде:

  1. Все говорят, но я никого не слушаю и делаю по-своему (параллельный подход с минимальным контролем).

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

Имеем какую-то конфигурацию (собственную, отраслевую или от фирмы 1С не имеет значения).

В частном случае создана конфигурация из трех документов и одного общего модуля

Содержание общего модуля достаточно банальное

Для этой конфигурации создано хранилище.

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

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

Разработчик 3 пойдет по пути №2, но при этом не будет заботиться и переживать о контроле, он отдаст это механизмам 1С. Создаёт файл поставки от основного хранилища конфигурации. После чего этот файл поставки загружает в свою тестовую базу, поставив её на поддержку.

Если появится сообщением с вопросом, отвечаем положительно

Загрузив файл поставки в свою тестовую базу, видит, что все объекты находятся на поддержке или, как говорят, «на замке»:

На этом этапе технология разветвленной разработки (п. 4. Разработка технических проектов) гласит - Правило «Объект поставщика редактируется с сохранением поддержки» нужно устанавливать только для тех объектов, которые изменяются при выполнении технического проекта. Правило нужно менять как можно более точечно – например, если изменения в проекте будут затрагивать только форму, то нужно изменить правило только для этой формы, а для объекта, которому эта форма принадлежит, нужно оставить правило «Объект поставщика, не редактируется».

На самом деле это только Ваше дело, устанавливать правило «Объект поставщика редактируется с сохранением поддержки» точечно или сразу для всей конфигурации целиком. Методологически правильно делать как гласят стандарты, но это долго и, по моему мнению, избыточно, т.к. при разработке проекта часто меняется много объектов сразу. В тот момент, когда потребовалось в процессе разработки поменять, к примеру, общий модуль или модуль объекта, которые ещё на поддержке, нужно открывать окно поддержки конфигурации, пользоваться неудобным поиском, визуально находить нужный объект метаданных, менять свойство снимая с поддержки и т.д. в то время как в голове содержится информация по разработке, и она может вылететь из головы из-за того, что ты отвлекся на лишние действия. Я по своему опыту сразу устанавливаю для всей конфигурации целиком правило «Объект поставщика редактируется с сохранением поддержки», это позволяет мне не снимать точечно в том числе с поддержки те метаданные, которые я изменю в процессе разработки, но в хранилище конфигурации они «на замке» от основного поставщика конфигурации, там я как раз их сниму в процессе переноса и помещения в хранилище точечно, если уже потребуется!

Открываем настройку поддержки конфигурации

И включаем возможность изменения

Устанавливаем правила поддержки

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

Для примера мы поменяем общий модуль «ОбщийМодульДляВсегоВызовСервера» и «ДокументРазработчика3», добавим свой общий модуль и справочник.

Процедуру, которая имела вид

Мы преобразовали к такому:

В результате чего конфигурация принимает примерно такой вид:

Аналогично поступят Разработчик 1 и Разработчик 2, мы опустим этот момент, скажем лишь то, что Разработчик 1 без особых переживаний сделает это прямиком в хранилище конфигурации с захватом объектов, Разработчик 2 сохранит свой файл конфигурации и перенесет все сравнением/объединением, потратив какое-то количество времени на все это. И наступает наша очередь (мы самые последние) переносить свой проект в хранилище.

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

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

Обновление базы из хранилища:

Видим следующую картину обновления

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

Снимаем отметку в корне конфигурации, тем самым сняв отметки со всех объектов метаданных

И устанавливаем фильтр в режим «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».

В данном режиме возвращаем отметку в корне конфигурации, отметив все объекты в этом режиме

 

И переключаем фильтр в режим «Показывать только дважды измененные свойства»

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

В данном случае я вношу результирующие изменения, просто добавив их в конкретную процедуру

И на этом все! Если режим «Показывать только дважды измененные свойства» вообще не показал ничего, значит, мест, где пересекалась разработка с другими разработчиками, нет вообще и переживать тем более не о чем!

 

 

Устанавливаем правила поддержки для новых объектов, как и ранее, на свое усмотрение:

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

Там (в основном хранилище конфигурации при сравнении/объединении) мы увидим вот такую приятную картину – мы видим только те изменения, которые вносили мы:

Общий модуль:

Объединяем с хранилищем и понимаем, что мы сократили огромное количество времени и сил.

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

Углубившись в проблему, мы поняли, что в большей степени каждый сам для себя выбирает пути в коллективной разработке. Но кто-то не ищет лёгких путей, а ходит «по натоптанной». Надеюсь материал был Вам полезен, и вы примете на вооружение эту полезную и нужную технологию. Удачной и, главное, легкой вам коллективной разработки. Спасибо за прочтение статьи.

UPD 08.06.2021

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

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

Технология разветвленной разработки конфигураций

См. также

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Программист Стажер Платформа 1С v8.3 Платные (руб)

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    10048    81    4    

115

Групповая разработка (Git, хранилище) Программист Стажер Бесплатно (free)

Не знаете, чем бы таким заполнить свой профиль Github? Заполните его своими статьями на Инфостарт! Этот простой workflow сам соберет список ваших последних статей и будет периодически обновлять его для актуализации данных.

08.04.2024    1135    bayselonarrend    2    

32

Групповая разработка (Git, хранилище) Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Доработки 1С:ERP на крупных проектах можно организовать, не внося изменения в саму типовую конфигурацию, а используя только расширения и отдельные «микроконфигурации». Расскажем о том, как это сделать без EDT, используя процесс разработки GitHub Flow.

02.04.2024    6306    Begemoth80    24    

49

Групповая разработка (Git, хранилище) OneScript Системный администратор Программист Бесплатно (free)

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1907    bayselonarrend    3    

41

Групповая разработка (Git, хранилище) Программист Бесплатно (free)

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    2686    user1989937    6    

17

Групповая разработка (Git, хранилище) Программист Стажер Бесплатно (free)

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    4519    bayselonarrend    15    

66

Групповая разработка (Git, хранилище) Программист Стажер Бесплатно (free)

Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.

22.01.2024    8569    bayselonarrend    50    

88

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    3703    kamisov    19    

62
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. OlegLad67 19.05.21 15:39 Сейчас в теме
Очень интересная статья! Первый раз про такое читаю. Спасибо!
3dice; POWone; LeXXeR; +3 Ответить
2. sinichenko_alex 181 19.05.21 15:57 Сейчас в теме
(1) благодарю за высокую оценку!
3dice; POWone; +2 Ответить
3. Cmapnep 18 20.05.21 09:52 Сейчас в теме
Хороший подход, но есть нюансы.
С увеличением масштаба дорабатываемой конфигурации растут и накладные расходы - если, например, мы дорабатываем ERP и задачи нарезаны достаточно мелко, то цикл выгрузка-сравнение-выгрузка-сравнение может занимать больше времени, чем сама разработка.
Также не решается проблема с захватом разрабом №1 в основном хранилище - наша загрузка в него не пройдет, пока не будут освобождены все измененные нами объекты и в общем случае придется некоторое время ждать, захватывая объекты по мере их освобождения. За это время накопятся не обработанные нами на первом этапе изменения, которые нужно будет не забыть учесть при объединении.
В общем одному по такой технологии на крупном проекте не реально работать, как бы не хотелось, а вот если каждый член команды будет придерживаться технологии разветвленной разработки, да еще и в основное хранилище будет помещать тимлид, совмещая с ревью кода, то будет совсем отлично - именно такой подход предлагает нам вендор
3dice; DELOVOYDOM; rpgshnik; POWone; nekit_rdx; Rastopchinss; Dementor; almierm; CodeNull; dabu-dabu; ITSun; RustIG; akimych; prosoftsystems; Tavalik; CSiER; John_d; FatPanzer; cleaner_it; +19 Ответить
5. sinichenko_alex 181 20.05.21 11:14 Сейчас в теме
(3)
Также не решается проблема с захватом разрабом №1 в основном хранилище

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

(3)
За это время накопятся не обработанные нами на первом этапе изменения, которые нужно будет не забыть учесть при объединении


Помещать в основное хранилище логически незавершенный код частями, полагаясь на "когда повезло тогда и поместил часть кода" - плохая практика, если у Вас так делают, то Вам никакие технологии и методики не помогут. Я Вам здесь приведу пример, у вас задача при решении которой вы изменили 3 документа и один общий модуль, они все связаны, общий модуль захватил коллега и не отпускает, вы будете помещать эти 3 документа в хранилище, а общий модуль нет? Судя по вашему комментарию получается так.
И к сведению если конфигурация будет на поддержке от основного хранилища. То можете свои изменения помещать хоть порциями, хоть вообще по одному объекту объединять, при следующем сравнении/объединении они отображаться не будут, а покажутся лишь остаточные различия которые вам как раз таки и "нужно было не забыть учесть при объединении". Главное не забыть создать очередной файл поставки и обновить им свою конфигурацию в тестовой базе которая находится на поддержке.

(3)
С увеличением масштаба дорабатываемой конфигурации растут и накладные расходы - если, например, мы дорабатываем ERP и задачи нарезаны достаточно мелко, то цикл выгрузка-сравнение-выгрузка-сравнение может занимать больше времени, чем сама разработка.


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

(3)
на крупном проекте

(3)
мы дорабатываем ERP и задачи нарезаны достаточно мелко

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

(3)
В общем одному по такой технологии на крупном проекте не реально работать


Это сугубо Ваше мнение, никто не в праве его оспаривать. Просто сама суть, вы даже не пробовали (в отличие от меня), но уже критикуете и говорите что это не работает :) Остается лишь пожелать дальнейшего просиживания по несколько часов на сравнении и объединении конфигураций "по старинке", на периодической ловле ошибок которые связаны с этим, а также хорошей памяти, чтобы все что "накопилось необработанное не забыть учесть при объединении"
3dice; POWone; Dementor; Bassgood; +4 Ответить
12. Cmapnep 18 20.05.21 15:28 Сейчас в теме
(5) Видимо неправильно донес свою мысль - постараюсь пояснить

эта проблема не решается вообще никаким образом

Решается как указал выше - в основным хранилищем работает ТОЛЬКО тимлид. Он мержит доработки от всех разрабов и разрешает все конфликты, он же захватывает все нужные объекты. Только такой подход, насколько я знаю, обеспечивает возможность помещать целиком изменения разрабов в правильной последовательности даже при наличии пересечений по коду.

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

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

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

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

Вы же сами пишите "выгрузка-сравнение"... Я здесь Вас если честно немного не понял

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

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

Тут уже я не понимаю о чем вы пишете...

Ну и вообще, пожелание - не нужно преподносить выбранный вами способ как панацею. У любого способа есть как плюсы, так и минусы, на которые я и указал.
Также я написал "хороший подход", т.к. мне лично технология разветвленной разработки нравится, но именно в каноническом варианте - для всей команды и с выделенным ответственным за помещение в основное хранилище
3dice; Рамзес; VKislitsin; almierm; sinichenko_alex; +5 Ответить
14. sinichenko_alex 181 20.05.21 16:21 Сейчас в теме
(12) благодарю за такой более детальный и развернутый ответ который многое прояснил. Ставлю плюс :)
3dice; Рамзес; Cmapnep; +3 Ответить
4. user634257_mryzhov 20.05.21 10:40 Сейчас в теме
Еще бы варианты работы через GIT осветить:
- синхронизация gitsynс работа через конфигуратор
- разработка в Enterprise Development Tools
Рамзес; +1 Ответить
8. sinichenko_alex 181 20.05.21 13:39 Сейчас в теме
(4) к сожалению пока такого глубокго опыта в этих вопросах (чтобы можно было написать статью поделившись этим опытом) нет. Но как только я буду готов, обещаю что напишу статью и об этом тоже :) кстати саасибо за направление к которому действительно стоит присмотреться.
6. VAAngelov 411 20.05.21 12:07 Сейчас в теме
Отличная статья! Спасибо.
POWone; sinichenko_alex; +2 Ответить
7. Алексей Воробьев 310 20.05.21 13:39 Сейчас в теме
Отлично, большое спасибо автору! Как нельзя более вовремя статья подоспела. В копилку вариантов к рассмотрению. Как раз выбираем путь проектной доработки ERP с сохранением возможности мелких доработок в боевой конфигурации и последующим слиянием.
Как мне представляется, способ, представленный в статье, очень даже подходит для подобного вида разработки. Будем пробовать!
sinichenko_alex; +1 Ответить
9. sinichenko_alex 181 20.05.21 13:41 Сейчас в теме
(7) спасибо. Я очень рад, что опыт пригодился и тем более возможно будет рассматриваться как основной вариант применения в вашей команде! Это приятно осознавать.
10. Bassgood 1435 20.05.21 14:13 Сейчас в теме
Еще в качестве дополнения к описанной в статье последовательности действий - перед тем как создавать из основного хранилища файл поставки для последующего обновления им локальной базы разработки (и дальнейшего накатывания доработок обратно на основное хранилище) - в основном хранилище следует захватить доработанные вами объекты (если это конечно возможно, ведь другие разработчики согласно статье могут работать без использования этой технологии), дабы к моменту накатывания доработок на основное хранилище ваши доработанные объекты другие разработчики не смогли бы захватить их под свои нужды. То бишь сначала мы добиваемся того, чтобы все доработанные нами в рамках тех. проекта объекты были захвачены в основном хранилище, а уже после этого занимаемся обновлением локальной базы разработки и переносом доработок в основное хранилище.

Можно также упомянуть, что инструменты для применения технологии разветвленной разработки также реализованы в типовом решении "1С:Система проектирования прикладных решений" (СППР), в котором можно выделить следующие основные моменты:
1. Ведение тех. проектов с возможностью их привязки к измененным объектам конфигурации (в том числе с детализацией этих изменений, формируемых через отчет о сравнении конфигураций)
2. Автоматизация действий по работе с хранилищем тех. проекта, основного хранилища, базой тех. проекта - их создание, обновление и перенос доработок
3. Возможность работы с тех. проектом как с созданием отдельного хранилища под тех. проект, так и без его создания (через основное хранилище или вообще без хранилища) - в зависимости от объема доработок, планируемых в рамках тех. проекта
3dice; Krio2; sinichenko_alex; Алексей Воробьев; +4 Ответить
15. sinichenko_alex 181 20.05.21 16:23 Сейчас в теме
(10) вы все верно написали! Спасибо, буквально на выходных дополню статью этой информацией!
11. CSiER 35 20.05.21 14:13 Сейчас в теме
Спасибо за публикацию. В приведенной статье ИТС, как мне кажется, очень важен шаг 10 в случае наличия обычных форм (например, при объединении у реквизитов может очиститься свойство "Данные", слететь привязки).
POWone; sinichenko_alex; +2 Ответить
18. sinichenko_alex 181 21.05.21 04:10 Сейчас в теме
(11) в случае с обычными формами (а если подумать то с управляемыми тоже) при объединении форм (именно самих форм, а не их модулей) конечно есть соответствующие коллизии. В таких случаях, когда вы изменяете реквизиты формы, сами элементы, их расположение и т.д., а в особенности если это обычные формы где как Вы верно подметили есть еще и привязки элементов нужно понимать, что дополнительный контроль здесь не помешает, и конечно следовало бы выполнить п.4, п.9, п.10 "Приложение 2. Порядок обновления хранилища технического проекта до состояния основного хранилища" статьи ИТС. Постараюсь дополнить статью этой информацией на выходных в том числе.
13. Maxisussr 20.05.21 16:01 Сейчас в теме
Еще один из возможных вариантов на данный момент -
1. От хранилища отказываемся
2. Используем выгрузку формата EDT и ГитКонвертор.
3. Каждый разработчик с помощью EDT создает свою ветки и работает в ней.
4. Разработка ведется в конфигураторе. EDT позволяет открыть любую ИБ с пом. конфигуратора и потом "подсосать" изменения обратно в ветку.
5. Периодически (не реже, чем перед помещением в ветку) получаем изменения основной ветки и сливаем средствами EDT.

Плюсы - EDT используем только в качестве работы с GIT и для мержевания. Разрабатывать в самом EDT не обязательно. Повышается параллельность работы. Merge происходит проще, чем опасно в статье.
Минусы - нужно использовать 2 продукта. Подход требователен к ресурсам.
michmich; sinichenko_alex; +2 Ответить
16. sinichenko_alex 181 20.05.21 16:25 Сейчас в теме
(13) в целом все так, из еще одного минуса сюда можно добавить, то что из 10-ти разработчиков 1С (а может даже 20-ти) с EDT знаком на достаточном уровне 1 максимум 2. Поэтому как описали в (12) вероятнее всего в этой схеме работающий с GIT и EDT должен быть тимлид.
17. Nefilimus 75 20.05.21 16:58 Сейчас в теме
Полезная статья, благодарю. Я привык работать один, но думаю в будущем точно понадобиться
19. ManyakRus 484 21.05.21 09:40 Сейчас в теме
Лучше всего "линейный подход", главное придумать порядок как пользоваться хранилищем совместно. Например писать новый код 99% только в своём "личном" общем модуле, тогда проблема решается на 99% :-)
20. sinichenko_alex 181 21.05.21 10:16 Сейчас в теме
(19)
Лучше всего "линейный подход", главное придумать порядок как пользоваться хранилищем совместно. Например писать новый код 99% только в своём "личном" общем модуле, тогда проблема решается на 99% :-)

ну тогда и справочники нужно каждому свои, регистры, документы... ну вы поняли...
Bassgood; +1 Ответить
25. ManyakRus 484 24.05.21 09:20 Сейчас в теме
(20) да, правильно.
Все новые справочники, регистры, документы должен изменять только автор.
26. Bassgood 1435 24.05.21 10:35 Сейчас в теме
(25) А если автор в отпуске или на больничном, или занят другими задачами - ждать когда он сможет принять на себя очередную задачу, связанную с доработкой "его" объектов?
А ведь чем дальше, тем "его" объектов будет только больше и в конечном итоге он физически не сможет выполнять в срок все задачи, которые касаются доработки "его" объектов.
3dice; sinichenko_alex; +2 Ответить
28. ManyakRus 484 24.05.21 10:45 Сейчас в теме
(26) 1. Кроме отпуска конечно
2. Исправить старую ошибку важнее чем сделать новую, не делать новых функций пока старые не исправлены
31. Bassgood 1435 24.05.21 11:02 Сейчас в теме
(28) Имеем десять задач, восемь из которых относится к подсистеме автора - две отдадим первому разработчику, а все остальные восемь будет делать автор, в то время как первый разработчик будет простаивать без задач?
А как же взаимозаменяемость - уйдет из проекта автор и все, проект встал? В итоге все равно доработкой его авторских модулей далее будет заниматься другой разработчик, который в них по "нулям", потому что ни разу в них не лазил и не в курсе как и что в них работает, ведь он никогда не выполнял каких-либо задач, касающихся доработки модулей уже ушедшего автора (спросить по ним уже не у кого). Лучше совершить ошибки в начале в присутствии автора, чем совершать их уже после в его отсутствии.
А компании, в которых высокая текучка программистов - так там вообще сборная солянка будет, если каждый такой автор будет создавать под себя отдельные модули, вместо того чтобы разобраться в работе уже существующих.
3dice; POWone; +2 Ответить
33. ManyakRus 484 25.05.21 10:14 Сейчас в теме
(31)
все остальные восемь будет делать автор

это хорошо, это правильно.
"взаимозаменяемость " - это безответственность, когда никто ни за что не отвечает, даже за свой лично созданный документ, так нельзя, можно только временно во время отпуска.
34. Bassgood 1435 25.05.21 10:33 Сейчас в теме
(33)
это безответственность, когда никто ни за что не отвечает

Для этого в том числе и существуют системы версионирования (хранилище конфигурации), через которое можно просмотреть кто, что и когда сделал и определить ответственного за то или иное изменение в программе.
Правильно когда один из разработчиков простаивает только потому что по "его" подсистеме нет задач? А как к этому отнесется сам разработчик (если у него почасовка, то вряд ли будет рад простаиванию без оплаты) и бизнес, который платит за недешевого разработчика, используемого далеко не на все 100% (если у него фикс оплата)?
sinichenko_alex; +1 Ответить
38. ManyakRus 484 26.05.21 09:37 Сейчас в теме
(34)
определить ответственного за то или иное изменение

1) Ответственный должен быть не за изменение, а за весь новый документ, в том числе за чужие изменения если кто-то туда залезет.
2) "один из разработчиков простаивает" - можно делиться ответственностью, передать один из своих документов (обязанностей) другому сотруднику навсегда, а не на 1 раз.
39. Bassgood 1435 26.05.21 11:34 Сейчас в теме
(38)
1) Ответственным за тот или иной объект может быть назначен конкретный разработчик, но это не означает что только он может его дорабатывать - он может производить код-ревью изменений, внесенных в "его" объекты другими разработчиками
2) Навсегда - это до смерти или до ухода разработчика из команды? Сегодня первый разработчик передал его второму, завтра второй уволился - документ обратно перешел первому, второй послезавтра уволился - теперь документ "пилит" только третий. Если речь идет именно о разделении ответственности за код-ревью конкретных объектов - то это одно дело (п.1), если же речь идет о разграничении прав на доработку объектов - то это уже другое дело (именно в этом случае и теряется гибкость)
sinichenko_alex; +1 Ответить
27. Bassgood 1435 24.05.21 10:39 Сейчас в теме
(19)
Например писать новый код 99% только в своём "личном" общем модуле, тогда проблема решается на 99% :-)

На практике видел модули, именованные по фамилии автора - это конечно что-то с чем-то, чтобы наверняка никто не перепутал его модули с другими ;)
А процедуры общего назначения, которые могут использоваться в любом месте программы или в нескольких подсистемах, Вы предлагаете дублировать в авторских модулях?
sinichenko_alex; +1 Ответить
29. ManyakRus 484 24.05.21 10:46 Сейчас в теме
(27)
общего назначения
кроме типовых каждый сам себе сделает отдельно
21. Bassgood 1435 21.05.21 11:07 Сейчас в теме
Кстати касательно установки правила поддержки "Объект поставщика редактируется с сохранением поддержки" для всех объектов конфигурации сразу, вместо точечной установки этого правила только для модифицируемых вами в рамках тех. проекта объектов - минусы такого подхода в следующем:
1. Более длительное обновление конфигурации локальной базы разработки поставкой из основного хранилища - ведь в этом случае система будет производить сравнение всех объектов конфигурации, в виду снятой у них блокировки от редактирования в виде "замка поддержки" - чем больше размеров конфигурация, тем более заметно вы будете это ощущать по времени ее обновления (это же касается и доработок типовых конфигураций - снимать замок следует только с модифицированных нами объектов)
2. Нет возможности визуально понимать какие объекты вы модифицировали в процессе разработки тех. проекта - ведь они все разблокированы от редактирования, а значит изменения могли быть внесены вами в любые из них (в противном случае вы наглядно могли бы понять меняли ли вы что-то в том или ином объекте или нет - если замок на нем стоит, то вы его точно не "трогали"), особенно если тех. проект запланирован на длительный срок
3dice; Рамзес; Dementor; zqzq; sinichenko_alex; +5 Ответить
22. sinichenko_alex 181 21.05.21 12:27 Сейчас в теме
(21)
, в виду снятой у них блокировки от редактирования в виде "замка поддержки" - чем больше размеров конфигурация, тем более заметно вы будете это ощущать по времени ее обновления (это же касается и доработок типовых конфигураций

спасибо за замечание. Думаю стоит этим тоже дополнить статью. Это не маловажный факт!
37. sinichenko_alex 181 26.05.21 04:25 Сейчас в теме
(21)
2. Нет возможности визуально понимать какие объекты вы модифицировали в процессе разработки тех. проекта - ведь они все разблокированы от редактирования, а значит изменения могли быть внесены вами в любые из них (в противном случае вы наглядно могли бы понять меняли ли вы что-то в том или ином объекте или нет - если замок на нем стоит, то вы его точно не "трогали"), особенно если тех. проект запланирован на длительный срок


Перечитал сегодня этот пункт и вник более детально в его смысл. На мой взгляд это исключено. Даже если случится так, что вы случайно внесли какие-то изменения в произвольный модуль сами того не поняв (случайно ткнули эникей в модуле и закрыли его сами того не поняв, после чего сохранили конфигурацию, и случалось так что проверка синтаксиса не обнаружила ошибки), то технология выполнит еще одно свое предназначение - исключить такие "неоднозначные" ситуации. В тот момент когда вы обновляете свою конфигурацию из хранилища и смотрите "Дважды измененные" вы как раз видите объекты которые модифицировали совместно с другими коллегами, если на этом этапе не было выявлено таких ситуаций (с эникеем или вообще с изменением модулей или объектов), то когда вы будете переносить изменения обратно из своей конфигурации в хранилище вы увидите именно все измененные Вами объекты, тоесть вашу фразу "(в противном случае вы наглядно могли бы понять меняли ли вы что-то в том или ином объекте или нет - если замок на нем стоит, то вы его точно не "трогали"" можно переформулировать в этом контексте буквально так "вы наглядно увидите и поймете меняли ли вы что-то в том или ином объекте или нет - даже если замок на нем не стоит вы его точно трогали", потому как при сравнении и объединении будут отображаться только ваши изменения и ничьи больше. И вам в любом случае в этот момент нужно посмотреть - что вы меняли вообще когда писали проект, на этом этапе как раз и всплывут проблемы с "эникеем" или еще какие либо.
Но стоит отметить и Важный факт который вы озвучили, что точечное снятие объектов с поддержки гарантированно избавляет Вас от подобных ситуаций (например с тем же эникеем), по этой причине менее опытным разработчикам все же следует выполнять требование в этой части.
Bassgood; +1 Ответить
42. kirinalex 15 24.07.21 08:43 Сейчас в теме
(21)
2. Нет возможности визуально понимать какие объекты вы модифицировали в процессе разработки тех. проекта - ведь они все разблокированы от редактирования,

Если конфигурация относительно небольшая, то это можно решить организацией своего персонального хранилища. Этим решается и вопрос возможности экспериментов без риска потерять текущий код, т.к. можно откатываться на версии хранилища.
3dice; Bassgood; +2 Ответить
43. sinichenko_alex 181 25.07.21 14:18 Сейчас в теме
(42) Если конфигурация относительно небольшая то технология разветвленной разработки там не нужна.
44. kirinalex 15 25.07.21 15:57 Сейчас в теме
(43) и где же та грань? ньюансы размеров могут влиять на накладные расходы по созданию и поддержки своего хранилища, я о этом
23. Akcium 311 21.05.21 14:35 Сейчас в теме
Используем у себя для продуктовой разработки подобный подход.
Единственное, что как отметили коллеги выше включаем возможность изменений точечно, только для отдельных объектов.
3dice; sinichenko_alex; +2 Ответить
24. Agregadus 19 22.05.21 17:48 Сейчас в теме
то выход один - отменять захват объекта администратором хранилища принудительно. В этом случае разработчик, захвативший объект, потеряет изменения, которые он вносил в объект.

ничего не теряется.
Bassgood; zqzq; +2 Ответить
30. Bassgood 1435 24.05.21 10:48 Сейчас в теме
(24) Я бы написал, что может потерять эти изменения, если обновит свою локальную базу разработки из хранилища
sinichenko_alex; +1 Ответить
32. sinichenko_alex 181 24.05.21 14:54 Сейчас в теме
(30) так сказать вернее всего, думаю стоит переформулировать трактовку в статье дабы убрать недопонимание
35. 7OH 69 26.05.21 00:29 Сейчас в теме
А кто сказал, что насильная отмена захвата ведёт к потере изменений захватившим?
Ничего никто не теряет.
Рамзес; sinichenko_alex; +2 Ответить
36. sinichenko_alex 181 26.05.21 04:07 Сейчас в теме
(35) там есть условия при которых произойдет потеря изменений. Я позже опишу чуть подробнее. Там конечно не безусловная потеря изменений но риск есть.
40. eskor 98 27.05.21 12:11 Сейчас в теме
Методика весьма интересна. Для уменьшения риска потери данных нужно затвердить правила (т.е. регламент) для сотрудников.
Однозначно имеет право на жизнь, обязательно попробую в ближайшее время.
sinichenko_alex; +1 Ответить
41. kirinalex 15 24.07.21 08:40 Сейчас в теме
можно еще добавить, что на это дело хорошо ложатся инструменты трехстороннего объединения
P4Merge как пример
sinichenko_alex; +1 Ответить
45. POWone 06.10.21 16:56 Сейчас в теме
Спасибо автору за разъезнения и примеры) Попробовал, вроде получается)
sinichenko_alex; +1 Ответить
Оставьте свое сообщение