Внешние обработки: подключаем Git и храним историю изменений

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

С ее помощью можно настроить версионирование внешних обработок и решить многие сложности, связанные с хранением и сравнением разных версий *.epf-файлов, отслеживанием изменений.

О чем эта статья

В этой статье мы:

  • Рассмотрим процедуру выгрузки внешних обработок в XML-файлы
  • Подключим систему управления версиями Git
  • Научимся версионировать внешние обработки и просматривать историю их изменения.

Сложности при работе с внешними обработками

Внешние обработки — это обработки, которые не включены в состав конфигурации и хранятся в виде файлов с расширением *.epf.

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

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

  • Не ясно, что поменялось по сравнению с прошлой версией;
  • Не понятно, когда именно были выполнены изменения. Это можно узнать только из комментариев, если они есть;
  • Нет возможности быстро вернуться на прошлую версию обработки, если она не была предусмотрительно скопирована и не сохранена с другим названием или в другой папке;
  • По прошествии некоторого времени сложно разобраться среди множества однотипных файлов.
  • Чтобы безвозвратно не потерять изменяемую логику, приходится оставлять большие участки закомментированного кода (хотя комментарии должны только пояснять работу программного кода);

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

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

Выгрузка внешних отчетов и обработок в XML

Начиная с версии 8.3.8, платформа научилась выгружать внешние отчеты и обработки в файлы формата XML, проще говоря — конвертировать файлы *.epf и *.erf в набор файлов XML и BSL.

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

Конвертация файлов

Рисунок 1. Конвертация файлов

При такой конвертации на диск сохраняется следующий набор файлов:

  • Файл с описанием обработки или отчета в формате XML.
  • Файлы с описанием всех форм обработки в формате XML.
  • Файлы с исходным кодом модуля формы и модуля обработки или отчета в виде BSL-файлов.

С файлами такого формата могут работать все существующие системы контроля версий.

Используем систему контроля версий

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

Такие системы рассчитаны на работу с файлами в виде исходного программного кода и воспринимают файлы платформы 1С с расширениями *.epf и *.erf как двоичные, т.е. просто как набор нулей и единиц и поэтому не умеют их переводить в «читаемый» формат.

Так видит файл с расширением*.epf сторонняя программа

Рисунок 2. Так видит файл с расширением*.epf сторонняя программа

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

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

Приступаем к настройке

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

  1. Git — программа для работы с системой управления версиями
  2. SourceTree — визуальный клиент для работы с Git
  3. Araxis Merge — программа для сравнения и объединения программного кода.

Программы для версионирования файлов обработки

Рисунок 3. Необходимые программы

Выбор именно этих программных решений не является принципиальным — в качестве визуального клиента можно использовать другое приложение, например GitHub Desktop или TortoiseGit, а Araxis Merge можно заменить программами KDiff3, WinMerge или любой другой. Цель данной статьи — продемонстрировать подход к версионированию файлов платформы «1С:Предприятие», а не показать готовое решение.

Для демонстрационного примера будет использована внешняя обработка «ЗагрузкаСпецификации.epf», расположенная в папке «c:\Обработки\». В папке «c:\Repo1C\» будет создан проект Git, в котором будет храниться история разработки.

Набор файлов

Рисунок 4. Исходный набор файлов

Интерактивная выгрузка

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

  1. Открыть обработку в конфигураторе платформы версии 8.3.8 и старше
  2. Открыть контекстное меню обработки
  3. Выбрать пункт «Выгрузить в файлы» и указать нужную папку.

Интерактивная выгрузка обработки

Рисунок 5. Интерактивная выгрузка обработки

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

Выгруженные файлы

Рисунок 6. Выгруженные файлы

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

Процесс выгрузки обработки можно автоматизировать. Для этого нужно запустить конфигуратор в пакетном режиме.

Пакетный режим

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

Чтобы произвести выгрузку обработок, нужно запустить исполняемый файл 1cv8.exe с указанием ключа DumpExternalDataProcessorOrReportToFiles.

После этого ключа нужно указать следующие параметры:

  • Полный путь к файлу обработки («что выгрузить»)
  • Путь к папке, в которую будут выгружены xml-файлы («куда выгрузить»)
  • Формат выгрузки: иерархический или линейный. При иерархическом формате файлы будут выгружены с учетом структуры элементов, при линейном — простым списком, при этом тексты модулей будут сохранены с расширением *.txt.

Выполнять такой запуск нужно из командной консоли Windows. Чтобы запустить командную консоль, нужно открыть меню «Пуск — Выполнить» (или нажать сочетание клавиш Win+R), написать«cmd» и нажать Enter.

Откроется командная строка, в которой нужно написать следующую команду (путь к исполняемому файлу 1cv8.exe может быть другим, в зависимости от установленной версии платформы):

"c:\Program Files\1cv8\8.3.12.1529\bin\1cv8.exe" DESIGNER /DumpExternalDataProcessorOrReportToFiles "c:\Repo1C" "c:\Обработки\ЗагрузкаСпецификаций.epf" /Out "c:\Repo1C\out.txt"

Командная строка

Рисунок 7. Командная строка

После выполнения указанной команды в папку «C:\Repo1C» будут выгружены файлы, а в файле out.txt появится такая запись:

Выгрузка прошла успешно

Рисунок 8. Выгрузка прошла успешно

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

Командный файл

Командный файл — это текстовый файл с расширением «*.bat», который содержит последовательность команд для выполнения в системе Microsoft Windows.

Чтобы создать такой файл, нужно открыть Блокнот (или любой другой текстовый редактор: Notepad++, AkelPad), скопировать в него следующий текст и сохранить с расширением «.bat»:

SET PATH1C="c:\Program Files\1cv8\8.3.12.1529\bin\1cv8.exe"
SET EXT="c:\Обработки\ЗагрузкаСпецификации.epf"
SET SRC="c:\Repo1C"
SET OUT="c:\Repo1C\out.txt"
%PATH1C% DESIGNER /DumpExternalDataProcessorOrReportToFiles %SRC% %EXT% /Out %OUT%

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

На изображение ниже показано, как выбрать кодировку в текстовом редакторе Notepad++.

Сохранение файла в кодировке OEM-866

Рисунок 9. Сохранение файла в кодировке OEM-866

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

Создание репозитория

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

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

Наш тестовый репозиторий будет размещаться в папке, в которую мы выгружаем обработку – «c:\Repo1C».

Создать репозиторий можно через командную консоль, но проще воспользоваться программой SourceTree — ее также необходимо скачать с официального сайта и установить. При установке нужно указать адрес электронной почты (либо учетную запись Google) и пройти процедуру регистрации. Для создания репозитория нужно нажать на кнопку «Create» в главной панели SourceTree и указать полный путь к папке:

Создание репозитория в SourceTree

Рисунок 10. Создание репозитория в SourceTree

После создания репозитория в папке появляется скрытая директория «.git» — наличие ее означает, что Git теперь отслеживает изменения файлов в этой папке.

Поскольку в папке с:\Repo1C уже находились выгруженные файлы, Git сразу же предложит зафиксировать их в хранилище.

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

Помещение измененных файлов в индекс

Рисунок 11. Помещение измененных файлов в индекс

Для фиксирования изменений нужно нажать кнопку «Закоммитить» (или сочетание клавиш Shift+Ctrl+C). Команда commit (с англ. — «совершать, фиксировать») помещает изменения файлов в служебное хранилище системы Git. Аналогичным действием в хранилище 1С является команда «Поместить в хранилище».

После заполнение комментария нужно нажать на кнопку “Закоммитить”

Рисунок 12. После заполнение комментария нужно нажать на кнопку “Закоммитить”

Попробуем теперь поменять что-то в нашей обработке и перевыгрузить файлы.

Например, после добавления в форму процедуры ПроверитьНастройкиВТаблицеДанных(),

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

Git отображает изменения файлов обработки

Рисунок 13. Git отображает изменения файлов обработки

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

cd %SRC%
set /P txtcommit="Введите текст комментария: "
git add .
git commit -m "%date% %time%: %txtcommit%"

Смотрим историю изменений

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

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

Просмотр изменений конкретного файла

Рисунок 14. Просмотр изменений конкретного файла

Для сравнения версий файлов между собой будем использовать внешнюю утилиту сравнения Araxis Merge.

Предварительно нужно настроить SourceTree — указать, что именно Araxis нужно использовать в качестве внешнего средства сравнения.

Настройка внешней утилиты сравнения

Рисунок 15. Настройка внешней утилиты сравнения

Чтобы сравнить версии, нужно выбрать «Внешняя утилита сравнения»

Рисунок 16. Чтобы сравнить версии, нужно выбрать «Внешняя утилита сравнения»

В открывшемся окне программы Araxis Merge можно увидеть наглядное сравнение версий модуля формы.

Araxis Compare сравнивает версии файла

Рисунок 17. Araxis Compare сравнивает версии файла

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

Дорабатываем командный файл

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

Окончательный вариант bat-файла будет выглядеть так:

SET PATH1C="c:\Program Files\1cv8\8.3.12.1529\bin\1cv8.exe"
SET EXT_FOLDER="c:\Обработки"
SET SRC="c:\Repo1C"
SET OUT="c:\Repo1C\out.txt"
cd /D %EXT%
del /f /q %OUT%
FOR %%F IN (*.epf *.erf) DO (
%PATH1C% DESIGNER /DumpExternalDataProcessorOrReportToFiles %SRC% %%F /OUT %OUT% -NoTruncate
)
set /P txtcommit="Введите текст комментария: "
git add .
git commit -m "%date% %time%: %txtcommit%"

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

Подведем итоги. Теперь мы можем:

  • Фиксировать новые версии обработки в хранилище системы контроля версий. Например, это можно делать в конце рабочего дня или перед началом работы над новым блоком программного кода.
  • Просматривать историю версий и внесенные изменения, чтобы быстро понять, когда и что было добавлено, изменено или удалено.
  • Сравнивать версии обработки между собой. К примеру, можно увидеть, чем именно отличается версия недельной давности от текущей. Или в какой момент был неверно выбран алгоритм для решения задачи — и при необходимости вернуться в исходную точку.

При наличии удобных инструментов такие вопросы решаются быстрее и эффективнее.

Заключение

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

  • Обработку нужно выгрузить в формате *.xml.
  • Выгруженные файлы должны быть помещены в репозиторий системы контроля версий.
  • Сравнение версий выполняется внешними инструментами сравнения.

Платформа 1С также предоставляет возможность обратной загрузки — формирования внешней обработки отчета из набора XML-файлов. Для этого существует команда «Загрузить из файлов» и ключ LoadExternalDataProcessorOrReportFromFiles.

Также за рамками статьи остались другие возможности, которые предоставляет система Git: облачное хранение репозитория, совместная работа над проектом и многое другое. Они тоже могут использованы при работе с внешними файлами системы «1С:Предприятие».

Об авторе

Автор статьи – Сергей Калеников

г. Москва

Остались вопросы?

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

В нем разбирается:

  • Назначение внешних отчетов и обработок
  • Использование подсистемы БСП “Дополнительные отчеты и обработки”
  • Виды внешних обработок для конфигураций на базе БСП: УТ 11, ERP 2, БП 3, ЗУП 3
  • Преимущества хранения внешних обработок в ИБ
  • Версионирование внешних обработок
  • И много другое :)

26 комментариев к “Внешние обработки: подключаем Git и храним историю изменений

  1. AlexPC сказал:

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

  2. Esagila сказал:

    Огромное спасибо! Какая интересная статья! Как хорошо написана! О такой возможности прежде не слышала, даже не ожидала, что такое возможно

  3. akazakov сказал:

    А почему бы и нет, так тоже можно. Останавливает от использования данного способа постоянная выгрузка в xml, даже с использованием пакетного режима. Т.е. трудоемкий процесс помещения изменения и создания commit. Если стоит задача хранить версии внешних обработок и просмотра версий и ничего более сложного как merge и т.д., то я свой выбор остановил на tortoise svn. Есть папка Repo, которая версионируется. Она синхронизируется с облаком. Изменяешь обработку, фиксируешь изменение (commit). Далее, если нужно посмотреть изменения в версиях, в настройках tortoise svn для epf и ert указан скрипт, который написан на замечательном инструменте OneScript. Скрипт запускает служебную базу, где на входе 2 файла разных версий, в этой базе единственная обработка v8reader (еще один мощный инструмент с большим потенциалом) которая опубликована на infostart, с с помощью этой обработки и происходить сравнение версий. Немного сложно изначально для настройки, зато затем процесс фиксации изменений и просмотра версий простой.

  4. Михаил сказал:

    Каждый раз с восторгом открываю статьи про 1С и Git, и каждый раз расстраиваюсь. Ничего полезней 1С в выгрузке внешних обработок в файлы не смогла придумать, как выгрузить в читаемом виде для текстового редактора модуля объекта, а модулей формы вы бинарник! “Это же так информативно!”
    Именно по этому эта выгрузка в файлы не несёт особого смысл.
    Я в гит сохраняю сам *epf-файл и в текстовые файлы с расширением *.bsl ручками содержание модулей форм. Так удобно отслеживать изменения в модулях, а на случай необходимости посмотреть остальное уже приходится доставать два варианта обработки и сравнивать. Это куда продуктивней и понятней для работы обычного смертного не из матрицы, который не умеет видеть картинки в потоке единичек и нулей.

  5. Владимир сказал:

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

    Иначе все ссылочные реквизиты в результате выгрузки будут иметь тип “Строка”:

    http://prntscr.com/lq54de

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

    Помочь при этом может режим агента конфигуратора : https://wonderland.v8.1c.ru/blog/rezhim-agenta-konfiguratora/

    • Калеников Сергей сказал:

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

      Про режим конфигуратора — не понятно, уточните, пожалуйста, как именно его можно использовать для решения нашей задачи?

      И еще — а зачем запускать скрипт 10 раз? Если у вас 10 обработок, достаточно поместить их в одну папку и запустить скрипт один раз.

  6. Артур Аюханов сказал:

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

  7. Артур Аюханов сказал:

    – А использовать Gitsync, Гит-Конвертер и т.п.?
    – Нет, не слышали! :(

    Коллеги, историям с коллективной работе 1C через Git уже много лет.
    Уже описано на многих сайтах.

    Зачем эта статья?

    • Юлия Толстых сказал:

      Артур, у этой статьи есть своя аудитория.
      Давайте обсудим – может быть, Вы готовы написать статью для нашего сайта? Отправила по этому поводу письмо на Ваш e-mail.

    • Калеников Сергей сказал:

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

      Цель же данной статьи — на конкретном примере показать, как именно работает выгрузка метаданных в файлы и как работает версионирование. Если хотите — это такой небольшой шаг в сторону EDT и полноценной работе с GIT. Всему свое время, а начинать всегда лучше с азов :)

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

  8. Денис Гончаренко сказал:

    Форма вместе с текстом модуля формы выгрузилась не в bsl файл, а в bin
    Платформа 8.3.12.1595

      • Калеников Сергей сказал:

        Денис, это особенность платформы.
        Управляемая форма может быть представлена в виде XML-документа, а обычная форма — нет, она выгружается просто как двоичные данные.

  9. Анатолий сказал:

    У меня идея. Почему бы не использовать отдельное хранилище от самой 1с для внешних обработок и отчетов?

    • Анатолий сказал:

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

      • Ingvar Vilkman сказал:

        Поздравляю, Вы только что изобрели расширения)
        Вот только их уже давно все используют…

  10. Catseye сказал:

    А проблема с модулем менеджера обработки остается? Он не выгружается из конфигурации в файл?

    • Калеников Сергей сказал:

      Catseye, спасибо за вопрос. Это не совсем проблема, просто у внешних обработок на самом деле не существует модуля менеджера.

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

      И получается нестыковка — модуль менеджера нужен для вызова функций БЕЗ создания экземпляра объекта, а внешняя обработка БЕЗ создания экземпляра вообще не может существовать.

      В общем, поэтому модуль и не выгружается :)

  11. Aidar сказал:

    Спасибо! Хорошая статья. А курс по EDT будет? Или уже не стоит надеяться? :-)

    • Юлия Толстых сказал:

      Добрый день, Айдар!
      Пока не видим необходимости записывать курс. Сам продукт отслеживаем, ждем пока ситуация с ним более-менее стабилизируется.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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