От экспертов «1С‑Рарус»: Применение «1С‑Рарус: Сценарный обработчик конфигураций», автоматизация выпуска релизов

Введение

Работа в команде, которая разрабатывает большое количество типовых решений — это далеко не только написание кода. Для того, чтобы наладить процесс разработки необходим ряд вспомогательных инструментов. Например, при разработке отраслевых решений, таких как «1С:УНФ 8. Управление предприятием общепита», «1С:Общепит» и других нам необходимо следить за выходами новых релизов типовой конфигурации, на базе которых разрабатывается отраслевая, скачивать новые дистрибутивы, производить обновление на новый релиз, уметь готовить нашу конфигурацию к сертификации, собирать и выпускать собственные релизы. И это далеко не полный список того, чем мы занимаемся, а значит и потребность в автоматизации таких достаточно однотипных сценариев назревает сама собой. Идея оркестрации и автоматизации таких рабочих процессов, конечно же, не нова. На рынке уже есть ряд решений, но все же далеко не всегда они способны учесть специфику разработки на 1С.

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

Концепт СОК

Идея пошагового исполнителя

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

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

Накопление сценариев в базе СОК

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

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

Идея окружений для переиспользования сценариев

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

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

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

Релизы

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

Шаблоны

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

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

Функции

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

Возможность вызова скриптов на других языках

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

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

Отладка шагов

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

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

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

Далее нам необходимо в рабочем месте «Исполнение сценариев» выбрать отладку и указать имя модуля, к которому система будет обращаться при выполнении шагов:

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

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

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

Примеры сценариев автоматизации в «1С‑Рарус: Сценарный обработчик конфигураций»

Выпуск релиза

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

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

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

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

Совместные решения публикуются на сайте releases.1c.ru и структура публикуемых материалов регулируется фирмой 1С. Несовместные же публикуются только на сайтах «1С‑Рарус» и имеют схожую структуру, но регулируется нашими внутренними регламентами.

Для того, чтобы не запутаться в правильности создания данных структур у нас были написаны регламенты формирования необходимых файлов и размещения их в соответствующий каталогах. Однако типовые релизы имеют одну особенность — частый выход релизов. Например, по «1С:Бухгалтерии предприятия» выпускаются релизы иногда каждую неделю.

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

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

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

Более детально процессы автоматизируемые в «1С-Рарус: СОК» представлены на следующей схеме:

Предлагаем рассмотреть их по очереди.

Сценарий «Обновление защиты»

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

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

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

Для автоматизации данных действий был разработан отдельный сценарий «Обновление защиты».

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

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

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

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

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

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

Шаблон команды для частичной выгрузки:

"ПутьК1cv8" config /F "ПутьКБазе" /N "ЛогинБазы" /P "ПарольБазы" /ConfigurationRepositoryF "АдресХранилища" /ConfigurationRepositoryN "ЛогинХранилища" /ConfigurationRepositoryP "ПарольХранилища"/DumpConfigToFiles "КаталогКудаБудетВыполненаВыгрузка" -Format Hierarchical -listFile "КаталогСФайлами\СписокОбъектовДляВыгрузки.txt" /DisableStartupDialogs /Out "КаталогЛогов\DumpConfigToFiles.log"

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

Шаблон команды для частичной загрузки:

"ПутьК1cv8" config /F "ПутьКБазе" /N "ЛогинБазы" /P "ПарольБазы" /ConfigurationRepositoryF "АдресХранилища" /ConfigurationRepositoryN "ЛогинХранилища" /ConfigurationRepositoryP "ПарольХранилища" /LoadConfigFromFiles "КаталогОтКудаБудетВыполненаЗагрузка" -Format Hierarchical -listFile "КаталогСФайлами\СписокФайловДляЗагрузки.txt" /DisableStartupMessages /DisableStartupDialogs /Out "КаталогЛогов\LoadConfigFromFiles.log"

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

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

Сценарий «Подготовка связанных конфигураций»

Следующим автоматизируемым процессом является подготовка конфигурации. Можно задать вопрос: а что мы собственно собираемся готовить, мы ведь релиз уже должны собирать? На самом деле это далеко не всегда так. Одним из способов разработки конфигураций является разработка на единой конфигурации, которая перед сборкой релизов преобразовывается в более мелкие с ограничением функционала. Например, продукт «1С:ERP Управление предприятием» содержит в себе полный функционал, а конфигурация «1С:Комплексная автоматизация» получается путём вырезания из ERP блока планирования.

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

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

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

1. Основная конфигурация разработки «1С:Ресторан.Фронт-офис». Находится на поддержке от конфигурации «1С:Розница», содержит весь отраслевой функционал и подключена к основному хранилищу.
2. Конфигурация «1С:Ресторан. Фронт-офис», находится на поддержке от конфигурации основного хранилища.
3. Конфигурация «1С:Фастфуд. Фронт-офис», находится на поддержке от конфигурации основного хранилища и имеет вырезанный блок ресторана.
4. Конфигурация «1С:Фастфуд. Фронт-офис. Базовая версия» находится на поддержке от конфигураций «1С:Розница базовая» и основного хранилища, имеет вырезанные блоки ресторана и доставки.

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

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

Алгоритмически процесс был простой, но имел мааааленький недостаток. А именно — продолжительность. Средняя длительность выполнения превышала 6 часов. Когда в пользовательском режиме «вырезание» осуществлялось за 1,5–2 часа.

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

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

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

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

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

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

В результате получилось оптимизировать время выполнения сценария подготовки до 1 часа.

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

Хорошо. Защиту обновили, конфигурацию получили, что дальше? А дальше добавление информации о сборке, а именно добавление описания изменений в конфигурацию.

Сценарий «Добавление информации о сборке»

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

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

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

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

Решив задачу с забывчивостью разработчиков можно переходить к задаче получения описаний. Разработчики платформы позаботились об этом добавив отдельную пакетную команду /ConfigurationRepositoryReport. Добавив к ней установку отбора по номеру версии или дате последнего формирования описания получится собирать только крайние изменения:

"ПутьК1cv8" config /F "ПутьКБазе" /N "ЛогинБазы" /P "ПарольБазы" /ConfigurationRepositoryF "АдресХранилища" /ConfigurationRepositoryN "ЛогинХранилища" /ConfigurationRepositoryP "ПарольХранилища" /ConfigurationRepositoryReport "ПутьКВыгрузке\ВыгрузкаКомментариевКРелизу.txt" -DateBegin "ДатаНачала" -GroupByComment -DoNotIncludeVersionsWithLabels  -ReportFormat txt /DisableStartupDialogs /DisableStartupDialogs

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

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

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

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

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

Если бы заставка была в векторной графике и представлена, например, в формате SVG. Тогда хватило бы выгрузить ее из конфигурации, заменить в ней текст описания и загрузить обратно.

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

Для реализации данной идеи мы написали скрипт на Python, воспользовавшись библиотекой PIL.

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

На этом основная подготовка будет завершена и останется выполнение сценария сборки релизов.

Сценарий «Формирование файлов дистрибутива»

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

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

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

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

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

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

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

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

Затем необходимо пройтись по всем файлам. В ходе обхода заменить тип «DataProcessor» на «ExternalDataProcessor», удалить информацию несвойственную внешним обработкам, например, о модуле менеджера, стандартных командах и т. п, а также сформировать новые идентификаторы для объектов и форм.

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

"ПутьК1cv8" config /F "ПутьКБазе" /N "ЛогинБазы" /P "ПарольБазы" /ConfigurationRepositoryF "АдресХранилища" /ConfigurationRepositoryN "ЛогинХранилища" /ConfigurationRepositoryP "ПарольХранилища" /LoadExternalDataProcessorOrReportFromFiles "ФайлВыгрузкиОбработки" "ПутьФайлаЕПФ" /DisableStartupDialogs

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

Давайте рассмотрим еще один интересный момент. При автоматизации процесса сборки релизов мы сталкивались с ситуациями, когда одними пакетными командами не обойтись и была необходимость выполнения кода на языке «1С:Предприятие 8».

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

Если же попробовать поискать аналогичную пакетную команду для его формирования, то ничего не получится. А как тогда автоматизировать?

И тут весь подвох: в языке «1С:Предприятие 8» есть функция ПолучитьИдентификаторКонфигурации() , которая как раз и получает соответствующий идентификатор.

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

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

"ПутьК1cv8" ENTERPRISE /F "ПутьКБазе" /N "ЛогинБазы" /P "ПарольБазы" /Execute "ПутьКВнешнейОбработке" /C "ПутьКФайлуСПараметрамиОбработки"

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

"ПутьК1cv8" ENTERPRISE /F "ПутьКБазе" /N "ЛогинБазы" /P "ПарольБазы" /C "СформироватьИдентификаторКонфигурацииИЗакрыть <ДопПараметрыЗапуска>"

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

Вместо заключения

Мы рассмотрели концептуальное и даже с некоторыми подробностями устройство «1С-Рарус: СОК» для задач, которые необходимо решать команде разработки. И решать так, чтобы эта вспомогательная деятельность не отвлекала от творчества. Рутину оставим роботам.

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

До новых встреч!