От экспертов «1С‑Рарус»: Работа с EDT и Git — от миграции из Хранилища 1С до групповой разработки

Введение

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

Помимо привычной связки Конфигуратор + Хранилище 1С теперь также полноценно используется 1C:EDT + Git. Альтернативной схемой является разработка при помощи Конфигуратора в паре с GIT. Давайте рассмотрим организацию процессов разработки решений в условиях гетерогенной среды, когда может использоваться как Конфигуратор, так и 1C:EDT.

Что такое Git

Чтобы разобраться, что такое Git, давайте для начала поймем, какие вообще существуют типы систем контроля версий:

• Локальные системы контроля версий хранят информацию об изменениях на одном локальном компьютере разработчика.

  

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

  

  К таким системам контроля версий относится Хранилище 1С:

  

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

  

К таким системам контроля версий относится GIT.

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

В качестве удаленного сервера чаще всего выступают специальные платформы для хостинга проектов, такие как GitHub/GitLab, а располагаться такой сервер может как в облаке GitLab/GitHub, так и на серверах внутри компании (в этом случае платформа, например gitlab, является отчуждаемой).

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

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

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

Старт работы в 1C:EDT — перенос истории изменений в Git

Предположим, что мы решили перенести контроль версий проекта из Хранилища 1С в Git. Здесь существует несколько вариантов того, что нам делать с уже накопленным списком версий в Хранилище 1С.

Не переносить старые версии в Git

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

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

Перенести всю историю изменений из хранилища в Git

Принцип переноса следующий:

• Создать новый локальный репозиторий Git.
• Для каждой версии из хранилища:
  • Сохранить версию в файл cf.
  • Загрузить полученный cf в информационную базу.
  • Выгрузить конфигурацию информационной базы в файлы в каталог с созданным репозиторием Git.
  • Если перенос будет производиться для дальнейшей разработки в 1C:EDT, то дополнительно еще необходимо конвертировать выгрузку в файлы в формат 1C:EDT при помощи утилиты ring. Это необходимо по причине разных форматов выгрузки Конфигуратора и 1C:EDT.
  • Сделать фиксацию изменений в локальной системе контроля версий (git commit).
• Дополнительной задачей является сопоставление пользователей Хранилища с пользователями созданного Git‑репозитория для того, чтобы не просто видеть историю изменений, а делать это в разрезе пользователей.
• Полученный локальный репозиторий далее отправляется на удаленный сервер.

Для автоматизации подобного сценария можно воспользоваться собственными скриптами или сценариями, используя запуск 1С в пакетном режиме или в режиме автономного сервера (ibcmd). Подробней о запуске 1С в пакетном режиме можно почитать на ИТС (its.1c.ru/db/v838doc#bookmark:adm:TI000000493), про автономный сервер и утилиту ibcmd можно почитать тут its.1c.ru/db/v8314doc#bookmark:adm:TI000000894.

Похожий сценарий мы реализовывали в нашем разработческом контуре при помощи решения «1С‑Рарус: Сценарный обработчик конфигураций» (сокращенно просто СОК):

Сценарий умеет перегружать историю изменений из Хранилища конфигураций 1С в Git, а также запускать проверку новых изменений в SonarQube. Однако, сценарий можно использовать также и для стартового переноса изменений при переходе на 1С:EDT. В основном шаге «Выполнить алгоритмы» написан код, который автоматизирует все вышеописанные действия по итерационному сохранению версий из Хранилища и фиксацию изменений в Git:

Помимо самописных сценариев и скриптов также можно воспользоваться специальной конфигурацией, которую предоставляет фирма 1С под названием «1С:ГитКонвертер». Подробней можно почитать на ИТС (its.1c.ru/db/metod8dev/content/5937/hdoc).

После переноса истории всех изменений проекта в новую систему контроля версий получим следующую схему:

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

Сокращение версий Хранилища

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

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

Для начала, создать проект в 1С:EDT и подключиться к репозиторию Git. Далее мы будем рассматривать именно этот вариант работы, т. к. сами им пользуемся, но есть и варианты вести разработку в Git без использования 1C:EDT о чем было подробно рассказано в статье «Интеграция СППР и Git для учёта клиентских требований и управления разработкой 1С».

Порядок перехода в 1С:EDT для разработчиков

Далее будет показан процесс перехода разработки на 1C:EDT на примере разработки проекта «1С-Рарус: Сценарный обработчик конфигурации», которая происходила у нас в команде. В качестве платформы для управления удаленными репозиториями будет использоваться GitLab. Нижеописанные действия производятся каждым разработчиком на своей локальной станции. Также, если команда уже ведет разработку на 1C:EDT и необходимо перейти на новую версию платформы 1С, то порядок действий для рядовых разработчиков (за исключением ведущего разработчика, которому необходимо подготовить репозиторий к переходу на новую версию платформы) будет идентичен.

Версии 1C:EDT и платформы

Для начала необходимо регламентно определить версию 1C:EDT и платформы, используемой для разработки. Каждый переход на новую версию происходит одновременно всеми разработчиками, которые выполняют работы на проекте.

После того, как с версиями определились, необходимо установить:

• 1C:EDT, за обновлениями и последними версиями можно следить на releases.1c.ru/project/DevelopmentTools10.
• Git с официального сайта проекта git-scm.com/downloads.
• Платформа 1С необходимой версии скачивается с releases.1c.ru/project/Platform83.

Далее необходимо получить доступы к аккаунту на платформе GitLab/GitHub, на которой размещается репозиторий Git:

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

На платформе GitLab есть система прав доступа, поэтому необходимо убедиться, что к проекту есть доступ:

Разворачивание проекта 1C:EDT из Git

После установки всех необходимых инструментов, создаём новый проект через программу 1C:EDT start (устанавливается вместе с дистрибутивом 1C:EDT) и запускаем его:

Далее в редакторе проекта надо выбрать импорт конфигурации из Git и клонировать существующий URL:

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

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

На экране выбора каталога проекта необходимо создать подкаталог в каталоге проекта:

Далее будет произведено клонирование проекта из репозитория Git:

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

На остальных шагах необходимо оставить настройки по умолчанию. В результате получим проект в 1C:EDT, импортированный из репозитория Git:

Получение демо-базы для ведения разработки

Для ведения полноценной разработки в 1C:EDT нам также необходима подключенная к проекту информационная база.

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

Полученную демо-базу необходимо загрузить в информационную базу на локальном компьютере разработчика. Для этого в проекте 1C:EDT в панели информационных баз добавляем новую информационную базу:

После чего загружаем информационную базу из файла dt, полученного на предыдущем шаге:

Связывание проекта 1C:EDT с информационной базой

В общем случае, схема связывания проекта 1C:EDT с информационными базами 1С будет иметь следующий вид:

На схеме видим, что приложения являются промежуточной сущностью между проектом 1C:EDT и информационными базами 1С. Синхронизация данных при этом может происходить в обе стороны, как из информационной базы в проект, так и наоборот. Однако при схеме работы через 1C:EDT мы фиксируем изменения в системе контроля версий именно через файлы проекта, поэтому проект 1C:EDT является главным.

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

Для связывания проекта 1C:EDT с приложением необходимо воспользоваться специальной панелью приложений. Сначала включаем ее видимость:

Затем создаем новое приложение с флагом «Загрузить конфигурацию полностью»:

В результате в панели приложений можно будет увидеть все связанные с проектом 1C:EDT информационные базы:

После связывания проекта и информационной базы необходимо настроить конфигурацию запуска на используемую версию платформы 1С. В данный момент это 8.3.25. Перейти к конфигурациям запуска можно из подменю запуск:

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

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

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

Альтернативный путь разработки

Существует и альтернативный вариант внесения изменений. Когда основной средой разработки все еще остается Конфигуратор. В этом случае разработка ведется в одной из связанных информационной баз:

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

1C:EDT выдаст окно сравнения, где можно будет посмотреть, какие объекты будут затянуты из конфигурации в проект, а также разрешить возникшие конфликты:

После этого объединяем и проверяем, что все внесенные изменения перенеслись в 1C:EDT:

Последним действием необходимо обновить все связанные с проектом приложения, чтобы изменения распространились на все подключенные информационные базы:

Принципы ветвления работы

Итак, у нас есть проект 1C:EDT подключенный к репозиторию Git и связанный с информационной базой 1С через приложение. Достаточно ли этого для старта разработки? Для полноценной разработки нам необходимо также разобраться с особенностями системы контроля версий, такими как ветвление и объединение изменений. Git предоставляет возможности ветвления разработки, чем мы и пользуемся в рамках разработки проекта «1С‑Рарус: Сценарный обработчик конфигураций». Давайте попробуем подробней разобраться, что это такое.

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

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

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

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

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

Когда один разработчик работает над несколькими задачами

Предположим, что у нас есть репозиторий Git, разработчик подключился к нему в базовую ветку. На схеме базовой веткой будет ветка common. Стоит отметить, что в общем случае базовая ветка вовсе не обязательно должна иметь имя master, main и т. д.

В момент подключения к удаленному репозиторию в определенную ветку, репозиторий скопировался на локальный компьютер разработчика, ветка common указывает на версию «Версия 3»:

Продемонстрируем это также в реальном репозитории на тестовой ветке common. Внесем туда 3 изменения в 3 разных версиях. В 1C:EDT для этого есть специальная перспектива, которая так и называется — GIT:

В выбранной перспективе можем просматривать список отслеживаемых веток Git и управлять ими, смотреть историю выбранной ветки, фиксировать изменения и отправлять их в удаленный репозиторий и так далее:

Изменим одну из функций общего модуля проекта для демонстрационного примера:

После внесения изменения необходимо переключиться на перспективу GIT и перейти в окно «Индексирование Git». В окне индексирования будут показаны все измененные файлы, необходимо нажать кнопку «Добавить все файлы в индекс»:

Далее необходимо написать сообщение коммита и нажать «Фиксировать», если хотим внести изменения только в локальную ветку Git или же «Фиксировать и отправить», если хотим внести изменения и в удаленную ветку:

Аналогично внесем еще 2 изменения, чтобы история версий проекта выглядела следующим образом:

Предположим, разработчик работает над задачей, он внес новое изменение на своей локальной станции и зафиксировал его:

В этом случае на его локальном компьютере создается версия 4:

Граф изменений в 1C:EDT будет следующим:

Далее разработчика просят выполнить срочную задачу и выпустить патч, но он не должен в себя включать изменения версии 4. Без механизма ветвления нам нужна была бы еще одна информационная база или проект 1C:EDT, куда мы бы загрузили версию 3 и так решили бы задачу, выпустив патч. И в будущем изменения из этой копии базы необходимо было бы переносить вручную в основной проект.

При использовании ветвления мы можем создать отдельную ветку от версии 3. В общем случае ветка будет называться номером задачи из учетной базы задач. Для демонстрационного примера назовем ветку task_1. Внесем изменения в код и зафиксируем версию «Версия 5»:

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

Граф изменений в 1C:EDT будет следующим:

Теперь у нас есть отдельная ветка, в которой мы решили задачу «Задача 1» (ветка task_1), на базе «Версии 3», а также ветка common, в которой мы тоже вносили изменения и создали «Версию 4».

Далее, все что нам остается сделать, чтобы изменения из позадачной ветки оказались бы в базовой ветке — это перенести их. Система контроля версий Git предоставляет несколько механизмов для переноса изменений. Подробнее мы рассмотрим их далее, а пока давайте выберем самый популярный способ переноса изменений — тот, которым мы сами пользуемся на проекте «1С‑Рарус: Сценарный обработчик конфигураций», — механизм слияния веток. Он предполагает слияние любых двух веток репозитория при условии наличия у них какой-то общей родительской версии. По схожему принципу работает обновление от конфигурации поставщика в Конфигураторе.

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

В нашем случае такой родительской версией будет «Версия 3». Таким образом, мы можем произвести трехстороннее объединение ветки task_1 в ветку common, объединив все изменения из «Версии 5» и «Версии 4». В этом случае Git создаст специальный коммит слияния, который и отобразит данную операцию:

Граф истории изменений в 1C:EDT будет выглядеть следующим образом:

Все изменения в коде перенеслись автоматически, так как мы меняли разные участки кода:

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

Перенос изменений в Git

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

1. Когда мы разрабатываем в позадачной ветке какую-то большую задачу и хотим актуализировать позадачную ветку всеми изменениями, которые были внесены за время разработки задачи в базовой ветке другими разработчиками. В этом случае мы переносим изменения из базовой ветки в позадачную.
2. При завершении разработки в позадачной ветке мы наоборот переносим изменения из позадачной ветки в базовую, то есть ту ветку, от которой мы начали разработку задачи.

Сделать это можно следующими способами:

• перемотка (fast-forward);
• слияние (merge);
• перебазирование (rebase).

Перемотка (fast-forward)

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

Это самый простой случай, никаких дополнительных действий нам выполнять не потребуется, указатель ветки просто перейдет на версию 4:

В 1С:EDT, когда разработчик переключится на базовую ветку common и выполнит операцию объединения веток, к примеру, слиянием, он увидит сообщение о том, что произошло автоматическое объединение методом перемотки:

Слияние (merge)

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

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

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

Разрешение конфликтов

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

А в версии 5 так:

Получается, что изменена одна и та же строка кода. Система при этом не сможет применить слияние автоматически. В 1C:EDT будет выдано специальное окно сравнения объединения ветки common с веткой task_1:

Будет установлен фильтр «Показывать потенциальные проблемы», то есть нам необходимо будет пройти по всем объектам в окне сравнения и произвести их объединение вручную. В приведенном примере был изменен общий модуль br_ОбщегоНазначения. При нажатии на иконку с шестеренкой 1C:EDT выдаст окно объединения модуля:

Средняя часть окошка это результат ручного труда разработчика.

Безусловно, большим преимуществом 1С:EDT является удобный интерфейс для объединения форм, макетов и других сложных сущностей. Для демонстрации внесем изменения в ветке task_1 в синоним команды формы:

В ветке common также изменим этот же синоним:

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

Это выгодно отличает процесс объединения изменений в 1C:EDT для форм и других сложных сущностях от Конфигуратора 1С, или же от объединения исходных xml файлов при помощи сторонних программ.

После нажатия кнопки объединения мы получим заветную версию слияния веток и изменения будут считаться перенесенными:

Перебазирование (rebase)

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

Вернемся к ситуации, которая была описана для слияния веток. У нас есть изменения, которые мы внесли в позадачную ветку task_1, а также изменения, которые были внесены в базовую ветку common:

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

Схематично мы увидим изменения родителя для версии 4:

Граф изменений в 1C:EDT будет выглядеть следующим образом:

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

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

Когда несколько разработчиков работает над несколькими задачами

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

Возникнет новая версия (на схеме это «Версия 4»):

При этом одновременно с ним второй разработчик также внес изменения в код и зафиксировал их. Возникнет «Версия 5»:

Далее разработчик 2 отправил изменения в удаленный репозиторий:

С точки зрения разработчика 1, в его локальном репозитории от версии 3 была создана версия 4, а вот с точки зрения удаленного репозитория теперь от версии 3 создана версия 5. Поэтому при попытке отправить изменения в версии 4 в удаленный репозиторий первым разработчиком, он не сможет этого сделать. Будет выдано сообщение об ошибке отправки данных:

Схематично можем себе представить вышеописанную ситуацию следующим образом:

Граф изменений в 1C:EDT для разрабочика 1 будет выглядеть следующим образом:

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

Итак, представим, что разрабочик 1 и разработчик 2 теперь начали вносить и фиксировать изменения каждый в своей позадачной ветке. У разработчика 1 в его локальном репозитории теперь есть ветка task_1, в которой он зафиксировал версию 4, а у разработчика 2 есть ветка task_2, в которой он зафиксировал версию 5:

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

При окончании разработки каждый из разработчиков отправляет и объединяет свои изменения в базовую ветку. При этом тот, кто первый отправит изменения в удаленный репозиторий не увидит никаких различий в ветках и изменения просто перенесутся из позадачной ветки в базовую быстрой перемоткой, то есть указатель ветки common переместится на Версию 4:

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

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

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

Улучшение «качества жизни» разработчиков

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

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

Однако потом вспоминаем, что добавили в индекс не все измененные файлы, или же не дописали несколько важных строк кода. В этом случае мы можем не создавать новую версию, а изменить последний коммит, добавив в него новые изменения (операция git amend). Для этого в панели «Индексирование Git» мы как обычно добавляем файлы с изменениями в индекс, однако выбираем опцию «дополнить». В этот момент в поле сообщения коммита выведется сообщение последнего зафиксированного изменения, мы можем дополнить его и зафиксировать:

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

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

Иногда возникает ситуация, когда мы вовсе хотим полностью отменить одно или несколько изменений и «откатить» все что мы сделали (операция git reset). Для этого в 1C:EDT на панели «История» мы можем выбрать соответствующий пункт в контекстном меню той версии, до которой мы хотим откатиться:

Здесь главное разобраться в «степени жесткости» отмены изменений:

• Мягко. Это вариант, когда изменения отменяются только в системе контроля версий, в локальных же файлах проекта все останется как было. Все измененные файлы при этом будут добавлены в индекс:

  

• Средне. Этот вариант похож на предыдущий с тем лишь отличием, что измененные файлы не будут проиндексированы:

  

• Жестко. В данном варианте изменения полностью удалятся, как из истории версий, так и из локальных файлов проекта:

  

Проверка и контроль изменений при объединении веток

Как уже говорилось ранее, в качестве удаленного сервера для хостинга репозитория Git мы используем GitLab, развернутый на сервере компании. Важной функциональностью, которой мы пользуемся, является возможность вносить изменения в базовую ветку только после верификации от ведущего разработчика. Для этого применяется «запрос на слияние» или же «merge request». Идея в том, чтобы не просто слить изменения из позадачной ветки в базовую, а пройти верификацию изменений ведущим разработчиком проекта. При таком подходе стоит вопрос, кто будет заниматься объединении изменений, ведущий разработчик или же разработчик, который закрыл задачу? В нашем случае за объединение и разрешение конфликтов отвечает последний, на плечи же ведущего разработчика ложится необходимость проверить правильность объединения.

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

В базовой ветке изменим синоним этого же элемента формы:

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

В интерфейсе GitLab в панели проекта можно перейти в меню merge request и создать новый запрос на слияние:

В качестве ветки-источника выберем ветку task_1, в качестве ветки-приемника выберем ветку common и нажмем кнопку сравнения:

Перед запросом на слияние есть возможность установить флажок удаления ветки-источника (delete source branch), что полезно в случае с позадачной веткой, так как она нам больше не нужна, а также флажок сворачивания всех версий (squash commits), на которой ветка-источник отличается от ветки-приемника в один коммит. Это может быть полезно, опять же, в позадачной ветке, когда разрабочик фиксирует изменения «для себя», а уже при помещений изменений в базовую ветку все «сжимается» в один коммит с красивым и емким сообщением:

После нажатия на кнопку создания запроса на слияние система проверит возможность автоматического слияния, найдет конфликт и выдаст соответствующее сообщение. Можно попытаться разрешить конфликты прямо в интерфейсе GitLab, это может быть полезно, когда изменения небольшие. Для этого нажимаем Resolve conflicts:

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

Если же все-таки конфликт не сложный, то можно воспользоваться кнопками Use theirs или Use ours для того, чтобы оставить в результате одну из версий строки с конфликтом, или же нажать Edit inline для ручного редактирования кода файла. После разрешения конфликта жмем Commit to source branch:

В том же случае, если конфликтов много и все они в сложных сущностях, то гораздо проще будет разрешить их непосредственно в IDE. Однако прав на редактирование базовой ветки у обычного линейного разработчика, как правило нет. Как же тогда поступить, чтобы правильно сделать слияние веток? Правильный ответ будет следующим: перед созданием merge request необходимо в 1C:EDT слить или перебазировать изменения из базовой ветки в позадачную, а не наоборот. Если мы использовали перебазирование, то для примера выше мы должны получить историю версий, как на следующей схеме:

Таким образом, мы сможем разрешить все конфликты еще до проверки в GitLab способом, описанным в разделе о разрешении конфликтов в удобном интерфейсе 1C:EDT.

После того, как запрос на слияние отправлен, ведущий разработчик получает уведомление, находит merge request в списке и может просмотреть список внесенных версий (вкладка commits), список изменений по файлам (вкладка changes). Если все изменения верифицированы, то нажать на merge. Или же не спешить с подтверждением и оставить комментарий для разработчика, который создал запрос:

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

Обновление «боевой» базы и выпуск релиза

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

1. Подключить «боевую» базу к проекту 1C:EDT.

В этом случае все что нам необходимо будет сделать — это обновиться из Git, то есть получить и слить все изменения из базовой ветки:

Если мы все делали правильно, то при обновлении базовой ветки конфликтов не должно быть. Далее необходимо обновить информационную базу новыми изменениями непосредственно через 1C:EDT:

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

2. Второй способ более регламентированный. Это формирование CF поставки и обновление «боевой» базы через операцию обновления конфигурации. В этом случае ведущий разработчик должен сначала обновить свою информационную базу способом из п. 1, затем зайти в нее в режиме Конфигуратора:

И далее сформировать файл поставки:

Подробней про формирование файлов поставки можно почитать на ИТС (its.1c.ru/db/metod8dev/content/2296/hdoc).

На базе cf поставки происходит сборка дистрибутива. Для этого в «1С‑Рарус: Сценарный обработчик конфигураций» мы разработали специальный сценарий сборки, который на верхнем уровне состоит из выполнения различных проверок перед сборкой, создания каталогов, подготовки всех необходимых файлов, включая файл документации, файл «Новое в версии», readme, файлы сервера защиты и т. д., а также непосредственно создания файлов поставки и копирования всех подготовленных файлов и копирования дистрибутива на сервер для публикации. Можно сказать, что сценарный обработчик конфигураций умеет «собирать сам себя»:

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

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

Сложности при переходе на новые релизы платформы 1С

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

Все дело в том, что каждый новый релиз платформы может менять формат выгрузки конфигурации 1С в файлы, а значит, что в проекте 1C:EDT мы увидим большое количество изменений:

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

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

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

После чего необходимо запустить новый проект 1C:EDT и выбрать «Импорт конфигурации и расширений из информационной базы»:

В окне выбора информационной базы выбираем базу, подключенную к старому проекту 1C:EDT:

Убеждаемся, что версия платформы указана новая. То есть, если ранее информационная база работала на версии 8.3.25, а потом мы перевели ее на версию 8.3.26, то указываем 8.3.26:

После импорта у нас есть новый проект, созданный не из Git, а из информационной базы, соответствующей последней версии проекта в Git и переведенной на новый релиз платформы 1С:

Осталось подключить проект к репозиторию и зафиксировать все изменения в файлах проекта. То есть, с точки зрения конфигурации 1С мы ничего не изменили, но вот с точки зрения проекта 1C:EDT в файлах выгрузки будут содержаться изменения, связанные с тем, что поменялся формат выгрузки.

Для этого сначала необходимо скопировать каталог .git и файлы .gitignore, .gitattributes из каталога старого проекта 1C:EDT в каталог нового проекта 1C:EDT:

Таким образом мы скопировали файлы локального репозитория из старого проекта 1C:EDT в новый проект. Теперь подключаем новый проект к скопированному репозиторию Git. Для этого в контекстном меню проекта выбираем «Групповая разработка — Общий проект»:

Если все сделано правильно, то система сама найдет каталог репозитория и предложит его подключить:

В панели «Индексирование Git» увидим большое количество изменений. В основном это изменения формата выгрузки сложных объектов в xml файлы:

Добавляем все файлы в индекс, в сообщение коммита пишем, что произошло обновление на новую версию платформы и фиксируем:

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

Еще один вариант разработки — в 1С:Предприятии

Есть еще один интересный случай для проекта «1С‑Рарус: Сценарный обработчик конфигураций», когда разработка ведется в режиме 1С:Предприятия. Ведь разработка сценариев автоматизации предполагает написание кода шагов непосредственно в СОК:

Здесь мы можем поступить двумя способами:

1. Напрямую редактировать шаги «боевой» базы «1С‑Рарус: Сценарный обработчик конфигураций»:
1. Плюсы: не нужно переносить данные, они уже в «боевой» базе.
2. Минусы: может быть неудобно отлаживать, не подходит для исправления сценариев, с которыми ведется активная работа пользователей. Наша «боевая» база СОК помимо сценария автообновления, который входит в поставку релиза «1С-Рарус: Сценарный обработчик конфигураций», содержит также множество других сценариев, таких как сборка релизов, выпуск патчей, декларативное обновление конфигураций и т. д. Более подробно мы уже рассказывали об этом в одном из докладов в рамках 1C‑Рарус Tech Day 2024.
2. Редактирование копии базы и дальнейшее внесение изменений в «боевую» базу:
1. Плюсы: можно отладить сценарий не помешав другим пользователям, а также комбинировать изменения в конфигурации и в информационной базе.
2. Минусы: Необходимость переноса внесенных в копию изменению в «боевую» базу.

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

Выгрузка обработки для отладки происходит специальным служебным сценарием, система попросит указать окружение сценария, где должно быть заполнен путь к 1С и каталог для выгрузки:

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

В форме обработки будет заполнена функция «Выполнение шага»:

Теперь мы можем редактировать код шага в Конфигураторе и отлаживать его используя все функции отладки:

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

Код доработки автоматически загрузится обратно в шаг сценария:

После внесения всех изменений в копию базы перенос в «боевую» базу можно осуществить двумя способами:

1. Ручное копирование сценариев, шагов сценариев, диаграмм мониторинга. Заходим в добавленный/измененный шаг, копируем его текст и вставляем в такой же шаг в «боевой» базе:

   

2. Второй способ заключается в переносе изменений обработкой «Выгрузка загрузка XML»:

   

Далее на стороне копии базы в случае нового сценария отмечаем:

• Справочник «Сценарий» с отбором по ссылке в списке добавленный сценарий и все его родители:

  

• Справочники «Шаги сборки» и «Параметры» с отбором по владельцу:

  

• В случае изменения только шагов сценария, отмечаем только шаги с отбором по ссылке в списке добавленных/измененных шагов и отбором по владельцу.

  Далее жмем «Выгрузить данные» и сохраняем файл как xml:

  

На стороне «боевой» базы СОК открываем ту же обработку, в окне «Загрузка» жмем «Загрузить данные» и выбираем выгруженный из копии xml:

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

Послесловие

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

Сама среда 1C:EDT по сравнению с Конфигуратором предлагает новые сущности к пониманию: проекты, приложения, информационные базы, связь с версиями платформы. Совершенно очевидно, что чем больше сущностей, тем сложнее с этим разобраться. Однако, надо признать — новые возможности среды выглядят привлекательно как для многоперсонной команды, так и для малогабартиной или даже одиночной разработки.