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

02.06.21

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

Для чего нужно ветвление доработки типовой конфигурации? Как быть с расширениями? Как все это потом связать в одно целое?

Вводные условия

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

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

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

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

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

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

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

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

В процессах доработки, внедрения и сопровождения участвуют только сотрудники ИТ-отдела организации: до 7-ти разработчиков, до 5-ти сотрудников сопровождения (они же консультанты, методологи и тестировщики). При этом, та же команда сопровождает все другие используемые информационные системы организации, кроме технологических. Стандартный "заводской" набор.
Контуры автоматизации разработки, тестирования и развертывания (CI/CD) не используются - масштаб не тот, относительно больших конфигураций "с нуля" не разрабатывается. Есть набор "дымовых" тестов, помогающий при обновлениях и все.

Подходит очередь автоматизации нового контура учета и возникает дилемма.

Требуется одновременно:

  • достаточно интенсивно дорабатывать конфигурацию и расширение в рамках внедрения нового функционала;
  • дорабатывать боевую часть функционала (отложенные при прошлых внедрениях моменты) и исправлять там ошибки.

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

 

Проблемы Git'а и EDT при доработке типовых конфигураций

Само собой, первое что приходит здесь на ум - Git с его ветками. Действительно, решение в мире 1С современное, модное и, на первый взгляд, вполне подходящее под сложившуюся ситуацию.
Но конфигуратор, наиболее привычная среда разработки для пока подавляющего большинства разработчиков 1С, не может работать с Git'ом.
Git, вернее достаточно большое число его клиентов, может работать с отдельно взятыми файлами, в которые сейчас можно выгрузить конфигурацию и/или расширение.
Но, в случае использования такого подхода, процесс разработки грозит стать достаточно сложным и долгим. Выгрузка/загрузка в файлы конфигураций уровня ERP занимает очень продолжительное время. Кроме того, разработчикам придется учиться очень тщательно контролировать работу с Git'ом через файловую систему или учиться работать с большим количеством нового инструментария. И я не уверен, что не возникнет еще одной проблемы, которая описывается чуть ниже.

Напрашивается вроде бы очевидное решение - EDT.
Среда разработки, пусть и относительно новая, но вполне годная для достаточно быстрого освоения разработчиками, с большим количеством "плюшек", которых лишен старый добрый конфигуратор. Сейчас уже поддерживаются самые свежие релизы платформы. Работа с Git'ом поддерживается без лишних "танцев с бубном". Есть возможности расширения функционала с помощью плагинов. И прочая, и прочая...

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

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

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

 

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

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

Разветвленная разработка в конфигураторе

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

Применительно же к нашим вводным условиям и через призму рекомендаций ИТС выглядеть все должно примерно так:

  1. Перед разветвлением разработки желательно обновить боевую базу до последнего релиза. В процессе разветвленной разработки до слияния веток делать это нежелательно, поскольку может значительно затрудниться сам процесс слияния. А одновременно обновить и боевую базу и базу ветки не получится, поскольку в конфигурации поставщика базы ветки должна сидеть боевая конфигурация на момент разветвления.
     
  2. В определенный момент из основного хранилища (Хранилище № 1) конфигурации получаем файл поставки, на основании которого создаем центральную базу нашей новой ветки (см. статью). В последнем помещении в хранилище № 1 ставим метку, которая будет показывать нам точку разветвления. Просто для себя, на всякий случай. Особого смысла в ней нет, поскольку в конфигурации поставщика нашей ветки сидит как раз последнее состояние этого хранилища на момент разветвления.
     
  3. В этот же момент из хранилища расширения боевой базы (Хранилище № 2) получаем файл cfe, на основании которого делаем расширение в центральной базе новой ветки. Опять же, в хранилище-родителе (№ 2) помечаем меткой точку разветвления. Вот здесь это сделать уже обязательно! А еще неплохо бы сохранить этот самый исходный cfe-файл. Почему - поясню позже.
     
  4. Из центральной базы новой ветки создаем новые хранилища основной конфигурации (Хранилище № 3) и расширения (Хранилище № 4)
     
  5. В этих хранилищах (3 и 4) ведем разработку в рамках автоматизации нового контура учета.
     
  6. Параллельно в хранилищах 1 и 2 дорабатываем и исправляем ошибки боевого функционала.
     
  7. По завершении разработки и тестирования в рамках автоматизации нового контура учета обновляем основную конфигурацию ветки (Хранилище № 3) с помощью нового файла поставки, полученного из боевой конфигурации (Хранилище № 1). Как это делать подробно описано все в той же статье.
    В итоге получим в хранилище № 3 все изменения боевой базы и функционал нового контура учета.
     
  8. Обновляем расширение в конфигурации ветки (хранилище № 4) с помощью исходного файла cfe, полученного в момент разветвления, и нового файла cfe, полученного из расширения боевой базы на текущий момент (хранилище № 2). Как именно это сделать проще - опишу чуть ниже.
     
  9. Тщательно тестируем "слитые" конфигурации в базе ветки.
     
  10. Обновляем основную конфигурацию и расширение в боевой базе с помощью обычного "Сравнить, объединить...", используя cf и cfe-файлы, полученные из базы ветки после пункта 9. Фиксируем изменения в хранилищах № 1 и 2. Ликвидируем базу ветки вместе с хранилищами 3 и 4.

 

Слияние веток расширения

Теперь вернемся к пункту 8. Дело в том, что расширения не обладают функционалом основной конфигурации в плане создания, хранения и использования при обновлениях конфигурации поставщика. В лучшем случае, в конфигураторе можно использовать сравнение/объединение для расширений.
Но при таком подходе очень легко затереть те изменения, которые были внесены в расширение в Хранилище № 2 изменениями, внесенными в Хранилище № 4.
Для качественного слияния двух веток нужна общая отправная точка - начало новой ветки из пункта 3. Чтобы сравнением с ней двух файлов cfe в настоящий момент (Хранилище № 2 и Хранилище № 4) найти тонкие места в виде дважды измененных свойств и уделить им максимальное внимание при слиянии веток.

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

Итак, как же действовать:

  1. Получаем актуальные файлы cfe из хранилищ № 2 и 4.
     
  2. Получаем нашу "отправную точку" - файл cfe перед разветвлением - из помеченного нашей меткой в предыдущей главе помещения в хранилище № 2 (если, конечно, вы не сохранили его еще тогда, при разветвлении):
     
  3. Берем любую базу (которую вы, например, использовали для разработки) отключаем ее расширение от хранилища. После чего последовательно загружаем в расширение наши три файла и выгружаем каждый раз расширение в файлы в разные папки - "начало ветки", "боевая" и "ветка":




    Наша цель - получить три папки с файлами для загрузки их в проекты EDT
     
  4. Открываем EDT, создаем три новых проекта расширений из наших папок в одной рабочей области, указывая соответствующие наименования проектов. Проекты расширений в EDT могут существовать и без родительских проектов.
    Так как объемы расширений обычно значительно меньше больших конфигураций (если, конечно, следить за ними и не допускать огульного массового расширения ненужных объектов), то проекты создаются достаточно быстро:


     
  5. Теперь осталось воспользоваться тем самым трехсторонним сравнением/объединением, ради которого все и затевалось. Выбирать главный источник для сравнения/объединения следует исходя из соображений наибольшего числа изменений в нем с момента разветвления. Для нашего случая - это проект "ветки":


     
  6. В итоге получим примерно следующую картину:

     
  7. То есть, EDT самостоятельно отметила нам объекты, которые безусловно должны быть перенесены в общее расширение. Кроме того, с помощью фильтра внизу формы сравнения можно ограничить список различий до тех объектов, объединение которых вызвало у EDT затруднение. Это как раз наши дважды измененные объекты - и в хранилище № 2, и в хранилище № 4.
    Их объединение EDT предлагает провести нам вручную:


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

     
  8. Как я уже говорил, у нас не стоит цели получить результат объединения в проекте EDT. Нам это надо сделать в конфигураторе, а EDT нам нужен в качестве "подсказки".
    Поэтому открываем конфигуратор, загружаем в конфигурацию расширения тот файл cfe, который мы получили из ветки (хранилище № 4). Запускаем сравнение/объединение расширения с файлом cfe, который мы получили из боевой базы (хранилище № 2).
    Снимаем все флажки и аккуратно расставляем их в соответствии с тем, как установила нам их EDT (два монитора очень помогут!). А также аккуратно повторяем все манипуляции по ручному слиянию дважды измененных объектов:


    Ах, если бы можно было бы из EDT сохранить настройки объединения, а в конфигураторе применить их... Но увы, эти настройки объединения конфигуратор не понимает.
     
  9. Собственно, все. Результат объединения сохраняем в cfe, сравниваем/объединяем с ним расширение в боевой базе, помещаем все изменения в хранилище.
     

Послесловие

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

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

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

Всем спасибо за внимание! Особенно тем, кто осилил сей опус до конца!

 

Другие мои публикации, возможно, достойные вашего внимания:

  1. [БЕСПЛАТНО] "Откат" данных без транзакций. Расширение для легкого возврата к "исходному" или выбранному состоянию после любых изменений данных
     
  2. Быстрое формирование наборов данных Объект схемы СКД
     
  3. Комплексный контроль остатков. Для одного или сразу нескольких логически связанных регистров накопления. Универсальное решение уровня данных для контроля не только складских остатков
     
  4. Подсистема "Диспетчеризация обслуживания". Предварительная запись, планирование, регистрация и анализ этапов обслуживания или производства для любых конфигураций на платформе 8.3.6+ с использованием планировщика
     
  5. Даты запрета изменения по пользователям в режиме "Общая дата" для БП 3, ЗУП 3 и других конфигураций на УФ, использующих БСП

ветвление расширение типовая конфигурация слияние трехстороннее объединение поддержка поставка хранилище Git EDT

См. также

Системы контроля версий для 1С-разработчиков.

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

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9157    78    4    

110

Особенности национального Workflow: Github Actions и OneScript

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

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

25.03.2024    1228    bayselonarrend    3    

37

Автоматизация процесса разработки с помощью сервиса GitFlic

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

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

05.03.2024    1878    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

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

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

05.02.2024    3790    bayselonarrend    15    

61

Насколько глубок 1С-ный GitHub?

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

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

22.01.2024    7852    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

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

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

17.01.2024    2791    kamisov    17    

57

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

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

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

26.12.2023    1350    ardn    1    

26

Git Code Review - инструмент для рецензирования кода

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

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3964    59    salexdv    26    

81
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. FreeArcher 158 08.06.21 08:17 Сейчас в теме
Спасибо за статью, у нас такой же подход к разработке. УТ11 конфа (новые объекты) + расширение. Только отдел уже 9 разработчиков (и хотелось бы ещё расширят штат за счет удаленщиков). В хранилище, самые популярные объекты всегда захвачены, буквально очередь до драки :)

Я сейчас смотрю в сторону EDT. Я прочитал ваши замечания, и да есть такое видел. Не знаю, аукнется или нет, но у нас в типовых объектах нет изменений, кроме новых реквизитов.

Ваш способ кажется очень громоздким, у нас большинство задач короткие 1-12 часов, обновление рабочей почти каждый день. И каждый раз делать 3х стороннее сравнение много времени будет теряться.

На EDT начали разрабатывать типовые конфигурации, должно быть все нормально уже, я надеюсь...
native-api; Алексей Воробьев; +2 Ответить
2. Алексей Воробьев 291 08.06.21 08:43 Сейчас в теме
(1) Спасибо за отзыв.
Ваша ситуация совсем не подходит под описанный метод. Множество коротких задач, которые должны попадать в рабочую среду в короткие же сроки - это как раз целиком одна из веток в описанной концепции.
Вторая ветка должна появиться при появлении задачи внедрения большого программного блока, которым в той же УТ раньше вообще никак не пользовались, но поступил запрос на его внедрение. А внедрение предполагает масштабную доработку. Скажем, от 100+ часов.
Вот в этой ситуации и следует применять описанный подход, когда рабочая база дорабатывается по-мелочи одновременно с разработкой нового функционала, который попадет в рабочую среду только после его полной разработки, тестирования и слияния веток...

Песню про то, что вендор перешел на разработку типовых конфигураций в EDT, я слышал (преподносилось исключительно как инсайды) на конференциях Инфостарта и в 2019, и в 2020 году. Но, по крайней мере, ни в ERP (а, соответственно, ни в УТ, ни в КА), ни в ЗУПе я этого не заметил.
Ведь если бы это было так, то описанных в начале статьи отличий (артефактов) после "прогонки" конфигурации через проект EDT не возникало бы. Все эти "артефакты" прилетали бы в конфигурации еще от вендора.
Или при выпуске релизов вендором используется дополнительное ПО, избавляющее от подобных артефактов конфигурацию...

В любом случае, если вы не приняли решение зафиксировать у себя версию вендора и более не обновлять рабочую базу, а только самостоятельно ее дорабатывать, то использовать EDT нельзя! Это очень повредит при необходимости обновления.
Если же база более не обновляется, а только дорабатывается собственными силами (а сейчас такое редкость), то EDT и Git - то что доктор прописал :-)
Оставьте свое сообщение