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

Итак,статья посвящена системам версионного контроля и их практическому применению для работы с 1С.

История развития систем контроля версий

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

Историю развития систем контроля версий можно разбить на несколько этапов:

1.     Файловые (локальные) копии

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

2.     Локальные системы контроля версий

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

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

И, в принципе, эти локальные задачи контроля версий на тот момент решало такое программное обеспечение, как RCS (Revision Control System). Я его упоминаю ради исторической справедливости. Потому что использовать подобную систему контроля версий имеет смысл только тогда, когда для разработки используется локальная база. Когда у вас и во всем мире начинается командная разработка, эта система контроля версий уже не подходит.

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

В некоторой степени системы на основе 1С:Документооборот или БСП с подсистемой версионирования файлов также являются локальными системами контроля версий.

3.     Централизованные системы контроля версий

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

Открытыми системами этого типа являются CVS и SVN.

• До вчерашнего дня я думал, что CVS (Concurrent Versions System) уже можно выкинуть на свалку истории, но, оказывается, есть в нем некоторые моменты, которые все-таки до сих пор применимы и в наших сегодняшних жизненных реалиях.
• Subversion (или SVN, сокращение от названия клиента для командной строки, входящей в состав пакета) – это эволюционное развитие CVS. По сравнению со своим прототипом что-то нашло, а что-то потеряло.
• Хранилище 1С тоже является централизованной системой хранения версий. В принципе, в хранилище у нас есть и сервер, и права доступа, и две чашки кофе вы можете успеть выпить, пока захватите рекурсивно весь корень конфигурации, да? А если по http-доступу еще или по tcp – ваше счастье… Придется долго ждать.

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

1. Получил из хранилища
2. Захватил
3. Отредактировал
4. Поместил обратно.

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

Но у централизованных систем есть и некоторые недостатки:

1. Первый недостаток – это конечно то, что сервер фактически является «единой точкой отказа». В связи с этим совет: делайте backup хранилища. На самом деле, хотя бы базы данных.Но хранилища тоже, пожалуйста, делайте. Потому что если с сервером что-то случится – восстановиться можно будет только из backup-а.
2. Следующая особенность – пессимистическая блокировка. Некоторые считают, что, когда в централизованной системе разработчик захватывает объект, он, таким образом, всем объявляет свое намерение, что собирается в этом объекте что-то изменить. К тому же, многие руководители думают, что они, таким образом, контролируют этого разработчика. Раз разработчик захватил какой-то там документ – значит, мы знаем, что он над ним работает, и он его к какому-то периоду времени сделает. По факту, если это уже опытный специалист, и вы ему доверяете, то он, конечно, всегда обоснует, почему он месяц назад объект захватил и до сих пор не поместил его в хранилище. Но все равно – эта пессимистическая блокировка накладывает на нас ограничение, которого можно было бы избежать. В дальнейшем в распределенных системах обошли этот путь.
   Также, если у вас идет глобальный рефакторинг, или идет какое-то исправление модуля и срочно необходимо исправить ошибку – тоже может возникнуть проблема. В худшем случае – база стоит, ничего не работает. В лучшем – возникает дилемма, 50% кода уже исправлена, то ли помещать в хранилище неоттестированный код, то ли сохранять его куда-то в файл. И у нас опять появляется в файловой системе «Копия конфигурации такой-то» и мы забыли/не забыли ее вернуть обратно в конфигурацию.
3. И есть еще в централизованных системах такое соглашение – это за или против, я даже сомневаюсь – что последняя версия у нас самая оттестированная и самая рабочая. По факту, наверное, так и есть. Но только если мы тестируем на пользователях – нам сказали, что есть ошибки, мы их исправили и только тогда положили объект в хранилище. Только в этом случае мы можем быть уверены, что в хранилище у нас более-менее рабочая копия.
   В любых других случаях – для простого программиста у нас тестов нет. Разработчики типовых конфигураций не покрывают код тестами. Нет такого, что – дописал свое, запустил полное тестирование, проверил, как работает. Будет ли? Время покажет.

4.     Распределенные системы контроля версий

Следующим этапом развития систем контроля версий стали, конечно же, распределенные системы. Основная идея этих распределенных систем контроля ревизий – это ветвление.

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

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

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

Ключевые особенности

Итак – что отличает распределенные системы контроля версий от всех остальных?

• Во-первых, как только перед вами встанет задача с кем-то обменяться информацией – для вас станет необходимостью организовать какой-то сервер. Пускай он будет развернут даже на вашей локальной машине, но для обмена сервер необходим.
• Во-вторых, по сравнению с централизованными системами, где обычно можно было бы на определенные объекты поставить ограничение доступа, в распределенных системах нет смысла говорить о какой-то блокировке на определенный файл. В централизованной системе, например, в хранилище, у нас есть возможность на определенные объекты поставить доступ на чтение/запись, а в распределенной системе, поскольку вся копия проекта копируется разработчику на машину, разработчик все равно может этот файл изменить, прочитать и т.д. Это, наверное, одна из проблем… Но при желании, если вам необходимо какому-то удаленному разработчику выгрузить определенную подсистему, чтобы он ваше основное дерево конфигурации не смотрел, вы можете выделить эту подсистему в отдельную конфигурацию. Способы решения есть. Например, можно какую-то часть дерева истории выгрузить, а потом обратно загрузить уже изменения, которые разработчик внес.
• Еще один важный момент, о котором я говорил: в централизованных системах на сервере должен всегда быть оттестированный код. В децентрализованных системах, когда вечером вы уходите домой, вы можете спокойно поместить в свою локальную копию неработающий код. Поверьте, это очень удобно, когда поместили свои изменения и записали для них какой-то естественный комментарий. От комментария многое зависит. Если вы с пустым комментарием что-то помещаете в то же хранилище, то я бы это не приветствовал. Понятно, что вы тут что-то изменили… А что по факту? С учетом скорости хранилища это практически невозможно узнать.
• Ветвление, естественно, является палкой о двух концах. Оно, как линия жизни вашего проекта, может уйти куда-то в сторону, а может держаться генеральной линии. Это надо прочувствовать на себе. И основной принцип – ветвиться часто, но в меру.

Отдельно хотелось упомянуть о важности комментариев к коммиту. Если вы не можете кратко сформулировать результат работы и написать комментарий к версии хранилища, то вы наверное делали черти-что. Понятно, что вы тут что-то изменили… А что по факту? С учетом скорости хранилища это практически невозможно узнать, т.е. комментарий является кратким якорем для памяти и понимания что может быть в этой версии изменено.

Режимы работы распределенных систем

Распределенные системы поддерживают различные режимы работы.

• Если вы разворачиваете проект для одного себя, вы можете использовать базу хранения версий локально.
• Можно по старинке – с центральным сервером. Причем, вы можете копировать не полностью весь репозиторий на него, а только нужные вам для хранения истории файлы. Допустим, выгрузка хранилища 8.3 занимает 1.5 Гб. Разработчику первый раз выгрузить содержимое репозитория по каналу интернета очень тяжело. В то же время, можно выкачать только последние изменения, с которыми он работает.Так, поддерживается тот же принцип централизованной системы, как и в хранилище.
• Без центрального сервера тоже можно работать. Но, в любом случае, какой-то сервер, хотя бы на локальной машине, организовывать все равно нужно.
• И наконец, самый предпочтительный и самый удобный способ – с центральным сервером, с локальными фиксациями и ветками. Однако настройка будет наиболее трудоемкой.

Какие есть системы?

Альтернативы достаточно разнообразны: git, svn, bzr, fossil, hg.

Я специально выделил Mercurial – потому что, к сожалению, если брать практику разработки хранения версий именно для 1С – эта распределенная система не подходит.У нее есть проблемы с кодировками в наименованиях файлов и, когда перед вами встанет вопрос об осуществлении обмена с другим сервером (например, один сервер будет базироваться на ОС Windows 7, а другой – на WindowsXP), вы не сможете синхронизировать данные из-за различного представления кодировок имен файлов для различных ОС. К сожалению, его нельзя пока использовать. Хотя это моя любимая система, т.к. она более логичная и с ветками работает наиболее понятно. Особенно для новичка, делающего попытки разобраться в принципах работы.

SCM fossil

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

Ее особенности:

• Проста
• Удобна
• Весь пакет инсталляции содержит один файл exe, который содержит в себе
  • Систему версионного контроля
  • Систему документирования на основе wiki
  • Простейший баг-трекинг
  • Встроенный web-сервер
  • Управляется с web-браузера
  • Единственный недостаток – нет GUI-интерфейса, к которому все привыкли. Покликать мышкой, чтобы сделать коммит/добавить файл, не получится. Посмотреть изменения через web-интерфейс можно. Но все остальное стандартно, только через консоль
  • Советую применять для внешних обработок, отчетов, схем СКД, различных внешних файлов. Почему-то у нас не любят хранить версии схем СКД, но ведь в процессе разработки схемы для какого-то отчета можно уйтив сторону и потом не вспомнить, какую схему мы использовали изначально…
  • Также SCMfossil можно применять как замену хранилищу для удаленной разработки или для малой разработки. Например, если у вас небольшая конфигурация или раз в два месяца какая-то удаленная разработка – чтобы вспомнить, что же там было в изменениях, fossil подходит просто идеально. Компактный и поддерживает все необходимое для удобной работы.

Здесь приведен простой скриншот web-интерфейса fossilс реальной работы. Внизу видно, как какая-то ветка разработчика слилась в основной ствол дерева.

Практика применения

Теперь продолжим про практику применения в 8.3 различных распределенных систем.

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

• Система управления задачами – Redmine. Я использую ее совместно с удобным плагином для обзора кода CodeReview
• Сервером для Gitу меня служит такая программка, написанная на Java, как Scm-Manager– контроль репозиториев. Удобно ставится, настраивается через простейший web-интерфейс – запустили и все работает.
• TortoiseGit – клиент для Git под Windows на основе «черепахи». Кто работал с Subversion – тот знает, что есть такой TortoiseSVN, TortoiseGIT и пр.
• И, главный виновник торжества – 1С:Предприятие 8.3. Это то, что нам позволяет полностью выгрузить конфигурацию в файловую систему.

Связь коммита с задачей

Рассмотрим простейшие понятия. Может, это даже больше относится к системам управления требований (задач).

У меня есть настроенная синхронизация хранилища 1С:Предприятия с GIT, и, в дальнейшем, это передается уже в систему управления задач Redmine.

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

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

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

В результате для задачи в системе Редмайн в поле «Связанные редакции» вы получите такую картинку – можно перейти, посмотреть, какой код изменялся. Это очень удобно.

Ветвление

Эта тема очень большая и актуальная.

Самих способов ветвления три. Остальное – их комбинации.

• Ветвление по функционалу.

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

• захватить корень,
• добавить новый объект
• отпустить корень
• Работать над объектом
• Если он кому-то понадобится – отпустить
• Потом опять захватить и т. д.

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

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

• Следующий способ ветвления – ветвление по пользователям. Тоже применяется. Например, у вас есть удаленный разработчик, или какой-то новый молодой специалист. И у вас стоит компромисс – или дать доступ на запись в хранилище, или… По мне, так это – «пусти козла в огород»… Если не проконтролировать, что он там изменял, завтра с базой будет совсем плохо. Одно дело, если этот «специалист» рядом сидит, и его проконтролировать и сделать ему какие-то замечания не составляет труда. А если это удаленный разработчик и он уехал куда-то в Таиланд – то… хранилище не поможет вам этого разработчика проконтролировать. Только если дать ему конфигурацию хранилища на чтение, а потом вам или ему мучиться с объединением. Никто не захочет дальше работать с вами. А возможность использовать трехстороннее сравнение позволяет определить именно те объекты, которые были дважды изменены, и быстро, с помощью различных инструментов типа kdiff3, их объединить. Это дорогого стоит.
• Ну и самый последний, не любимый мною способ ветвления – это ветвление по задачам. На каждую задачу открывается отдельная ветка. Потом — вы задачу решаете, ветку закрываете. Поверьте, если задача у вас не долгоиграющая, и она закрывается за один-два коммита – лучше отдельную ветку под нее не выделять, потому что в определенном смысле вы можете уйти совершенно в другую степь. В этом смысле ветвление – это «зло». Может вдруг оказаться, что в ветке, предназначенной для решения одной задачи – вы «на автомате» начнете реализовывать и другие задачи, для других подсистем и в один момент времени может оказаться, что ваша основная ветка стала называться не trunk, а «суперРазработка252». Разобраться, где что, будет уже сложнее.

Обзор кода

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

Конечно, это решается административным путем – пришел утром на работу, сделай обновление конфигурации из хранилища. Посмотрел, что у тебя в хранилище 10 объектов измененных, смотришь «А кто их изменял?». Если там два программиста – еще можешь спросить/узнать, что же там изменяли. А если больше двух? Здесь начинается проблема коммуникаций, и понять, кто же что изменял в хранилище, довольно-таки трудно.

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

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

Авторство кода

Самая интересная картинка – «Авторство кода».

В стандартном хранилище от 1С я не знаю способа, как получить «Кто же писал эти строки?»

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

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

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

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

Практика применения при выгрузке конфигурации в 8.3
Ложка дегтя

Сразу скажу, просто так взять и использовать выгрузку у вас не получится.

• Во-первых, ваша древовидная конфигурация превращается в файловой системе в линейный список.
  То есть, например, наиболее распространенная конфигурация УТ 10.3 – в разобранном виде превращается в 9451 файл в одной папочке. Причем ориентироваться по таким файлам просто невозможно (Документ.Реализация.МодульОбъекта.txt). С учетом того, что по алфавиту там сначала идут роли, найти в этом списке нужный объект очень затруднительно.
  • Соответственно, для этого я использую такой метод – я выгружаю файл конфигурации в отдельную папку, а потом из этой папки копирую файлы в хранилище GIT с учетом структуры каталогов. То есть эта структура повторяет то же дерево, которое у нас есть в конфигурации. Для этого у меня есть специальная обработка, которая по точке, методом «МассивРазложитьВСтроку» разносит файлы по каталогам. Это позволяет наглядно посмотреть. Опять-таки, нам в скором времени обещают в 8.3 ускорение работы с хранилищем, но, в принципе, при такой выгрузке с помощью GITвсе равно то же самое получается. Вы получаете ту же самую информацию – только быстро, удобно… даже при ее линейном формате. Так же, как это в хранилище и есть.
• Еще немаловажный факт – обычные формы выгружаются во внутреннем формате. То есть файл форм «закодирован» во внутренний формат 1С. Почему так сделано, мне, если честно, непонятно, так как в 8.2, допустим, у нас есть возможность получить модуль формы. Еще раз уточню: это касается только «толстых» форм. Я понимаю, что управляемые формы «побеждают весь мир», но УПП 2.0 еще не вышло, а у нас еще есть УПП 1.3, которое еще на «толстых» формах – живет и здравствует.
  • для этого есть обходные пути – есть такая чудная программа V8Unpack, которая распаковывает эти формы на внутреннее представление формы и на модуль формы. Соответственно, эта проблема просто обходится.
• Огромный объем выгрузки ролей в файлы.
  • для меня стало неожиданностью, когда я увидел, что, оказывается, роли выгружаются полностью, то есть имеется возможность указать для роли «Право по умолчанию» на объекты. Но, все равно, роли выгружаются полностью. И, соответственно, есть проблема в хранилище. У вас, допустим, роль не захвачена, и в то же время вы добавили какой-то реквизит в документ. Вроде как только изменения документа идут, да? Если вы сделаете выгрузку конфигурации в XML,то у вас окажется, что у всех ролей есть изменения – добавлено новое право на новый реквизит (явное разрешение на чтение этого реквизита). Подчеркну, в выгрузке XML – изменение во всех ролях!
  • Кроме этого, есть еще проблема, связанная с тем, что роли из всего каталога конфигурации занимают наибольший размер.
• И, конечно же, нет выборочной выгрузки/загрузки. Я не говорю даже о скорости загрузки/выгрузки. Но хотя бы выборочно выгружать, чтобы как раньше – можно было частично выбирать – выгрузить только документы или определенные документы.У нас бы стало проще с работой, не так долго нам пришлось бы выгружать/загружать эти данные, мы могли бы быстрее получать готовый результат.

Выводы

Соответственно, краткие выводы:

1. Как альтернатива, вы можете использовать сейчас и GIT, и SVN, и BZR, и fossil – это все поддерживаемые системы. Если говорить про какую-то интеграцию с системой баг-трекинга, то здесь побеждает SVN и GIT. Если вы еще захотите ветвления – то, конечно же, без альтернативы GIT. То есть вроде как у вас есть альтернатива – но, тем не менее, альтернативы нет.
2. Синхронизация хранилища 1С с git работает.
3. Ветвление, в принципе, работает.
4. Единственный минус – просто так взять и воспользоваться в этом плане 8.3, к сожалению, нет возможности, то есть без доработок не обойтись

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

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

upd:

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

Стали более развиты средства по синхронизации хранилища 1С с git, опробованы приемы использования разработки по методики git-flow, с отказом от хранилища (удачно).

p.s.: Не можете применить git, примените хотя-бы хранилище.

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

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.