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

Меня зовут Александр Синиченко. Я работаю программистом в компании «DNS Технологии».

В докладе расскажу:

• Что такое технология разветвленной разработки;

• Как ее применить на практике;

• Как работать в «стороне» от основного хранилища, но при этом иметь с ним связь;

• Как снизить очередь и простои разработки в ожидании освобождения объектов хранилища конфигурации;

• Как вести разработку «долгоиграющих» проектов без длительного захвата этих объектов в хранилище;

• Как не совершить факап во время сравнения и объединения конфигурации;

• Некоторые тонкости мержа конфигураций на поддержке.

Доклад является развитием статьи //infostart.ru/1c/articles/1443756/ и дополняет изложенные в ней идеи.

Технология разветвленной разработки от фирмы «1С» помогает команде разработки достичь следующих целей:

• повышение качества разрабатываемой конфигурации;

• повышение культуры разработки и тестирования;

• обеспечение непрерывного развития конфигурации в условиях жестких сроков разработки.

Основные понятия, используемые в технологии:

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

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

• «Технический проект» – задание на доработку конфигурации. Для ведения информации о технических проектах предлагается использовать СППР (систему проектирования прикладных решений), но мы ее в докладе рассматривать не будем.

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

При этом в исправительной версии не должно быть объемных доработок.

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

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

Допускается мелкое исправление ошибок непосредственно в основном хранилище.

На слайде – рекомендации по содержанию комментариев к меткам при переносе технических проектов в основное хранилище.

Порядок нумерации редакций и версий для технологии разветвленной разработки описан в отдельной статье ИТС.

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

Как применить технологию разветвленной разработки конфигураций 1С на практике

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

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

А перед переносом доработок хранилище технического проекта нужно обновить до состояния основного хранилища. Именно этот процесс мы сейчас и рассмотрим.

Перед обновлением конфигурации технического проекта фирма «1С» предлагает сохранить отчет о сравнении его объектов с конфигурацией поставщика.

Далее запускаем процесс обновления и в открывшемся окне сравнения устанавливаем фильтр «Показывать только дважды измененные свойства». Этот фильтр отображает объекты конфигурации, которые были доработаны одновременно и поставщиком и программистом.

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

Далее мы можем выбрать для новых объектов, которые пришли к нам от поставщика, режим сохранения поддержки.

После завершения объединения с конфигурацией поставщика предлагается:

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

• Снова сформировать отчет о сравнении объектов.

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

Советы и рекомендации хорошие, но возникает вопрос: почему фирма «1С» предлагает проделанную нами в хранилище технического проекта работу затереть обновлением из основного? А если изменено 20 объектов? Или 40? Если программист 2 месяца трудился, ему все это нужно ручками переносить? А как? Искать отличия, сравнивая с необновленной конфигурацией базы данных? Вы понимаете, что это довольно сомнительное мероприятие.

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

Стандартный вариант использования хранилища

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

Но такой захват объекта может продолжаться неделями, человек может этот объект и на время тестирования у себя придержать, сказать: «Я когда его протестирую, тогда и отдам». А другим разработчикам, возможно, тоже нужно что-то срочно с этим объектом делать – у них приближается дедлайн сдачи отчетности и сроки по задаче горят.

Как снизить очередь и простои разработки в ожидании освобождения объектов хранилища конфигурации

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

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

• После получения изменений из хранилища в этой базе сохраняется файл конфигурации.

• И потом этот файл конфигурации путем загрузки или сравнения-объединения переносится в базу разработки с реальными данными.

• После чего разные разработчики в своих базах независимо приступают к разработке – никому не нужно ничего захватывать, просто сидим, работаем, реализуем свои задачи.

Никого не нужно ждать и ничего не нужно захватывать – это преимущество.

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

Особенно тяжело разбираться с изменениями в тех местах, где наши доработки пересекаются с доработками других коллег в одном и том же месте – допустим, мы вместе меняли какой-то общий модуль: я здесь, а он там.

В диалоге сравнения-объединения мы видим, что поменялись сортировки, есть отличия в куче объектов. Но какие из них были изменены за это время другими разработчиками, а какие нужно перенести мне? Где правда? Как это вспомнить? Можно не один час просидеть, собирая все это в единое целое. Если учесть, что проекты длятся по два-три месяца, под конец разработки сборка всех изменений в кучу окажется сущим адом.

Я когда-то так работал, потому что бизнес не ждет – нужно решать задачи параллельно.

Как работать в «стороне» от основного хранилища, но при этом иметь с ним связь

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

Получается, что мы позаимствуем идею из технологии разъединенной разработки и немного ее дополним.

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

Возьмем простую конфигурацию из трех документов и одного общего модуля. В этом общем модуле:

• есть три процедуры, изменяемые разными разработчиками;

• и одна общая процедура, в которую будут вносить изменения вообще все.

Разработка в команде производится следующим образом:

• Разработчик №1 ведет разработку напрямую – подключился к основному хранилищу, объекты захватывает, все его ждут, сам ждет освобождения.

• Разработчик №2 по новому принципу – сохранил файл в свою базу данных и там ведет разработку, потом с этими рисками все смерживает.

• А мы как разработчик №3 пойдем по тому же пути, что и №2, но при этом поставим базу разработки на поддержку основного хранилища и отдадим определение изменений на откуп механизму трехстороннего сравнения.

Чтобы поставить свою базу разработки на поддержку, разработчик №3 создает пустую базу, получает все изменения из хранилища, и выбирает в меню «Конфигурация» пункт «Поставка конфигурации» – «Создать файлы поставки и обновления конфигурации».

На вопрос о совпадающем имени конфигурации поставщика отвечает положительно. И создает файл поставки.

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

После этого нам требуется включить изменения для нашей конфигурации на поддержке.

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

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

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

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

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

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

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

Далее откроем этот общий модуль и внесем в него изменения. Например, Разработчик3 решил поменять способ определения переменной В: ранее она была равна 3, а он решил, что она должна вычисляться путем сложения А и Б.

Сами метаданные у Разработчика3 также претерпели изменения:

• добавлен ОбщийМодульРазработчик3;

• добавлен Справочник3;

• в ДокументРазработчика3 добавлены: Реквизит1, Реквизит2, ТабличнаяЧасть1 и ФормаДокумента.

Аналогично поступят Разработчик1 и Разработчик2 – они со своими документами сделают то же самое. Но нам не важно знать, что конкретно они будут делать. Нам важно понимать, что мы – последние. Они уже все свои изменения в хранилище внесли, а нам теперь нужно их изменения получить и как-то свои изменения тоже внести в хранилище.

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

Мы открываем ранее созданную пустую базу, которая подключена к основному хранилищу и через команду «Конфигурация» – «Хранилище конфигурации» – «Обновить конфигурацию из хранилища» получаем все изменения из основного хранилища.

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

Перед переносом всех наших изменений в хранилище мы, соответственно, будем обновляться:

• Захватываем в хранилище те объекты, которые мы изменили.

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

• И обновляем этим файлом поставки свою базу разработки – поскольку она находится на поддержке, здесь процесс обновления ничем не будет отличаться от обновления типовой конфигурации 1С.

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

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

Для этого мы снимаем галку в корне со всех объектов метаданных.

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

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

При этом мы исключили:

• те объекты, которые мы создали в нашей базе разработки – они еще не существуют в основном хранилище;

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

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

Для анализа и объединения изменений в дважды измененных объектах нажимаем серенькую шестеренку.

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

Когда вы все свои изменения в процессе сравнения-объединения настроили вручную – у вас появилась зеленая галочка на шестеренке, которая говорит вам о том, что модуль настроен для объединения вручную.

Как не совершить факап во время сравнения и объединения конфигураций

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

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

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

Это баг платформы, на который я нарывался трижды, трижды затирал код своих коллег. Ко мне приходил тимлид и говорил: «Что ты сделал? Как ты мог?» Я говорил: «Я не мог! Я клянусь, я делал все правильно!» После третьего раза я провел детальное расследование и выявил этот баг.

Исправляется он довольно просто:

• либо мы возвращаемся ко всем таким шестеренкам, каждую открываем и снова жмем «ОК» – после этого все будет нормально;

• либо исправляем с помощью сохранения и загрузки настроек из файла – просто сохраняем настройки и тут же их загружаем.

Мы с одним из коллег обсуждали, этот баг в фирму «1С» направлен, но неизвестно, в какой версии его исправят. Будьте готовы, что вы с этим можете столкнуться.

Собственно, все.

Если в режиме «Показывать только дважды измененные свойства» у вас вообще ничего не отображается, значит, пересечения с другими коллегами нет – вам вообще не о чем переживать. Жмем кнопку «Выполнить».

Далее для всех новых объектов устанавливаем свойство «Объект не редактируется», чтобы случайно не снять объект с поддержки.

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

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

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

• ОбщийМодульРазработчик3,

• Справочник3,

• новые реквизиты, табличную часть, форму объекта ДокументРазработчика3 – то, что мы меняли.

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

Открываем общий модуль и тоже видим только наши изменения В=А+Б, а изменения коллег уже здесь, потому что мы их ранее смержили.

Теперь просто все молча переносим без каких-либо проблем.

Таким способом можно обновлять свою конфигурацию разработки снова и снова в любой момент времени. Это полезно как раз при длительных проектах – когда вы разрабатываете свою большую функциональность и не мешаете коллегам вести мелкие доработки в основном хранилище.

В то же время после обновления базы разработки изменениями из хранилища вы можете отладить свой новый код в актуальных условиях – тогда на момент переноса вашего проекта в основное хранилище код уже будет адаптирован и отлажен. Это будет правильнее, чем просто перенести свои изменения в хранилище как Разработчик №2 и потом получить на боевой базе кучу ошибок, которые нужно в срочном порядке исправлять. Я знаю много программистов, которые работали по принципу Разработчика №2, пока не узнали, что можно делать так.

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

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

Также случается, что вам в процессе разработки нужно поменять 4-5 объектов метаданных, один из которых захвачен. Если работать по стандартной схеме, у вас задача наполовину решенная зависает – вам приходится кого-то ждать. А с таким подходом вы просто снимаете объект с поддержки, дорабатываете, а потом мержите.

Конкретный пример работы с хранилищем

На текущий момент, как я говорил, работаю в компании DNS. Расскажу об особенностях нашей разработки:

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

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

• В компании DNS используется полностью самописная конфигурация – у нас нет «Библиотеки стандартных подсистем», и нумерацию сборок мы не ведем. В связи с этим захватывать корень при каждом помещении в хранилище не нужно – это изрядно экономит время.

• ИТ-департамент компании состоит примерно из 320 сотрудников. Больше 150 из них являются программистами 1С.

• У нас более 14 систем.

• Одна из систем имеет объем базы более 20 терабайт – как раз с ней я работаю.

• В основное хранилище этой конфигурации ежедневно помещается от 90 до 100 коммитов – бывает, что между помещениями не проходит и 5 минут.

• Но даже такое количество коммитов позволяет мне неделями не обновляться – работать где-то в сторонке, а потом перенести к себе обновление и поместить свои решенные задачи в основное хранилище.

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

Вручную, сами понимаете, это все контролировать практически невозможно.

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

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

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

Вот, пожалуйста: я один отчет доработал, помещаю его и дальше уже не мучаюсь.

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

• Сначала мы снимаем галочку с корня

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

• И потом устанавливаем фильтр «Показывать только дважды измененные», чтобы изучить перекрестные изменения.

Изучаю изменения:

• Вижу, что есть изменения в конкурентном общем модуле ПечатьВызовСервера:

  • Я помню, что менял процедуру ПолучитьДоверенностьДок – снимаю с нее галочку, чтобы мои изменения попали в объединенную конфигурацию.

  • Процедуру ПолучитьРуководителяМалыйСписок_ тоже менял только я – снимаю с нее галку, чтобы оставить как есть.

  • И дальше по изменениям контролирую, кто что из коллег менял.

• Смотрю, что изменилось в справочнике «ШтатноеРасписание».

• В документе «ДвижениеДенежныхСредств» я менял процедуру «ОткрытьЖурналДокументовСОтбором» – снимаю с нее галочку, чтобы не затереть свои изменения.

• И обработка «ОтчетПоДокументамПЭП» – это полностью мой объект. На всякий случай пробегаюсь и смотрю, что здесь ничего не поменялось.

Получается, что такое сложное обновление обошлось все двумя минутами, тремя от силы.

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

Приятный бонус: удобный Code Review

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

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

• и сохранить свою текущую конфигурацию в файл, передав коллегам с просьбой сравнить.

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

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

Вопросы и ответы

При сравнении модулей конфигурации через «шестеренку» вы применяете инструмент сравнения, встроенный в платформу 1С. А пробовали ли вы использовать для сравнения KDiff3?

Не пробовал.

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

Спасибо, я попробую. Возможно, в будущем будет дополнение к докладу по этому поводу.

Я правильно понимаю, что пока разработчик ведет разработку, другие коллеги его изменения не видят?

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

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

А системы контроля качества кода у вас используются? Тот же SonarQube?

SonarCube используется, он проверяет каждую сборку и присылает отчет.

Он подключен к основному хранилищу?

Да.

А замечания SonarQube вы как закрываете в этом случае?

Тимлидом рассылается информация о том, что есть проблемы, и их нужно срочно исправлять.

На закрытие этих замечаний заводится еще один раз техпроект?

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

Меня смутила фраза в докладе. «Пока программист не отпустил объект». У вас практикуется, что объекты захвачены в хранилище несколько дней?

В целом, да.

А как вы синхронизируетесь, если бизнес хочет дорабатывать одни и те же объекты?

Бизнесу приходится ждать. Если с объектом связано несколько задач, бизнес должен выбрать, какую из них ему важнее решить в первую очередь. О том, что другую задачу в связи с этим придется подождать, он знает.

Я считаю, что эту проблему можно решить, не заставляя бизнес ждать.

В докладе я как раз и рассказал об одном из возможных решений этой проблемы.

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

Почему не Git?

Потому что доклад не про Git, а про хранилище конфигурации.

Git у нас не используется, потому что мы не видим смысла его использовать в качестве системы контроля версий. Обычно в 1С используется Git плюс что-то:

• Но EDT у нас не используется в силу определенных причин – многие не хотят с ним работать, а новичков учить тяжело. Из-за нехватки программистов приходится брать новичков, которые с EDT работать не будут.

• В если работать VS Code плюс Git, то встает вопрос – как отлаживать свой код?

И опять же мы возвращаемся в конфигуратор. А какой смысл иметь Git, если мы ведем разработку в конфигураторе?

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

Обычные формы мержить невозможно – в обычные формы лучше вносить изменения вручную.

Управляемые формы мержатся легче.

А для конфликтов реквизитов или табличных частей – если я, допустим, задал реквизиту тип «Число» с длиной 4, а Вася задал длину 5, мы должны с ним договориться, как правильнее. Здесь нужно сначала решить конфликт.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.