Руководство пользователя
Расширение 1С:СППР: «Управление сборкой GLI».

Оглавление

Руководство пользователя Расширение 1С:СППР: «Управление сборкой GLI». 1

Назначение подсистемы 1

Подсистема позволяет: 1

Ограничения: 2

Порядок подключения и начала использования: 2

Объекты расширения 4

Справочник СУБД 4

Подчиненный справочник Размещения баз на СУБД 5

Справочник Кластеры 1С 5

Справочник Информационные базы 5

Справочник Сборочные линии 9

Справочник Типы СУБД 13

Подчиненный справочник Пакетные задания 14

Справочник Алгоритмы определения переменных 15

Отчет Подготовка описания версии по техпроектам и ошибкам 17

Расширение объектов основной конфигурации 19

Справочник Ошибки 19

Справочник Технические проекты 21

Справочник Ветки 22

Подчиненный справочник Сборки версии 22

Обработка Настройка уведомлений о сборках и подключение к GitLab API 23

Варианты и особенности сценариев учета исправления ошибок в СППР при использовании расширения «Управление сборкой GLI» 24

В ветке с типом «Ветка для исправления ошибок»: 25

В ветке версии: 27

В ветке технического проекта 28

Сценарии создания веток в Git и взаимосвязь веток Git с одноименным справочником «Ветки» в СППР. 28

Создание веток из СППР 28

Создание веток в СППР при первичном помещении ветки в удаленное хранилище 28

Назначение подсистемы

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

Подсистема позволяет:

• Вести список информационных баз (ИБ) в нескольких кластерах и СУБД. Справочник "Информационные базы"

  • Для каждой ИБ допустимо указание имени пользователя и пароля, сохраняемые в настройках пользователя.

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

  • Для каждой ИБ возможно исполнение различных командных файлов, из которых четыре предопределены (копирование из родителя, удаление, получение параметров и получении списка ИБ). Остальные могут добавляться по усмотрению. Командные файлы хранятся в виде шаблонов, для каждого шаблона предусмотрены алгоритмы подготовки (заполнения) переменных шаблона и алгоритмы обработки результат на встроенном языке.

  • Каждая информационная база может быть связана с некоторым объектом разработки:

    • Ветки версий, основная ветка проекта

    • Технические проекты

    • Ошибки

• Вести справочник "Сборочных линий", представляющих собой динамически формируемый шаблон сборочной линии проекта, подключаемый в конвейере Gitlab одной строкой и не требующих модификации корневого файла проекта .gitlab-ci.yml. Пример шаблона.

• Поддерживать консистентность ветки версии, в которой содержится только проверенный код, и позволяющий выпустить релиз в любой момент согласно требованиям Разработка плановой версии п. 3.2 за счет использования ветки тестирования (подробнее Ещё/? Справка (GLI)*)

  • Автоматически формировать запросы на слияние в ветку тестирования ошибок, исправляемых в выделенных ветках, не имеющих связи с ИБ и отмеченных как "Исправлено". (Подробнее см. дополнение к справке по справочнику "Ошибки")

  • Автоматически формировать запросы на слияние в ветку версии подтвержденных ошибок

• Максимально автоматически подготавливать описание релиза.

• Автоматически создавать элементы в справочнике ветки, созданные при помещении в гит из локального репозитория гит для технических проектов и исправляемых ошибок. (Частично требуется СВ, в случаях, когда пользователь начал редактировать объект и в этот момент разработчики поместил новую ветку в удаленное хранилище) (Подробнее см. дополнение к справке в справочнике "Ошибки")

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

• Уведомлять администраторов сборок обо всех событиях сборочного конвейера, не только об успешных. (Требуется СВ)

• Уведомлять разработчика о проблемах при принятии запроса на слияние его кода в ветку тестирования (Требуется СВ)

Ограничения:

• Предполагается, что имя базы в кластере и сервере СУБД совпадает.

• Не допускается одновременная работа с двумя и более клонами Gitlab хранилищ, но допускается быстрое переключение между ними изменением настроек. Например, когда в публичное хранилище результаты работы могут выкладываться не сразу, а отладка некоторого функционала проводится в защищённом тестовом контуре, обособленным от публичного. В этом случае будут корректно обрабатываться входящие запросы через API, этого будет достаточно для обработки событий pipeline, push, merge-request, но, чтобы, заработала исходящая интеграция, необходимо в проекте указать новую строку подключения к хранилищу Git.

• Не поддерживается интеграция по issue Gitlab

• Если с сервера СППР доступа к СУБД нет, скорее всего использовать функционал не получится, либо будут ограничены операции с копированием эталонных баз. Для элемента справочника СУБД, к которым доступа с сервера СППР нет нужно включить флаг "Не опрашивать доступность СУБД" Подробнее здесь.

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

Порядок подключения и начала использования:

Подключение и настройка

• Для подключения необходимо инициализировать систему взаимодействия 1С в ИБ СППР, если она ещё не используется, инструкции по активированию 1С:Система взаимодействия

• Опубликовать, обособленно от основной публикации ИБ СППР, на веб сервере http сервисы расширения BS и GetPipeline. Подробнее здесь. 

• Настроить gitlab-runners для этапов сборки и обновления ИБ. У gitlab-runners не должно быть ограничений по доступу к серверу СУБД и кластерам 1С, включая и прилегающий к тестовому продуктивному контуру. В противном случае, возможность сборки ИБ ветки версии с одновременным обновлением тестовых данных из продуктивного контура будет невозможна.

• Настроить веб хуки. Подробнее здесь.

• Предоставить службе сервера СППР доступ в тестовый контур: открыть порты СУБД, 1С, организовать постоянное сетевое подключение к тестовому контуру сервера, на котором работает СППР. 

• Создать в Gitlab пользователя СППР, добавить его в проект как maintainer. Сгенерировать для пользователя приватный ключ и указать идентификатор проекта и приватный ключ в настройках, там же создать служебного пользователя в СППР, о лица которого будет работать интеграция и рассылаться уведомления в СВ.
  Важно! При создании пользователя – бота профиль «HTTP Сервис» создаётся автоматически, в нём используются две роли: Типовая «Запуск внешнего соединения» и роль расширения «Чтение интеграция Gitlab». Роль расширения использует вид доступа «Проекты», по умолчанию в созданном профиле сервису доступны все проекты, даже если ограничение доступа на уровне записей выключено. Если Вам нужно ограничить доступ к каким-либо проектам, установите настройки профиля и скорректируйте группу доступа, в которую будет включен бот, соответствующим образом. Роль «Чтение интеграция GitLab» необходима потому, что несмотря на то, что код HTTP сервисf, отдающий тест сборочной линии исполняется в привилегированном режиме, определение переменных производится исполнением кода в безопасном режиме, для этого роль содержит с учётом RLS права на чтение всех справочников расширения, а так же справочников технические проекты, ошибки, ветки, версии проектов, сборки версий, пользователи. Этих доступов достаточно для работы сборочной линии в демонстрационной базе. Если вы в алгоритмах определения переменных задумаете использовать ещё какие-то другие справочники то соответствующие роли, разрешающие доступ на чтение нужно будет добавить в профиль «HTTP Сервис».

• Описать тестовые контур и прилегающие к нему элементы продуктивного в справочниках "СУБД" и "Кластеры"

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

• Создать первую версию в справочнике «Версии проекта» связать её с веткой версии

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

• Добавить эталонные базы в кластер(ы) и на СУБД тестового контура, зарегистрировать соответствующие корневые элементы в справочнике "Информационные базы", связать из с объектом сборки основной ветки разработки. Обеспечить средствами СУБД сохранность ИБ в режиме FULL.

• Создать ветку(и) тестирования для ветки версии проекта. Подробнее см. описание справочника "Ветки" и справочника "Ошибки"

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

• Создать подчиненные ИБ от веток версии ИБ ветки тестирования и связать их с ветками тестирования.

• Запустить сборочный конвейер для ветки версии убедиться, чтоб сборка и уведомления работают.

• Система готова к работе.

Описание процесса работы с подсистемой

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

• Реализация доработок системы с использованием справочника «Технические проекты» на основании ЧТЗ** в справочнике «Идеи» в СППР

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

Процессы работы ошибками и техническими проектами описаны в руководстве пользователя СППР

Помимо двух основных процессов существуют процессы:

• Инициализации разработки первой версии системы (описано выше)

• Обновление системы новым функционалом от поставщика, встраивание и обновление библиотек

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

  • Создать новую версию в справочнике «Версии проекта» и добавить ветку версии для новой версии и ветку тестирования

  • Создать копии эталонных баз для ветки версии и ветки тестирования, отключить автоматическое копирование в справочнике «Информационные базы»

  • При необходимости добавить этапы для ветки версии и ветки тестирования в сборочном конвейере

  • Новые, не критичные ошибки ^{(критичными признают ошибки, блокирующие работу пользователей, и не имеющие способов обхода проблемы)} найденные в текущей версии откладывать до получения новой версии

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

  • Провести обновление и протестировать изменения в ветке новой версии

  • Заморозить регистрацию и исправление ошибок, а также разработку функционала

  • Перенести исправления критичных ошибок в новую версию кумулятивно из ветки текущей версии

  • Протестировать работоспособность критичных исправлений в ветке новой версии

  • Слить новую версию в основную ветку проекта

• Сборка очередного релиза системы

  • Провести ревизию подтвержденных исправлений и технических проектов, подлежащих закрытию^{(задачи которых либо выполнены, либо отменены)}.

  • Принять запросы на слияние в ветку версии, устранить конфликты при необходимости

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

  • Слить ветку версии в основную ветку проекта, добавить тег в Gitlab и ссылки артефакты сборки CF/CFU нового релиза из конвейера вставить во вложения нового релиза

* Аналогичные пункты присутствуют в адаптированных формах элементов справочников:

• Ветки (Форма списка и элемента)

• Сборки версии (Форма элемента)

• Технические проекты (Форма элемента)

• Ошибки (Форма списка и элемента)

** Частное техническое задание

Объекты расширения

Справочник СУБД

Предназначен для описания СУБД, используемых при сборке информационных баз.

Имя сервера СУБД: наименование, по которому идентифицируется именно этот сервер СУБД в скриптах, например в sqlcmd для сервера типа MS-SQL.

Тип СУБД: элемент справочника "Типы СУБД" описывающего основные и дополнительные алгоритмы для работы с выбранным типом сервера СУБД

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

Кодировка вывода: в подсистеме используется обращение к утилитам командной строки для выполнения манипуляций с ИБ, для правильной интерпретации результатов с кириллицей нужно указать в каком формате командная строка возвращает текстовый вывод. Например, sqlcmd, запускаемый в Windows из командного процессора CMD использует кодировку DOS OEM 866.

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

Путь к переменной: Параметры.ИБ.СУБД.ЛокальныйКаталогДляАрхивов

Общий каталог на сетевом ресурсе для архивов: может быть полезен если используются разные СУБД для продуктивного и тестового контуров, и между ними требуется делать перемещение копий ИБ. Все сервера СУБД должны иметь возможность создавать и восстанавливать архивы с этого ресурса.
Путь к переменной: Параметры.ИБ.СУБД.ОбщийКаталогНаСетевомРесурсеДляАрхивов

Не опрашивать доступность СУБД: используется в тех случаях, когда некоторые СУБД не доступны серверу СППР, но к которым есть доступ с бегунов (runners) GitLab. В этом случае с списке информационных баз такие ИБ будут отмечены как недоступные.

Подчиненный справочник Размещения баз на СУБД

Подчиненный справочнику СУБД, определяющий физическое расположение внутри сервера для хранения файлов данных и журналов транзакций
Полное имя каталога нужно указывать обязательно с закрывающим слешем "\" или "/" для путей в формате Linux.

Примеры: заполнения:
W:\SQLData\

/var/lib/pgpro/1c-11/data/base/

Справочник Кластеры 1С

Справочник предназначен для хранения информации о кластерах 1С, на которых размещаются информационные базы.

Имя кластера необходимо вводить в либо формате FDQN, либо в кратком формате, указывая только имя сервера, при необходимости дополняя его номером порта, если кластер размещён не нас стандартном порту.

Примеры корректных наименований:

1. MyServer.MyDomain.MyZone (FDQN)

2. MyServer сокращенное, только имя сервера

3. MyServer:1641 - имя с указанием порта

Релиз: Используемая версия в кластере – справочное значение, во встроенных алгоритмах не используется, может использоваться в алгоритмах определения переменных.

Имя администратора: Имя администратора кластера

Пароль администратора: Пароль администратора кластера

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

Доступные функции в алгоритмах подготовки переменных и разбора результата справочника "Пакетные задания":
GLI_АдминистрированиеКластера.ПустойСписокСеансов(ИБ), возвращает Истина, если нет сеансов с ИБ.

GLI_АдминистрированиеКластера.СоздатьИБВКластере(ИБ), создаёт базу в кластере, если она не создана. Для создания ИБ используются наименования из переданного элемента справочника "Информационные базы". Возвращает Истина - удачно, или не требуется создание, Ложь - если создание закончилось неудачей. Причины неудачи сообщаются в сообщении. База создаётся с расчетом, что на сервере СУБД уже присутствует одноименная ИБ. Если на сервере СУБД база не существует, будет выдано сообщение об ошибке.

GLI_АдминистрированиеКластера.УдалитьИБВКластере(ИБ), удаляет базу в кластере, возвращает Истина, если удаление прошло успешно, Ложь, если удалить базу не получилось. База из кластера удаляется без удаления с сервера СУБД.

GLI_АдминистрированиеКластера.ПолучитьБазуВКластере(ИБ), возвращает объект АдминистрированиеИнформационнаяБаза либо Неопределено при ошибке

GLI_АдминистрированиеКластера.ПолучитьКластер(ИБ), возвращает объект АдминистрированиеКластер либо Неопределено при ошибке

Параметр ИБ - ссылка на элемент справочника "Информационные базы"

Сервер RAS: имя сервера администрирования

Порт RAS: номер порта сервера администрирования

Справочник Информационные базы

Информационные базы, механизм, позволяющий хранить информацию о собираемых и/или тестируемых базах в контуре CI. 

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

Каждая информационная база (ИБ) привязывается к своему объекту сборки:

• Технический проект

• Ошибка

• Общая ветка тестирования ветки версии

• Ветка версии

• Ветка проекта

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

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

Пример скрипта для MS SQL: sqlcmd -S ~!ServerName -U ~!UserName -P ~!Password -h -1 -b -Q "SELECT name FROM master.dbo.sysdatabases", где ServerName, UserName, Password - переменные. описанные в справочнике "Алгориты определения переменных":

Результат такого запроса является простой список ИБ на сервере СУБД. Полученные имена ИБ сопоставляются с реквизитом "Полное имя" элементов справочника ИБ.

При выводе дерева информационные базы, которые физически присутствуют на сервере СУБД маркируются полем "Доступность", для недоступных (тех базах, которые присутствуют в справочнике, но отсутствуют в СУБД) Доступность будет равно Ложь.

Состав реквизитов корневого элемента и подчинённых элементов немного отличается, но в целом одинаков:

Перед копированием ИБ функцией "Скопировать из родителя" можно поменять у приёмной базы: Кластер, СУБД, Каталог СУБД. В этом случае база будет скопирована и размещена на другой СУБД и в другом кластере. Это удобно, когда проект ИБ находятся в разных контурах проекта (Продуктивный, Тестовый контур, Контур разработки).

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

Для толстого клиента УФ в форме списка (дерева) дополнительно отображаются оперативные параметры ИБ в кластере: 

• Установлена и действует (по дате окончания)/не установлена блокировка базы

• Установлена или не установлена блокировка регламентных заданий

• Количество сеансов

• Количество активных сеансов

Для определения параметров используются настройки сервера RAS для кластера. 

Кнопка - команда "Установить пользователя и пароль" позволяет установить выбранные имя пользователя и пароль для отмеченных в списке информационных баз, в дальнейшем эти параметры будут использоваться при запуске информационной базы из СППР.

Кнопка - команда "Открыть ИБ" запускает текущую ИБ в пользовательском режиме (ENTERPRISE)

Флаг отбора "Только активные, либо неопределяемые" включает фильтр, при котором отображаются только доступные базы. Скрываются те, которые физически отсутствуют на сервере СУБД, если это возможно определить: флаг "Не определять доступность" у СУБД выключен.

Штатная команда пометки на удаление отключена, вместо неё открывается диалог, в котором нужно указать - следует ли удалять также базу с сервера СУБД и из кластера.

Справочник Сборочные линии

Справочник предназначен для хранения и динамического формирования файла конвейера сборки в формате yml.

Для работы со справочником должен быть опубликован HTTP сервис GetPipeLine. 

Gitlab при наступлении определенных событий, таких как push, merge-request получает файл конвейера с HTTP сервиса.

Файл конвейера формируется системой СППР на основании данных о доступности информационных баз, необходимости их сборки и формирует

текст сборочной линии динамически.

К сожалению,  Gitlab не поддерживает передачу каких либо переменных в секцию include, например имени текущей ветки, поэтому текст сборочной линии генерируется сразу для всех веток, требующих сборки (по данным СППР с учетом доступности ИБ на сервере СУБД), а Gitlab CI выбирает из него подходящие для текущей ветки задания.

Для этого необходимо в ключевой файл .gitlab-ci.yml разместить строку вида:

include: 

    - 'http://gitlab.test.ru/sppr/hs/GetPipeline/CI_YML_TEST/ci-module.yml' 

где CI_YML_TEST -  Имя сборочной линии, sppr/hs корневой каталог HTTP сервисов, опубликованный из ИБ СППР. Если сама СППР опубликована на веб сервере для работы в браузере, то http сервисы рекомендуется публиковать отдельно, с другим способом авторизации, например в IIS для олицетворения может быт использована отдельная УЗ Windows связанная с УЗ пользователя - бота GitLab в СППР.

Важно! В случае, если по ссылке Вы получаете сообщение:

500 - Internal server error.

There is a problem with the resource you are looking for, and it cannot be displayed.

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

Если по ссылке текст корректно получается, но Gitlab CI/CD при запуске сборки вручную в разделе сборочные линии пишет ошибку синтаксиса:

Необходимо скопировать полученный по кнопке "Получить текст сборочной линии" в валидатор CI Iint:  CI/CD/Pipelines/CI lint.

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

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

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

stages:

    - ~!Stages

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

?
И этап StagesAndVariables содержит

stages:

    - ~!Stages

То в сгенерированный текст конвейера будут включены строки:

# шаблон этапа StagesAndVariables

stages:

    - StagesAndVariables

    - Lock

    - Copy

    - GetCF

    - Fetching

    - Convertation

    - Build

    - TestQQ

    - Update

    - Unlock

    - OnFailureUnlock

Для имени этапа определен литерал [\w\d_]+, т.е. символы латинского алфавита заглавные или прописные, числа и символ подчеркивания.

Порядок этапов можно изменять стрелками  и . 

Важно! Не создавайте одинаковых имён этапов разными регистрами символов латинского алфавита, например BUILD и Build. Уникальность имен этапов на уровне 1С поддерживается регистронезависимой.

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

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

# Преобразование в формат 1С

.job_template: &~!Stage_job

    tags: 

        - convertation

    variables:

        GIT_STRATEGY: none

    script:

        - chcp 65001

        - start "" /wait "%W_PLATFORM_1C%" DESIGNER /S %%  /N %USER_1C% /P %PASS_1C%  /UC UpdateDB /DisableStartupMessages /DisableStartupDialogs /DisableSplash /UpdateCfg %CI_PROJECT_DIR%\%UpdFile% /UpdateDBcfg -Dynamic- /Out %CI_PROJECT_DIR%\logs\%LOG_NAME%

Повторяемых частей, по умолчанию, есть всегда одна, маркированная * - эта часть будет подставляться для всех веток Git, для которых требуется сборка, для некоторых веток, параметры задания могут отличаться, например испольхзоваться другой скрипт или другой состав переменных, или другие условия. В этом случае можно на закладке "Добавить" выбрать требуемый объект сборки, например ветку версии и появится возможность для неё описать индивидуальное задание. 

Например, в секции этапа * можно разместить:

ConvertEDT_XML_~!JobSuffix: 

    <<: *~!stage_job

    stage: ~!Stage

    dependencies: []

    only:

        refs:

        - ~!Ref

        changes:

        - TEST-CONF/src/**/*

А для основной ветки проекта ветки добавить в конец условие:

ConvertEDT_XML_~!Ref: 

    <<: *~!stage_job

    stage: ~!Stage

    dependencies: []

    only:

        refs:

        - ~!Ref

        changes:

        - TEST-CONF/src/**/*

        variables:

        - $CI_PIPELINE_SOURCE == 'web'

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

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

В тексте постоянной части задания не рекомендуется использовать переменные ~! значения которых для каждой ИБ, собираемой в ветке будут разными. Например, для одного технического проекта может быть определено две информационные базы для сборки. В этом случае, если значение переменной применено будет только для одной из ИБ в порядке автоупорядочивания. Вместо этого, в постоянной части, например в тексте скрипта следует использовать переменные окружения командного процессора Windows CMD: %DATABASENAME%, Windows PowerShell &DATABASENAME, Linux bash $DATABASENAME,

А в переменной части определять их в секции скрипта variables:
      variables:
           - DATABASENAME: ~!DATABASENAME

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

Имена переменных Stages, Stage, Ref зарезервированы. Остальные переменные формируются по принципам, описанным в Справочник "Алгоритмы определения переменных", там же описан механизм сворачивания нескольких заданий в одно.

По нажатию на кнопку "Получить текст сборочной линии" можно получить текст на языке yml, например, чтобы подставить его в форму Gitlab CD/CI CI Lint для проверки корректности.

Справочник Типы СУБД

Справочник предназначен для хранения типов баз СУБД, поддерживаемых 1С:Предприятием. 

Наименование элементов должны повторять перечисление (см. ниже) т.к. имя элемента используется в процедурах администрирования кластера 1С 

• MSSQLServer - Microsoft SQL Server;

• PostgreSQL - PostgreSQL;

• IBMDB2 - IBM DB2;

• OracleDatabase - Oracle Database.

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

• Копирование из родителя - используется для создания клона ИБ для другого объекта сборки

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

• Список ИБ - для определения доступности на сервере СУБД ИБ, записанной в элементе справочника "Информационные базы"

Остальные могут дополняться по усмотрению, подробнее см. справочник "Пакетные задания"

Разделитель колонок запросов - используется в предопределенном алгоритме "Delimiters", может использоваться и в других алгоритмах справочников "Алгоритмы определения переменных", "Пакетные задания" и "Сборочные линии"

__________________

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

** Предопределенные элементы не являются на самом деле предопределенными элементами и предопределение эмулируется, так как индивидуальны для каждого элемента справочника "Типы СУБД"

Подчиненный справочник Пакетные задания

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

Все пакетные задания исполняются из формы элемента справочника "Информационные базы" и доступны пользователям с "Полными правами" либо "Администратор сборок"

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

Справочник не является самостоятельным, и подчинён справочнику "Типы СУБД" и доступен для открытия из формы элемента этого справочника. Такая логика продиктована специфичностью алгоритмов для определенного сервера СУБД. Пакетные файлы для MS-SQL будут мало полезны для Postgre SQL. 

Алгоритму подготовки переменных, и постобработке доступен через структуру "Параметры.Объект" текущий открытый элемент справочника "Информационные базы" с типом СправочникОбъект.ИнформационныеБазы, точнее ДанныеФормыСтруктура, повторяющего реквизиты справочника "Информационные базы"

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

Важно! Если определить значение переменной в алгоритме подготовке переменных, для которой существует алгоритм получения в справочнике "Алгоритмы определения переменных" то алгоритм в справочнике "Алгоритмы определения переменных" игнорируется.

Для алгоритма постобработки в структуре "Параметры" присутствует реквизит "Вывод", содержащий вывод текста пакетного задания, который может быть обработан алгоритмом, и в переданном объекте может быть установлена дополнительная переменная описывающая объект ИБ, используя экспортный метод Справочники.GLI_ИнформационныеБазы.УстановитьЗначениеПеременной**, например:

Справочники.GLI_ИнформационныеБазы.УстановитьЗначениеПеременной(Объект , "SourceLogicalDBLogName", Данное.Поле2);

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

или реквизит текущего элемента справочника "Информационные базы"

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

GLI_РаботаСПакетнымиФайлами.ПолучитьТаблицуИзТекстаСРазделителем(ТекстСТаблицей,РазделительКолонок), 

возвращаемое значение: ТаблицаЗначений с колонками Поле1,Поле2...ПолеN

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

Важно! И алгоритм подготовки переменных, и алгоритм обработки данных исполняются в безопасном режиме.

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

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

_____________________

* Текущее ограничение, в будущих версиях планируется это ограничение снять.
** Метод создан для упрощения работы с табличной частью "Дополнительные переменные", конечно же можно установить переменные непосредственно через параметры.Объект.ДополнительныеПеременные. Метод замещает существующее значение в табличной части безусловно, или создаёт если его нет.

Справочник Алгоритмы определения переменных

Справочник предназначен для хранения алгоритмов (правил) определения переменных. 

Переменные могут быть определены в пакетных файлах обслуживания сервера СУБД - справочник "Типы СУБД" и в YAML фрагментах справочника "Сборочные линии"

Переменная представляет собой литерал, начинающийся на ~! и заканчивающийся перед символом, отличным от символов латинского и русского алфавитов, цифр и знака подчеркивания. На языке регулярных выражений можно описать литералы как [A-Za-zА-Яа-я0-9_]+. литералы выделены жирным шрифтом:

copy ~!ИмяФайлаБазы_1.txt ~!ПутьКопированияФайла\

delete ~!DbName_2.mdf

В справочнике поле "Имя переменной" содержит литерал, например для приведенных выше примеров имена переменных будут:

ИмяФайлаБазы_1

ПутьКопированияФайла

DbName_2

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

Поле "Алгоритм получения" представляет собой выражение для присваивания на встроенном языке 1С:Предприятия, которое должно возвращать строковое значение, либо значение допускающее неявное преобразование в строку. При вычислении выражения доступна структура из трёх свойств:
ИБ - ссылка на элемент справочника "Информационные базы", "Этап" имя этапа, если допустимо, в противном случае значение поля будет пустая строка, "СборочнаяЛиния" - ссылка на элемент справочника "Сборочные линии", если применимо, Неопределено в противном случае.
Важно! Выражение исполняется в безопасном режиме. 

Флаг "Для общего задания". При генерации скрипта на языке YAML сборочной линии производится оптимизация получаемых заданий. Значения переменных каждого этапа вычисляются для каждой информационной базы, требующей сборки и объединяются в пул переменных и их значений. Если значения переменных получаемых в задании для каждой собираемой или тестируемой информационной базы получатся одинаковыми, то вместо отдельного задания под каждую информационную базу будет сгенерировано одно общее задание, в котором будут перечислены все ссылки (refs Git) используемые в ограничении заданий only: refs:. Если одна переменная имеет несколько алгоритмов, и один из них маркирован как "Для общего задания" то такая переменная из пула переменных для принятия решения о способе генерации заданий будет исключена. Более того, для получения значения такой переменной в общем задании будет использован именно этот алгоритм. В противном случае для каждого задания на свою ветку будет предпринята попытка вычисления алгоритма без флага "Для общего задания". Цель данного механизма уменьшить количество заданий в результирующем скрипте на языке YAML для этапов конвейера, которые для всех информационных баз будут исполняться одинаковым образом. 

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

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

Допустим, в повторяемой части шаблона задания определена переменная Stub, у которой алгоритм получения "JustOneLine":

ConvertEDT_XML_~!JobSuffix: 

    <<: *convertation_job

    stage: ~!Stage

    dependencies: []

    variables:

        STUB: '~!Stub'

    only:

        refs:

        - ~!Ref

        changes:

        - TEST-CONF/src/**/*

Результирующее задание:

ConvertEDT_XML_United: 
    <<: *convertation_job
    stage: Convertation
    dependencies: []

    variables:

        STUB: 'JustOneLine'

    only:
        refs:
        - master
        - TP/00-00000256
        - Tst/102
        changes:
        - TEST-CONF/src/**/*

Если заменить алгоритм получения переменной Stub на: Строка(Новый УникальныйИдентификатор()), то результирующие задания получатся такие:

ConvertEDT_XML_CI_YML_TEST: 

    <<: *convertation_job

    stage: Convertation

    variables:

        STUB: '0a09ca20-8f4a-48f7-8110-e6f2a8303a93'

    dependencies: []

    only:

        refs:

        - master

        changes:

        - cpm/src/**/*

ConvertEDT_XML_CYT.TP.00-00000256: 

    <<: *convertation_job

    stage: Convertation

    variables:

        STUB: 'c2000413-49d1-4b7f-a954-534421cad798'

    dependencies: []

    only:

        refs:

        - TP/00-00000256

        changes:

        - cpm/src/**/*

ConvertEDT_XML_CYT.Tst.102: 

    <<: *convertation_job

    stage: Convertation

    variables:

        STUB: '86418d3c-9e00-4229-bdb0-a7e2fe9bcb4c'

    dependencies: []

    only:

        refs:

        - Tst/102

        changes:

        - cpm/src/**/*

Однако, если для переменной Stub добавить 2й алгоритм получения с признаком "Для общего задания", например "Федот да не тот" то результат станет таким:

ConvertEDT_XML_United: 
    <<: *convertation_job
    stage: Convertation
    dependencies: []

    variables:

        STUB: 'Федот да не тот'

    only:
        refs:
        - master
        - TP/00-00000256
        - Tst/102
        changes:
        - TEST-CONF/src/**/*

Отчет Подготовка описания версии по техпроектам и ошибкам

Отчет предназначен для подготовки описания релиза. Уровень детализации рассчитан таким образом, чтобы описание обновления, выводимое средствами БСП не делать вручную, а просто скопировать из сформированного отчета:

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

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

Для остальных ошибок поле внизу:

Кроме этого, учитывается:

• Для идей, реализованных в рамках технических проектов, выводящихся в секции "Реализация функционала"

  • Идея должна быть в статусе "Реализована"

  • Ветка технического проекта должна быть помещена в ветку версии - статус "Помещена"

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

• Для любых ошибок:

  • Статус ошибки должен быть "Проверена, исправлена", для ошибок, исправляемых в разных ветках состояние исправления в ветке нужной версии должно быть "Исправлена и проверена", в этом случае ошибка выводится в секции "Исправление ошибок" 

  • Статус ошибки должен быть "Отозвана", для ошибок, исправляемых в разных ветках состояние исправления в ветке нужной версии должно быть "Не планируется исправлять", в этом случае ошибка выводится в секции "Не является ошибкой (отозвано)"

  • Ошибка должна быть публикуемой (закладка "Признание", "Статус публикации")

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

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

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

Для ошибок, разделяясь пустой строкой, выводятся секции "Публикуемое описание", закладка "Признание" и "Описание" закладка "Исправление"

Для реализованных идей выводится описание реализации идеи в техническом проекте колонка "Описание реализации идеи, исправления ошибки" закладки "Идеи и ошибки"

Расширение объектов основной конфигурации

Справочник Ошибки

Изменены логика формы списка и формы элемента. Улучшена эргономика работы с исправлением ошибок в варианте "В разных ветках", т.к. разные состояния исправления в ветках приводили к неразберихе и не соответствию общему статусу ошибки. Для этого были расширены и дополнены состояния исправления ошибок в ветке и статусов ошибки, так чтобы они соответствовали друг другу:

 * Добавленные состояния исправления в ветках

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

*** Статус отозвана допускается только когда в ветках исправления ошибку исправлять не планируется.

В форме списка:

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

• Пиктограмма около состояния умышлено отображает некий общий статус ошибки, который определяется по следующим критериям:

  • До тех пор, пока хоть в одной ветке есть состояние "Не рассмотрена" общий статус всегда "Зарегистрирована"

  • До тех пор, пока хоть в одной ветке указано "Требуется исправление" общий статус "Признана", при этом в некоторых ветках может быть ошибка уже исправлена и подтверждена, а в некоторых в состоянии "Исправление не планируется", что соответствует статусу "не признана"

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

  • Если все ветки проверены и исправлены, за исключением тех, в которых исправление не планировалось, то общий статус будет "Проверена и исправлена"

• Общий статус можно отобразить в списке через "Изменить форму" добавив поле Ссылка.Статус.

В форме элемента:

• Для варианта "Исправляется" = "В разных ветках" комбинация кнопок "Признать", "Не признавать", "Исправление не планируется", "Отметить исправление". "Подтвердить исправление" теперь зависит от того, в какой строке табличной части "Исправление в ветках" установлен курсор. Если ни одна строка не выбрана технически, считается что для первой. Соответственно можно выбирать состояние исправления как с помощью кнопок, так и с помощью установки состояния исправления. Так же табличная часть дополнена графами "Рассмотрена" с датой рассмотрения ошибки "Требуется исправление/ Исправление не планируется", и "Подтверждена", которая заполняется при подтверждении исправления в ветке.

• При регистрации новой ошибки вариант исправления "Только в ветке обнаружения"

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

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

• Если исправление ошибки ведётся в ветке исправления ошибки, с которой не связана информационная база, то при отметке исправления будет создан запрос на слияние в хранилище Git в ветку тестирования (см. подробнее про ветку тестирования в дополнении к описанию по справочнику "Ветки"), при отсутствии конфликтов запрос на слияние будет автоматически принят. При очередной сборке ветки тестирования (момент зависит от настройки для ветки сборочной линии, по умолчанию, сразу же после удовлетворения запроса на слияние) автор и исправивший получат уведомления об успешном завершении сборочной линии ветки тестирования в контекстном обсуждении ошибки, там же будет ссылка на открытие ИБ, которая была обновлена новым состоянием хранилища в ветке тестирования. Проверяющий (автор) проверяет исправление в базе и отмечает нажатием кнопки "Подтвердить исправление" (либо выставляет статус в строке таблицы "Исправление в ветках" соответствующего состояния исправления для варианта исправляется в разных ветках). В момент записи "Ошибки"  автоматически формируется запрос на слияние в основную ветку версии.

• На закладке дополнительно флаг "не делать запрос на слияние в тестирование" при выборе этого флага не будет сформировано запроса на слияние в ветку тестирование.

• Для варианта "Исправляется" = "В разных ветках" кнопка "Создать ветки для исправления" заменена на "Создать ветку для исправления" соответственно, в отличие от типового варианта создаётся ветка только для выбранной строки. 

• Создавать ветку исправления ошибки, а так же заполнять в реквизите объекта "Ошибка" не обязательно, при создании ветки в удалённом репозитории Git, или при помещении изменений новой ветки исправления ошибок автоматически предпринимается попытка найти, при необходимости создать новую ветку и заполнить её в соответствующем реквизите. Автоматическое заполнение ветки исправления доступно для вариантов исправления "Только в ветке обнаружения" и "В разных ветках". Порядок определения родительской ветки (учитываются только ветки версии и основная ветка проекта) следующий:

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

  • Если ветка уже ушла от родительской на несколько фиксаций. В этом случае определение родительской ветки производится по самой короткой цепочке фиксаций от merge-base с ветками версий. В случае неоднозначности, ветка не создаётся, пользователю в СППР, соответствующему пользователю Git выдается сообщение о невозможности автоматического создания ветки исправления. Сопоставление пользователя СППР и пользователя Git производится по адресу эл. почты, если у пользователя Git он публичный. Если электронная почта не публичная, то производится попытка сопоставить адрес почты в СППР и имя регистрации на сервере Git. Если пользователь не найден, то сообщение о создании ветки и заполнении её в исправлении ошибки выдаётся Исправившему или, при его отсутствии, Автору. Если какой-либо пользователь начал редактировать ошибку в СППР, то заполнение поля ветки исправления ошибки производится через оповещение СВ на клиенте. Таким образом данные, введенные пользователем, не будут потеряны.

Справочник Технические проекты

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

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

На закладке "Дополнительно" добавлена кнопка создания запроса на слияние  в ветку версии. 

Так же, на закладке "Дополнительно" возращён реквизит "Имя базовой ветки". При указании фиксации в этом поле файл отличий (diff) будет производиться между веткой техпроекта и указанной фиксацией, такой способ указания помогает корректно загрузить изменения в случае, когда перед слиянием в ветку версии ветка техпроекта обновлялась до текущего состояния ветки версии (это делается очень часто, чтобы исключить конфликты слияния при помещении ветки техпроекта в ветку версии). 

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

Справочник Ветки

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

• Кнопка  "Создать ветку в git" - создаёт ветку в хранилище Git, ссылка на который указана в элементе справочника "Проекты", на закладке разработка. Создание ветки производится посредством доступа к API Gitlab настроенным в обработке "Настройка уведомлений о сборках и подключение к GitLab API"

• Кнопка «Создать запрос на слияние» - создаёт запрос на слияние в ветку слева от кнопки

• Поле "Ветка тестирования" и кнопка около него "Пересоздать в Git":

В активной фазе проекта может быть зарегистрировано много ошибок, требующих подтверждение исправления. Рекомендуется в таких фазах не исправлять ошибки в ветке версии проекта, либо в одной ветке исправления ошибок, а под каждую заводить отдельную от ветки исправления ошибок, при отметке "Исправлено" в элементе справочника "Ошибки" будет автоматически сформирован и принят (если нет конфликтов) запрос на слияние в ветку тестирования, которую рекомендуется пересоздавать после выпуска каждого релиза. При подтверждении тестировщиком или автором ошибки исправления будет сформирован автоматически запрос на слияние в ветку версии. Таким образом в ветке версии будут только подтвержденный функционал. По событию "detached pipe" могут быть запущены регрессивные тесты сливаемой в ветку версии ветки исправления ошибки. Автоматического принятия запросов на слияние в ветку версии не предусмотрено. Ответственный за сборку релиза сам должен проверить и принять все исправления в ветку версии. При нажатии на кнопку "Пересоздать в Git" ветка тестирования удаляется в хранилище и создаётся заново от указателя ветки версии, после чего определяются удовлетворённые запросы на слияние в ветку тестирования, которых не было в ветке версии (по учетным данным СППР), СППР заново формирует запросы из веток исправления ошибок в ветку тестирования. 

• Секция "Информация о сборке" - версия, сборка заполняются автоматически. Версия, аналогично типовому функционалу, определяется из ссылки элемента справочника "Версия проекта", сборка прописывается автоматически каждый раз при начале и окончании сборки в GitLab и соответствует номеру сборочной линии.

• Секция GLI уведомления, информация. Добавляются пользователи - кураторы ветки, эти пользователи будут получать уведомления о сборках ветки вне зависимости от объектов сборки (Ошибки, техпроекты). Если этот список пуст, и при сборке ветки (например, запущенной по расписанию или вручную) новых объектов сборки, по данным СППР, не добавится - уведомления не придёт никому.

Подчиненный справочник Сборки версии

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

• pending (ожидание)

• running (запущена)

• canceled(отменена)

• failed(завершилось с ошибкой)

• success(завершилось с успехом) 

записывается в добавленный реквизит объекта, который выведен в форму элемента. 

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

Дата и время сборки определяются по данным сервера СППР.

Обработка Настройка уведомлений о сборках и подключение к GitLab API

Обработка предназначена для настроек бота уведомлений системы взаимодействия (СВ), указания связей id проекта в Gitlab, приватного ключа пользователя СППР в Gitlab  настроек уведомлений для администраторов сборок.

Настройки бота

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

Важно! Изображение бота хранится в СВ, так что замена изображения в копиях ИБ, не отвязанных от СБ приведёт к изменению изображения в основной базе.

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

См. ниже пример настройки пользователя в IIS

Важно! Если база СППР опубликована на веб сервере в виде тонкого клиента, то для HTTP сервисов потребуется отдельная публикация с использованием анонимной аутентификации, в которой должен быть указан тот же пользователь системы, что и в этом поле. Например, основная публикация СППР сделана как sppr и доступ к ней осуществляется по ссылке https://my_server.ru/sppr то для http сервисов компоненты нужно сделать вторую публикацию - только http сервисы, например sppr_api и указывать ссылку https://my_server.ru/sppr_api. Аутентификация должна быть настроена таким образом, чтобы любое обращение к API приводило к авторизации пользователя бота, права которого в СППР минимальны (права (Внешнее соединение, HTTP REST сервисы) настраиваются автоматически при создании пользователя). не рекомендуется давать этому пользователю прав более, чем устанавливается автоматически. 

Соответственно ссылка, которую нужно будет указать в разделе Gitlab WebHooks: https://my_server.ru/sppr_api/hs/BS/file.json

Откройте проект в Gitlab и в разделе Settings/Webhooks. Укажите полученный URL http-сервиса BS СППР. Отметьте события Push events, Merge request events, Pipeline events. Установите или снимите флаг SSL верификации в зависимости от типа публикации. Нажмите кнопку Add webhook.

Проведите тестирование, нажав на кнопку Test/Push events. Gitlab отправит событие push с SHA на который указывает origin/master в качестве теста. Откройте регистр сведений JSON, если появилась запись, соответствующая по времени отправке и по комментарию соответствующая фиксации указателя origin/master в проекте - значит настройка API СППР проведена верно. Можно ещё открыть, нажав на кнопку Edit, отправленные веб хуки, и, открыв последний, просмотреть детали - сообщение JSON. Это же сообщение должно быть в регистре сведений JSON в поле "Запрос". Важно! Процедур очистки регистра сведений JSON не предусмотрено, очищайте его самостоятельно во избежание разрастания ИБ СППР.

Ссылка для получения файла конвейера будет выглядеть как https://my_server.ru/sppr_api/hs/GetPipeline/PipelineOfMyProject/ci-module.yml, где PipelineOfMyProject - имя элемента справочника "Сборочные линии"

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

В секции Настройки gitlab API для каждого проекта указать следующие настройки:

• Идентификатор проекта в Gitlab

• Частный токен пользователя, от лица которого СППР будет авторизоваться, например "СППР".  Важно! У этого пользователя должно быть достаточно прав для того, чтобы принимать запросы на слияние в ветки тестирования и создавать запросы на слияние в ветки версии, а также удалять ветки.

• Префиксы веток, если не указывать, то будут использоваться префиксы веток указанные в образце заполнения. В типовом релизе СППР наименования веток получаются очень длинными, в результате их не удобно просматривать в истории EDT, поэтому не рекомендуется делать префиксы веток длинными.  Важно! префиксы со слешем "/" формируют подкаталоги в учётной системе Git, Windows не различает верхний и нижний регистр при поиске, поэтому после выбора префиксов с "/", крайне не рекомендуется менять у них регистр.

Варианты и особенности сценариев учета исправления ошибок в СППР при использовании расширения «Управление сборкой GLI»

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

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

2. Объектом сборки считается любой объект, ссылающийся на ветку сборки (элемент справочника «Ошибки» в поле «Ветка исправления» шапки или в поле «Ветка исправления» в ТЧ «Исправления в ветках» или в поле «Ветка разработки» справочника «Технические проекты»), у которого не заполнен реквизит «Сборка» и статус либо «Исправлена», либо «Исправлена и проверена». У справочника «Ошибки» реквизит «Сборка» в зависимости от способа исправления ошибки (в разных ветках или в одной) может быть либо внизу, над кнопками:
   
   либо, если исправление ветки ведётся в разных ветках, в табличной части «Исправления в ветках»:
   
   Технический проект:
   
   Значение поля очищается:

   1. При записи элемента справочника «Ошибки» со статусом «Исправлено» или «Исправлена и проверена», либо в шапке, либо в табличной части «Ветки»

   2. В шапке технического проекта, при направлении на проверку задачи процесса технического проекта.

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

3. Если поле «Сборка» не заполнена, то объект включается в уведомления при сборке ветки связанной с объектом сборки, пользователи для уведомления извлекаются из объекта сборки, если нет ни одного объекта сборки ожидающего сборки, связанного с собираемой / тестируемой веткой то пользователи для уведомления выбираются из ветки, для веток версий, тестирования этот список доступен для заполнения.

В ветке с типом «Ветка для исправления ошибок»:

Без индивидуальной ИБ, для проверки исправления используется общая ветка тестирования ветки версии.

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

  • Обособлено:

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

    • Под исправление каждой ошибки создаётся индивидуальная ветка.

  • Совместно:

    • Порядок учёта исправлений ошибок для такого варианта аналогичен предыдущему, и по-прежнему будет возможность тестировать исправления в ветке тестирования. Разница в том, что заводится одна ветка с наименованием, например, «BF/COMM-1» или «BF/ClsMnth-11». Далее, исправление ошибок по очереди фиксируются в ветке, после каждой отметки исправление происходит слив фиксации в ветку тестирования, а при отметке подтверждено делается запрос в ветку версии. Такой вариант удобен, когда исправляется много мелких ошибок, объединенных по какому-либо признаку, например ошибки при закрытии месяца. Или в том случае, когда обособленные исправления зарегистрированных ошибок не имеют смысла.
      Важно! При отметке исправления или подтверждение любой исправленной ошибки вся ветка будет влита либо в ветку тестирования, либо в ветку версии. В таком сценарии трудно будет исключить неподтвержденный код какой-либо ошибки из общей ветки, помочь в этом сможет операция интерактивного перебазирования, при которой фиксации с неподтверждёнными ошибками можно пропустить, однако нужно иметь в виду, что при возникновении конфликта слияния во время операции перебазирования, возможности EDT сильно ограничены типовым функционалом Git и разрешать конфликты придётся вручную.

С выделенной, привязанной к объекту сборки (ошибке или ветке) ИБ.

• Запросов на слияния в ветку тестирования не производится. Однако запрос на слияние в ветку версии будет сформирован при подтверждении исправления. В этом варианте при сборке выдаётся заголовок и сообщение из хранилища Git к фиксации, для которой производится сборка:
  
  Пропущенные фиксации, по которым не проходила сборка не отслеживаются. См. пример исправление ошибки BF/00-00000004 на демонстрационном стенде.

  • Обособленно:

    • Привязка ИБ производится к объекту сборки: элементу справочника «Ошибки».

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

  • Совместно:

    • Тестовая ИБ в этом случае привязывается к ветке, т.е. в качестве объекта сборки выступает ветка исправления ошибок.

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

В ветке версии:

ИБ привязана к ветке версии.

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

В ветке технического проекта

ИБ привязана к техническому проекту.

В ветках технических проектов регистрируют особый сорт ошибок, которые как правило ещё не дошли до релиза. Чисто технически уведомления ничем не отличаются от варианта исправления ошибки «С выделенной, привязанной к объекту сборки (ошибке или ветке) ИБ.» Ошибки подобного рода выявляются при внутреннем тестировании в ИБ, связанной с веткой технического проекта. Если технический проект ещё активен, как правило ошибку добавляют в этот же технический проект, где она прописывается на закладке «Идеи и ошибки» в остальном работа с ошибкой не отличается от обычной ошибки, исправляемой в ветке исправления ошибки. Так же, в рамках технических проектов исправляются ошибки, найденные в выпущенных релизах и исправление таких ошибок, может привести к изменению кода будущего функционала, который в настоящий момент дорабатывается. Подробнее о таких ошибках можно прочитать здесь: 9.6. Работа с ошибками, требующими проектирования :: 1С:Предприятие 8. Конфигурация «Система проектирования прикладных решений». Редакция 2.0. Руководство пользователя (1c.ru). При сборке ветки если в техническом проекте нового функционала не реализовали (задач процессов на проверку не было передано) – номер сборки в ТП остаётся прежним, а номер сборки прописывается только в ошибке. Важным плюсом является возможность не описывать подробно изменения в метаданных ошибки, так как все изменения ветки технического проекта будут загружены в таблицу ОМД вместе с данными технического проекта. Следует отметить, что графа «Описание реализации идеи, исправления ошибки» не используется в части ошибки при формировании отчёта: «Отчет Подготовка описания версии по техпроектам и ошибкам» для вывода исправлений используется текст с соответствующей закладки ошибки «Исправление».

Сценарии создания веток в Git и взаимосвязь веток Git с одноименным справочником «Ветки» в СППР.

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

Создание веток из СППР

Утилита расширяет возможности типового функционала для работы с ветками Git. Основная ветка проекта - master вводится автоматически при создании нового проекта в СППР. В Git на создаётся по умолчанию при создании первой фиксации в хранилище. Все остальные ветки можно создавать в СППР через нажатие кнопки с пиктограммой: . При нажатии на кнопку в удалённом Git будет предпринята попытка создания ветки, если попытка успешна – будет выдано соответствующее сообщение, при неудачном создании будет выдано диагностическое сообщение. Для получения ветки в локальный клон хранилища разработчику необходимо выполнить операцию Получить из удаленного хранилища (Fetch).

Создание веток в СППР при первичном помещении ветки в удаленное хранилище

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

Технические моменты и способ поиска базовой (исходной) ветки описан здесь. Аналогичное поведение будет предпринято при создании ветки в веб интерфейсе Gitlab.

Разворачивание демонстрационных баз и подключение к GitLab CI/CD

Демонстрационная база и примеры в ней ориентированы на работу с СУБД MS-SQL, несмотря на то, что изначально соблюдались требования к кроссплатформенности. Возможно кому то и примеры покажутся не современными, так как в качестве командного процессора используется CMD, который начиная с 13 релиза бегунов гитлаба вроде как и не поддерживается уже, но почему то работает.

Вариант для Windows/MSSQL

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

1. ПК, на котором установлено:

   1. Сервер 1С:Предприятия, желательно не ниже 8.3.17.1549, возможно можно и ниже, но не могу гарантировать работоспособность. Для исключения различного рода неожиданностей, рекомендую поставить именно указанную версию платформы. Блокировка ИБ для обновления запуском с ключом /C ЗавершитьРаботуПользователей требует корректно настроенного соединителя COM comcntr.dll. В противном случае задание блокировки будет зависать на первом же этапе. 

   2. СУБД MS-SQL от 2012 и выше.

   3. Веб сервер (для публикации HTTP сервисов СППР) примеры будут на IIS, но естественно может быть и любой другой. У сервера Gitlab должен быть к веб серверу СППР доступ.

   4. Тестовая ИБ на базе БСП.

   5. Демонстрационная база СППР.

   6. EDT. В него потребуется импортировать тестовую базу на базе БСП, создать из неё проект и запостить его на сервере gitlab, требования к нему читаем ниже.

   7. Рекомендую поставить, если ещё не стоит на ПК Notepad++

   8. Я рекомендую для простоты все сервисы развернуть именно на одном ПК, если всё же вам немного хочется экстрима, и у вас все сервисы разнесены по разным, не забываем, что серверу 1С, на котором стоит и работает ИБ СППР нужен доступ к СУБД (1433 порт по умолчанию для MSSQL) и серверу тестового контура, где будет развёрнута тестовая ИБ на базе БСП (порты кластера должны быть доступны, по умолчанию это 1540,1541).

2. Вам потребуется учётная запись в сервисе gitlab.

   1. Это может быть учётная запись в https://gitlab.com/ 

   2. Или ваш локально (например, в интрасети компании) развёрнутый Gitlab CE или EE, важно чтобы он был версии не ниже 11.2. 

      1. Чтобы корректно отрабатывали описанные примеры в тексте по тестам в формате jUnit, в GitLab должны быть произведены некоторые настройки. Т.е. Вам, возможно, потребуется доступ c привилегиями администратора к серверу Gitlab, чтобы включить всё это. Чтобы проверить откройте веб интерфейс Вашего сервера gitlab и добавьте в конец (выделено жирным) http://gitlab.myserver.int/help/ci/junit_test_reports.md, если не получите ошибку 404, а вместо неё получите инструкцию, значит скорее всего Вам придётся включить эту возможность, как там и описано, если нет и версия точно выше 11.2 то скорее всего всё уже включено. Вообще говоря по простому включение элементарно, в линуксовом terminal'е сервера с gitlab нужно набрать: 
         sudo gitlab-rails runner “Feature.enable(:junit_pipeline_view)”

      2. Или, если вас тестирование и хранение результатов в формате junit не интересует, вам просто нужна возможность опубликовать ваш проект в любом сервисе gitlab.

3. Сервисы бегунов гитлаба (gitlab-runner). В демонстрационных целях мы обойдёмся одним, запуская его из командной строки. Но я рекомендую настроить 2, один установить как службу (с повышенными привилегиями SYSTEM) и один запускать из командной строки в окне терминальной сессии и не завершать её, просто отключать. У них будет разный набор тэгов. 

4. Терпение, терпение и ещё раз терпение :)

Более подробно, по шагам. 

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

От этой схемы в реальной жизни были сделаны некоторые отступления, потому что эта схема была разработана для документа "Технология разветвлённой разработки, использующая git, ci/cd". Одно из отступлений отсутствие ветки release (в СППР > 2.0.2.12 для неё нет места), а с учётом технологии работы ветки версии, надобность в ней просто отпала. Другое отличие, что при организации доступа сервера СППР к тестовому контуру, СППР может находиться за пределами тестового контура, и, таким образом, быть разделена между проектами. Мы так и работаем.

1. Формируем эталонные и тестовые базы в контуре тестирования

   1. По правилам лицензионного соглашения, я не имею права выкладывать выгрузку (DT) демонстрационной базы, поэтому разворачиваем из дистрибутива конфигурации пустую базу СППР версии 2.0.4.15 на сервере 1С рекомендуемой версией платформы 8.3.17.1549

   2. Скачиваем одним архивом расширение GLI.CFE, выгрузку тестовой ИБ на базе БСП DemoAM.DT, обработку выгрузки и загрузки через XML, как оказалось они тоже между версиями несовместимы и данные для загрузки SPPRData.xml.

   3. В развёрнутой ИБ придётся включить возможность изменения конфигурации всю или частично - на ваше усмотрение. Нужно включить иерархию элементов у справочника "Ветки" без ограничений. В расширении с учётом совместимости этого сделать невозможно. С рекомендуемой версией платформы конфигурация не запустится, поэтому сразу загружаем расширение GLI.CFE
      После применения расширения и реорганизации запускаем на выполнение. По окончании первоначального заполнения увидите историю версий расширения и основной конфигурации.

   4. Добавьте пользователя с административными привилегиями, исключая имена Администратор и Иванов Иван Иванович (эти двое приедут с выгрузкой). Так же, создайте группу доступа "Открытие внешних отчетов и обработок" с одноименным профилем к внешним отчётам и обработкам, и добавьте этого пользователя туда. Поставьте стойкий пароль пользователю, если ИБ будет опубликована в интернете. Если вы будете полностью демонстрацию разворачивать у себя в интрасети (т.е. и gitlab тоже будет развернут внутри организации) и вы доверяете коллегам - можете не ставить пароли. Перезапустите ИБ СППР с новым пользователем.

   5. Откройте приложенную обработку выгрузки/загрузки и загрузите демонстрационные данные SPPRData.xml:
      Загруженным пользователям Администратор и Иванов Иван Иванович дайте при необходимости стойкие пароли и добавьте их в группы Администратор и группу пользователей внешних обработок.
      Перезайдите в СППР от Иванова, или добавьте своего пользователя в группы уведомления в ветках.

   6. Создаём в кластере 1С пустую ИБ, назовите DemoAM (assemble management - управление сборкой), так будет проще копировать настройки и примеры.  Загрузите в неё скачанную выгрузку тестовой ИБ на базе БСП.

   7. Учётной записи пользователя кластера, где развернёте СППР требуется повысить привилегии, так как она будет запускать много всяких пакетных файлов. Для этого нужно убрать запрет для этого пользователя на локальный вход. Открываем  Win+R, в строке вводим gpedit.msc и "ОК", далее согласно картинке удаляем УЗ службы 1С из группы запрета локального входа:
      
      Если пользователя вы создавали сами, например доменного, то скорее всего это вам не потребуется , потому что 99% админов этого пользователя в указанную группу не включают.

   8. Запускаем базу СППР должно появиться меню подсистемы управления сборкой:
      

   9. Создаём элементы справочников СУБД, Кластер 1С, у меня это элементы с именем ПК: CHECK, где развёрнуты кластер 1С, СУБД MS-SQL, Вам нужно будет подставить свои. У меня кластер указанной версии развернут на портах выше 1940, если у Вас по умолчанию на портах выше 1540, то порт в имени кластера можно не указывать.
      

   10. Далее, создаём информационную базу в одноименном справочнике, заполняя поля в последовательности как на рисунке:
       
       Конечно же порядок заполнения полей 1-7 может быть любой, главное чтобы они были корректно заполнены до нажатия на кнопку "Заполнить дополнительные переменные". Если вместо сообщений внизу как на снимке выше вы получаете другие сообщения:
       
       
       Если же всё проверили и всё равно что то не получается, то необходимо добиться, чтобы с сервера 1С, где развёрнута ИБ СППР был доступ к выбранному Вами SQL серверу из командной строки посредством SQLCMD, да поможет Вам Google или Яndex:

C:\Users\USER>sqlcmd -S CHECK -U sa -P *******(ваш пароль здесь) -h -1 -b -Q "SELECT name FROM master.dbo.sysdatabases WHERE name LIKE 'DemoAM'"
DemoAM
(1 rows affected)
C:\Users\USER>

14. Если всё получилось корректно то в списке ИБ напротив вашей добавленной ИБ будет зелёный кружок с галкой:
    
    !ВАЖНО! Тестовая ИБ уже готова к размещению в тестовом контуре: конфигурация стоит на полной поддержке без возможности изменения. Имитируется ситуация, когда вы создали ИБ из шаблона поставщика. Нельзя размещать базы с включённой возможностью изменения. Если по каким то причинам прежде чем начать работать с базой вам потребовалось в конфигурации включить возможность изменения, то нужно снова выключить возможность изменения и вернуть ИБ с состоянию как от поставщика, чтобы не потерять данные можно просто сохранить конфигурацию поставщика в файл, за затем загрузить эту конфигурацию игнорируя предупреждения, все сделанные изменения, естественно будут потеряны. Если в структуре базы были внесены изменения и вам их нужно сохранить, например, вы прежде чем выложить в тестовый контур исправили критичную ошибку поставщика, а обновления от него нет. В таком случае, создайте с этой базы файл поставки CF, и его загрузите в конфигурацию. Получите конфигурацию на полной поддержке, без возможности изменения но уже с вашими изменениями. На качество последующих обновлений от поставщика это сильно не повлияет, с учётом того каким образом предлагается её обновлять, однако будет считаться, что поставщик ваши изменения "удалил", поэтому лучше всё же сначала поместить типовую, свои изменения сохранить в отдельный CF, и они отдельной фиксацией пройдут в изменениях от типового. Во всех клонах базы будут иметь разную конфигурацию, относительно изначальной, в соответствии с веткой, к которой они привязаны, но все они должны быть на полной поддержке без возможности изменения. Ещё см. ниже раздел "Как обновлять базы при работе в EDT".

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

Конечно же в реальных проектах, где ИБ может иметь размеры более 50 Гб, копирование может отнять больше времени. Всё будет зависеть от Вашего оборудования. Поскольку хранилище проекта в gitlab ещё не создано, то полная идентичность всех трёх ИБ вполне нормальное явление, так как по сути 3 несуществующих указателя веток указывают сейчас в одно место - "в никуда".

16. Далее, нужно проверить корректность формирования сборочной линии, прежде чем это сделать, добавим алгоритм  определения переменной в одноименном справочнике - LockVersion и алгоритм "STD". В логике сборочной линии анализируется значение этой переменной на значение SSL, и в этом случае параметры передаются немного иные, тестовая база создана на БСП версии ранее чем 3.1.5 и код завершение работы пользователей пропатчен, до функционала БСП, который есть начиная в версии 3.1.5. Если Вы вдруг захотите попробовать в качестве тестовой ИБ свою какую то базу, проверьте версию БСП, если она 3.1.5 или выше - тогда алгоритм нужно написать "SSL". После создания дополнительной переменно открываем справочник "Сборочные линии", там уже должен быть один элемент DemoAM, встаём на него и жмём кнопку "Получить текст сборочной линии". Копируем полученный текст и вставляем в Notepad++ и выбираем синтаксис YAML, далее нажимаем Alt+0, чтобы свернуть группы YAML. Должно быть примерно следующее:
    
    Если вывод похож как на картинке, за исключением ваших имён серверов СУБД и кластера 1С то переходим к следующему этапу.

2. Настройка системы взаимодействия и интеграции СППР с gitlab в тестовом контуре

   1. Первым делом подключаем систему взаимодействия, инструкций как это сделать есть на ИТС: Глава 6. Администрирование информационной базы :: Руководство администратора :: 1С:Предприятие 8.3.19. Документация (1c.ru). Без этого шага вы в следующий не попадёте.

   2. Следующий шаг настройка бота, получение токенов из gitlab и подключение СППР к ней.

      1. Открываем меню Управление сборкой/Сервис/Настройка уведомлений о сборках и подключение к Gitlab API
         Заполняем поля, к полям простые подсказки, я поставил другой аватар для бота, чтобы отличать его от собственных тестовых баз, и жмём "Создать бота"
         
         Обработка сама создаст пользователя СППР, отключит у него аутентификацию 1С и включит аутентификацию ОС для указанного пользователя. В результате должна форма немного изменится, вместо кнопки "Создать бота" появится кнопка "Обновить бота". В списке пользователей должен появиться новый пользователь:
         
         Обработка так же создаст в системе взаимодействия одноименного пользователя и свяжет его с пользователем системы.

      2. В проектной деятельности, Вам лучше всего будет создать служебную учётную запись СППР в сервисе gitlab, добавить его в проект (потом вы можете этого же пользователя использовать и в других проектах). Но в демонстрационных целях мы засорять сервисы gitlab служебными пользователями не будем, я привяжу свой токен. Открываем наш сервис gitlab, у меня это будет ссылка http://gitlab.чекушкины.рф/-/profile/personal_access_tokens
         
         Теперь пропишем скопированный токен в СППР, чуть позже придётся вернуться к этой настройке, чтобы прописать идентификатор созданного проекта:
         

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

3. Публикация HTTP сервисов СППР на веб сервере. (контур тестирования)

   1. На этом этапе я предполагаю, что вы уже заранее установили на свой ПК веб сервер, настроили его и к нему есть доступ для сервисов веб хуков gitlab. Я в своих примерах буду использовать штатный сервер https://gitlab.com, для того чтобы у него был доступ к моему СППР, мой локальный сервер IIS редиректится в домен http://чекушкины.рф, однако не все программы знают её [кириллицу], и поэтому в ссылках и коде вместо красивой кириллицы он будет выглядеть как http://xn--e1agfaq7azal4a.xn--p1ai, поэтому не думайте, что это ошибка, это нормальная двуличность кириллических доменов. В самом начале, когда я описывал возможности функционала в части получения сборочных линий я уже сослался на опубликованную DemoAM базу СППР. Не пытайтесь открыть веб интерфейс опубликованной базы СППР, я его не публиковал из соображений безопасности, однако наша рабочая СППР опубликована в интернет, это пришлось сделать с появлением первого внештатника. 
      Есть отличительная особенность, при публикации штатными средствами HTTP и веб сервисов, сделанных в расширении: при публикации ИБ на веб сервере вы не увидите ни одного HTTP сервиса из расширения, это особенность поведения конфигуратора. Поэтому, запускаем конфигуратор с повышенными привилегиями, и публикуем все http сервисы конфигурации. Если вы всё же захотите в итоге опубликовать вашу СППР в интернете, то для основной публикации базы и для http сервисов сделайте разные публикации, это связано с разными способами аутентификации. Для основной базы вы можете использовать "Проверку подлинности Windows", либо "Анонимную подлинности подлинности", для http сервисов СППР проверка может быть только анонимной, причём олицетворяющий пользователь должен быть создан отдельный в системе, например локальный пользователь сервера, где установлен сервер 1С для СППР и там же веб сервер. Поэтому открываем локальных пользователей и создаём. Не забываем про хороший пароль, в случае, если ваш веб сервер виден из интернета.
      

   2. Открываем конфигуратором демо базу СППР, для публикации на веб сервере. Конфигуратор нужно запускать с повышенными привилегиями (Запуск от имени администратора), Администрирование/Публикация на веб сервере
      Соглашаемся на перезапуск. Если у Вас отдельный пул приложений под выбранную версию платформы (под каждую версию он должен быть отдельный, в противном случае будете получать периодически ошибку 500), то после нужно обязательно назначить его созданному приложению.

   3. Для проверки работоспособности веб сервиса получим сборочную линию,  у меня это будет ссылка: http://Чекушкины.рф/DemoAM/hs/GetPipeline/DemoAM/ci-module.yml (xn--e1agfaq7azal4a.xn--p1ai) , где DemoAM - имя публикации на веб сервере, hs/GetPipeline - имя HTTP сервиса, второй раз DemoAM - имя сборочной линии, и ci-module.yml - остаток от шаблона HTTP сервиса. В качестве ответа должны получить вывод, аналогичный при нажати и на кнопку "Получить текст сборочной линии":
      

4. Создаём хранилище проекта из контура разработки.

   1. Встаём на любой из трёх ИБ в тестовом контуре (напоминаю, они пока ещё полностью идентичны), но чтобы имя сформировалось нужное, рекомендую использовать базу, привязанную к ветке версии: dev/101. Откроем и подготовим базу к загрузке в контур разработки, который у нас децентрализован, см. схему в начале раздела, выше. В процессе подготовки происходит следующее: выбранная база копируется в промежуточную базу TempDBForUpload, далее конфигурация полностью снимается с поддержки, выгружается файл ConfigDumpInfo.xml. Далее с этой ИБ создаётся архив MSSQL с суффиксом пользователя в имени в каталоге для обмена, который так же прописан в пакетном задании. К файлу ConfigDumpInfo.xml так же дописывается суффиксом имя базы.
      

   2. Далее пользователю необходимо загрузить два файла см. GIF выше к себе на ПК для присоединения к проекту. Т.е. в обычной ситуации, когда проект уже находится в удалённом хранилище разработчик скачивает файлы из тестового контура, восстанавливает из архива себе базу, при необходимости создаёт её себе в кластере, и заменяет файл ConfigDumpInfo.xml (далее CDI) в рабочем каталоге проекта EDT. Как это сделать останавливаться подробно не стану, это описано подробно в другой моей статье "О синхронизации ИБ с проектом в EDT". Манипуляции с файлом CDI необходимы, чтобы сэкономить время на первичной сборке, это ни много не мало, для конфигурации УХ это около 35 минут на топовом оборудовании. Если ваша конфигурация не большая, или вы ведёте разработку в расширении советами с подменой CDI можно пренебречь. 
      В нашем, демонстрационном случае, хранилища ещё нет, и тестовый контур совмещён с контуром разработки, поэтому восстанавливать файлы из архива не будем, после отработки пакетного файла у нас в информационных базах MS-SQL осталась база UploadTempDB, просто переименуем её в DAM.dev.101.IvanovII (у вас может имя получиться DAM.dev.101.Administrator, если зайдёте в тестовую ИБ под пользователем Администратор). Добавляем базу с тем же именем в кластер, не создавая новой базы на СУБД, а используем уже существующую базу, и импортируем эту базу в проект EDT:
      
      Далее делаем проект общим:
      
      Я предлагаю создать папку git проекта DemoCMPrj внутри воркспейса EDT, у меня это будет W:\ws_DemoCM\DemoCMPrj, и проект EDT будет в подкаталоге DemoAM проекта git, именно на эту структура проекта git настроена сборочная линия. В будущем, вы конечно можете выбрать другие расположения, как Вы привыкли или как Вам удобнее. Не забываем о том, что итоговая длина пути до каталога src должна быть как можно меньше, согласно рекомендаций разработчиков EDT, в особенности если Ваша конфигурация имеет много вложенных подсистем, имеющих длинные наименования.
      
      Далее в панели "Индексирование GitR03;R03;R03;R03;", если она не открыта то открыть её через меню "Окно/Показать панель", переносим все файлы из неиндексированных изменений в индексированные, и фиксируем изменения, в реальных проектах настоятельно рекомендую в комментарии к помещению указать версию типовой конфигурации. Например: "ERP  2.5.48.3 Типовая". Когда будете смотреть Git-blame будет сразу ясно по комментарию откуда этот код.
      
      Далее первое  помещение нужно отправить в удалённое хранилище Git, сделаем это в панели 
      "Репозитории GIT":
      
      
      Вводимые каталоги потом будет поменять очень трудно, поэтому смотрим внимательно.
      

   3. Итогом отправки в Git имеем диалог:
      

5. Теперь откроем наш проект в сервисе gitlab (здесь и в шагах далее контур тестирования): у меня это будет ссылка http://gitlab.чекушкины.рф/check/DemoAMPrg/, затем перейдём на Settings/General. Нам нужен Project ID:
   
   Вставляем этот идентификатор куда? Там, где заполняли токен доступа к проекту:
   

6. Следующим шагом будет встраивание в проект и проверка работоспособности сборочной линии. 

   1. Нам нужно в корне проекта создать файл .gitlab-ci.yml, сделаем это сразу непосредственно в сервисе gitlab, однако защита по умолчанию ветки master нам не позволит этого сделать (её конечно же можно снять в Settings/Repository/Protected branches), но мы сделаем по другому: 

   2. Завершим настройки "Демо проекта" в СППР, откроем ветку версии (dev/101) и создадим ветку версии из СППР, тем самым убедимся, что всё получилось хорошо, и запросы от СППР доходят корректно до gitlab. Открываем демо проект, закладка "Разработка"
      

   3. Откроем ветку dev/101
      

   4. Проверим в веб сервисе хранилища: 
      
      Видим, что ветка создалась, но она не защищена. Настроим рекомендуемые параметры веток в удалённом хранилище, открываем в веб сервисе gitlab раздел Settings/Repository/Protected branches. Заменим (усилим) настройки для master (я обманул, можно было настройки конвейера запушить сразу) чтобы никто не смог ничего в ветку master запушить, и таким образом останется только один допустимый способ изменений в ветке master: запрос на слияние и его удовлетворение. Так же добавим более мягкие настройки для ветки dev/101
      

   5. Далее, откроем ветку dev/101: и добавим новый файл в корень проекта:
      
      Сборочная линия готова, автоматически она не стартовала только лишь потому, что для ветки dev/101 настроена на запуск только по двум событиям: web и sheduller. Кроме того, первое задание бы застряло, так как отсутствуют бегуны, которые могли бы эти задания выполнить. Кроме этого, так как в ветке master пока ещё сборочная отсутствует, gitlab будет предлагать различные варианты готовых шаблонов в разделе CI/CD - Pipelines. Чтобы он увидел что сборочная линия уже есть, нужно слить ветку deve/101 в ветку master. Для этого необходимо создать запрос на слияние ветки dev/101 в ветку master. Сделаем это в разделе "Merge requests"
      
      Gitlab помнит, что мы сделали фиксацию в ветке dev/101 и предлагает создать запрос на слияние в ветку master.  Если кнопки нет, то возможно с момента фиксации сборочной линии прошло более одного часа, чуть ниже и правее есть обычная кнопка создания запроса на слияние, отличие в том, что нужно будет выбрать ветку источник и ветку приёмник вручную. Далее, последовательно, записываем и принимаем запрос на слияние:
      
      

   6. Для настройки бегунов гитлаба скачиваем его по ссылке 64 бита или 32 бита. Можете, прочитать инструкцию по установке полностью.  Я рекомендую, в целях демонстрации поступить проще, запустить только одного бегуна и не устанавливать его в качестве службы.

      1. Скачиваем нужную по разрядности версию в новую папку, я создал для примера папку "D:\CI-DemoAM и загрузил 64 битную версию (файл: gitlab-runner-windows-amd64.exe) в него. Рекомендую переименовать его покороче, например grw.exe, чтобы меньше набирать в консоли.

      2. Открываем CMD, переходим в созданный каталог и запускаем бегуна с параметром регистрации:

grw.exe register

Runtime platform arch=amd64 os=windows pid=28352 revision=f761588f version=14.10.1

Enter the GitLab instance URL (for example, https://gitlab.com/):

_

3. Теперь открываем наш проект в gitlab и перейдём в раздел Settings-CI/CD-Runners
   

D:\CI-DemoAM>grw register<Enter>

Runtime platform arch=amd64 os=windows pid=28352 revision=f761588f version=14.10.1

Enter the GitLab instance URL (for example, https://gitlab.com/):

https://gitlab.com/<Enter>

Enter the registration token:

GR********-*****************z<Enter>

Enter a description for the runner:

[CHECK]: DemoAM-runner<Enter>

Enter tags for the runner (comma-separated):

build, convertation, update, gui-command, codequality<Enter>

Enter optional maintenance note for the runner:

<Enter>

Registering runner... succeeded runner=GR13489413-fr7cX6

Enter an executor: ssh, custom, docker-windows, docker-ssh, parallels, shell, virtualbox, docker+machine, docker-ssh+machine, docker, kubernetes:

shell

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

rem Правим файл config.toml и потом запускаем:

D:\CI-DemoAM>grw run<Enter>

Runtime platform arch=amd64 os=windows pid=37232 revision=f761588f version=14.10.1

Starting multi-runner from D:\CI-DemoAM\config.toml... builds=0

Configuration loaded builds=0

listen_address not defined, metrics & debug endpoints disabled builds=0

[session_server].listen_address not defined, session endpoints disabled builds=0

В процессе регистрации бегун в этом же каталоге создаст конфигурационный файл, в нём нужно исправить параметры, которые выделены
 
После запуска бегуна gitlab его должен увидеть (обновите страницу):

4. Далее, необходимо установить несколько переменных окружения в разделе Settings-CI/CD-Variables, они есть в тексте сборочной линии в этапе StagesAndVariables:

# Переменные ниже должны быть определены на сервере сборки

#W_PLATFORM_1C: 'C:\Program Files\1cv8\8.3.17.1549\bin\1cv8.exe' # Путь к запускаемому толстому клиенту Windows

#W_PLATFORM_1C_tc: 'C:\Program Files\1cv8\8.3.17.1549\bin\1cv8c.exe' # Путь к запускаемому тонкому клиенту Windows

# Переменные ниже могут быть определены на сервере сборки

#CI_DEBUG_TRACE: "true"

Я определю только те, которые нужны сейчас - пути к платформе, вы можете ещё и отладку включить:

5. Осталось последнее, настроить веб хуки gitlab, для этого перейдём в раздел Settings-Webhooks, и вставим ссылку на второй HTTP сервис СППР http://xn--e1agfaq7azal4a.xn--p1ai/DemoAM/hs/BS/file.json , где подчёркнутую ссылку Вам нужно заменить на свой веб сервер: 
   

6. Добавьте пользователя, под которым заходите в СППР в раздел уведомлений для ветки master (иначе не подучите уведомлений от бота о сборке):
   

7. Далее, переходим в gitlab, раздел CI/CD-Pipelines и запускаем сборочную линию, на видео процесс будет немного быстрее. чем у вас первый раз, так как первый раз заполняется кэш хранилища бегуна, кэш метаданных для утилиты ring в каталоге сборки. На видео собирается параллельно 3 ветки, но вам рекомендую начат сборку с какой ни будь одной.
   

7. Сейчас у ИБ для ветки версии и ветки тестирования не включён флаг копирования ИБ перед сборкой из родителя, в этом случае, прежде чем ваша база будет обновлена, допустим это ветка тестирования, из ветки версии будет скопирована ИБ с самыми свежими "тестовыми примерами" (ошибками), а затем этот клон будет обновлён до конфигурации ветки тестирования, тогда в сборочную линию добавится ещё один этап, копирование:
   

8. Разница в длительности сборки не большая - 30 секунд, на больших ИБ может достигать десятки минут, 50 Гб - ~6 минут. Такой подход позволяет, быстро получить с продуктивного контура копию ИБ, накатив на неё ветку версии с выполненными задачами и проверить работоспособность функционала на свежих данных. Ещё одна выгода - в продуктивном контуре отладка как правило отключена, а ветка версии всегда в тестовом контуре, где отладка включена. Идеальный вариант делать такие сборки до начала рабочего дня (по расписанию). То же самое с веткой тестирования, её как правило собирают два раза в сутки, один раз в ночь, второй раз в обед (так же по расписанию). Ну и всегда можно запустить сборку по требованию - из веб интерфейса.
   

7. На этом настройка демонстрационного контура базы закончена.

Разворачивание демонстрационных баз и подключение к GitLab CI/CD.

Демонстрационная база содержит примеры как для Windows, так и для Linux и примеры в ней ориентированы на работу с СУБД MS-SQL и PostGRE SQL, чтобы соблюсти требования к кроссплатформенности. Возможно, кому-то и примеры покажутся не современными, так как в качестве командного процессора используется CMD, который начиная с 13 релиза бегунов Gitlab вроде, как и не поддерживается уже, но почему-то работает.

Вариант для Linux
Примечание: некоторые изображения в тексте оставлены от варианта разворачивания на ОС Windows, так как они полностью аналогичны.

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

1. ПК с ОС Linux из поддерживаемых. Я использую Ubuntu 18.04-4. ОС должна иметь GUI. На ПК должно быть установлено:

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

      1. Установка обязательно с поддержкой публикаций на веб сервере. (компонента wsapi)

      2. Блокировка ИБ для обновления запуском с ключом /C ЗавершитьРаботуПользователей требует запущенного сервиса RAS. В противном случае, при запуске сборочных линий задание блокировки будет зависать на первом же этапе. По умолчанию блокировка пытается установиться в варианте COM, который в Linux не поддерживается, чтобы в дальнейшем срабатывал вариант через RAS сервер, нужно будет эталонную базу заблокировать и разблокировать интерактивно из раздела Администрирование/Блокировка пользователей, указав этот вариант и параметры подключения к серверу RAS.

   2. СУБД Postrgres, пропатченный с сайта 1С версии 11.16-1.1C. Как альтернативный вариант Postgres Pro 1C 11 и выше. Я использую PostgresPro. Для сервера нужно будет снять ограничения на прием запросов только с адреса localhost.

   3. Веб сервер (для публикации HTTP сервисов СППР) Apache, тонкости публикаций будут описаны ниже. У сервера Gitlab должен быть к веб серверу СППР доступ.

   4. Тестовая ИБ на базе БСП. (входит в комплект поставки)

   5. Дистрибутив СППР релиза 2.0.4.15.

   6. EDT. В него потребуется импортировать тестовую базу на базе БСП, создать из неё проект и разместить его на сервере gitlab, требования к нему читаем ниже.

   7. Рекомендую поставить, если ещё не стоит на ПК Notepad++

   8. В целях демонстрации, для простоты освоения, рекомендую все сервисы развернуть именно на одном ПК, если всё же вам немного хочется экстрима, и у вас все сервисы разнесены по разным, не забываем, что серверу 1С, на котором стоит и работает ИБ СППР нужен доступ к СУБД (5432 порт по умолчанию для Postgres) и серверу тестового контура, где будет развёрнута тестовая ИБ на базе БСП (порты кластера должны быть доступны, по умолчанию это 1540,1541).

2. Вам потребуется учётная запись в сервисе gitlab.

   1. Это может быть учётная запись в https://gitlab.com/ 

   2. Или ваш локально (например, в интрасети компании) развёрнутый Gitlab CE или EE, важно чтобы он был версии не ниже 11.2. 

      1. Чтобы корректно отрабатывали описанные примеры в тексте по тестам в формате jUnit, в GitLab должны быть произведены некоторые настройки. Т.е. Вам, возможно, потребуется доступ c привилегиями администратора к серверу Gitlab, чтобы включить всё это. Чтобы проверить откройте веб интерфейс Вашего сервера gitlab и добавьте в конец (выделено жирным) http://gitlab.myserver.int/help/ci/junit_test_reports.md, если не получите ошибку 404, а вместо неё получите инструкцию, значит скорее всего Вам придётся включить эту возможность, как там и описано, если нет и версия точно выше 11.2 то скорее всего всё уже включено. Вообще говоря, по-простому включение элементарно, в линуксовом terminal'е сервера с gitlab нужно набрать: 
         sudo gitlab-rails runner “Feature.enable(:junit_pipeline_view)”

      2. Или, если вас тестирование и хранение результатов в формате junit не интересует, вам просто нужна возможность опубликовать ваш проект в любом сервисе gitlab.

3. Сервисы бегунов гитлаба (gitlab-runner). В демонстрационных целях мы обойдёмся одним, запуская его из командной строки. Но я рекомендую настроить 2, один установить, как службу (с повышенными привилегиями SYSTEM) и один запускать из командной строки в окне терминальной сессии и не завершать её, просто отключать. У них будет разный набор тэгов. 

4. Терпение, терпение и ещё раз терпение :)

Более подробно, по шагам. 

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

От этой схемы в реальной жизни были сделаны некоторые отступления, потому что эта схема была разработана для документа "Технология разветвлённой разработки, использующая git, ci/cd". Одно из отступлений отсутствие ветки release (в СППР > 2.0.2.12 для неё места не оказалось), а с учётом технологии работы ветки версии, надобность в ней просто отпала. Другое отличие, что при организации доступа сервера СППР к тестовому контуру, СППР может находиться за пределами тестового контура, и, таким образом, быть разделена между проектами. Мы так и работаем.

1. Подготовка СППР и эталонной базы в контуре тестирования

   1. По правилам лицензионного соглашения, я не имею права выкладывать выгрузку (DT) демонстрационной базы, поэтому разворачиваем из дистрибутива конфигурации пустую базу СППР версии 2.0.4.15 на сервере 1С рекомендуемой версией платформы 8.3.17.1549

   2. Скачиваем одним архивом GLI_1.0.2.6.zip: расширение GLI.CFE, выгрузку тестовой ИБ на базе БСП DemoAM.DT, обработку выгрузки и загрузки через XML, как оказалось они тоже между версиями несовместимы и данные для загрузки SPPRData.xml.

   3. В развёрнутой ИБ придётся включить возможность изменения конфигурации всю или частично - на ваше усмотрение. Нужно включить иерархию элементов у справочника "Ветки" без ограничений. В расширении с учётом совместимости этого сделать невозможно. С рекомендуемой версией платформы конфигурация не запустится, поэтому сразу загружаем расширение GLI.CFE
      После применения расширения и реорганизации запускаем на выполнение. По окончании первоначального заполнения увидите историю версий расширения и основной конфигурации.

   4. Добавьте пользователя с административными привилегиями, исключая имена Администратор и Иванов Иван Иванович (эти двое приедут с выгрузкой). Так же, создайте группу доступа "Открытие внешних отчетов и обработок" с одноименным профилем к внешним отчётам и обработкам, и добавьте этого пользователя туда. Поставьте стойкий пароль пользователю, если ИБ будет опубликована в интернете. Если вы будете полностью демонстрацию разворачивать у себя в интрасети (т.е. и gitlab тоже будет развернут внутри организации) и вы доверяете коллегам - можете не ставить пароли. После перезапуска под новым пользователем система предложит вам включить обсуждения.
      
      Согласитесь. Перезапустите ИБ СППР с новым пользователем.

   5. Групповой обработкой e1cib/app/Обработка.ГрупповоеИзменениеРеквизитов, произвольным алгоритмом в режиме «Обмен.ЗагрузкаДанных=Истина» установите пометку удаления и, затем, удалите окончательно элементы справочников «Пакетные задания» и «Типы СУБД». Необходимые элементы будут загружены следующим пунктом.

   6. Откройте приложенную обработку выгрузки/загрузки и загрузите демонстрационные данные SPPRData.xml:
      
      Загруженным пользователям Администратор и Иванов Иван Иванович дайте при необходимости стойкие пароли и добавьте их в группы Администратор и группу пользователей внешних обработок.
      Перезайдите в СППР от Иванова, или добавьте своего пользователя в группы уведомления в ветках.

   7. Создаём в кластере 1С пустую ИБ, назовите DemoAM (assemble management - управление сборкой), так будет проще копировать настройки и примеры.  Загрузите в неё скачанную выгрузку тестовой ИБ на базе БСП.

   8. В части алгоритмов используется запуск клиентских приложений 1С:Предприятия из пакетных файлов, в частности создание ИБ в кластере 1С:Предприятия, которые не могут нормально запуститься под пользователем usr1cv8, создаваемого автоматически сценарием установки, в контексте которого выполняются процессы кластера 1С:Предприятия. Для решения этой проблемы придется отключить автоматический запуск кластера:
      sudo systemctl stop srv1cv83
      sudo systemctl disable
      И далее запускать его одним из двух вариантов

      1. Запуском пакетного файла:
         sudo cp ~/.Xauthority /home/usr1cv8
         sudo cp ~/.xinputrc /home/usr1cv8
         sudo chown usr1cv8:grp1cv8 /home/usr1cv8/.Xauthority
         sudo chown usr1cv8:grp1cv8 /home/usr1cv8/.xinputrc
         sudo /etc/init.d/srv1cv83 start

      2. Либо просто запустить кластер в контексте пользователя с GUI:
         /opt/1C/v8.3/x86_64/ragent /port 1540 /regport 1541 /range 1560:1591 /d ~/dbinfo/.1cv8 [-debug -http -debugserverport 1550]

Есть ещё один вариант выхода: заменить вызовы создания, загрузки / выгрузки ИБ на новую утилиту ibcmd.exe из состава утилит автономного сервера, однако в практике всё равно потребуется использовать 1С:Конфигуратор для создания файлов поставки. Кроме этого, утилита ibcmd.exe работает эффективно и корректно начиная с версии платформы 8.3.20

9. Запускаем базу СППР должно появиться меню подсистемы управления сборкой:
   

10. Создаём элементы справочников СУБД, Кластер 1С, у меня это элементы с именем ПК: Ubuntu-VM2, где развёрнуты кластер 1С, СУБД Postgrespro, Вам нужно будет подставить свои. У меня кластер указанной версии развернут на портах выше 1740, если у Вас по умолчанию на портах выше 1540, то порт в имени кластера можно не указывать.
    

11. Далее, создаём информационную базу в одноименном справочнике, заполняя поля в последовательности как на рисунке:
    
    Конечно же порядок заполнения полей 1-7 может быть любой, главное чтобы они были корректно заполнены до нажатия на кнопку "Заполнить дополнительные переменные". Если вместо сообщений внизу как на снимке выше вы получаете другие сообщения:
    
    
    Если же всё проверили и всё равно что то не получается, то необходимо добиться, чтобы с сервера 1С, где развёрнута ИБ СППР был доступ к выбранному Вами SQL серверу из командной
    строки посредством psql, да поможет Вам Google или Яndex:
    evgeniy@Ubuntu-VM2:~$ /opt/pgpro/1c-11/bin/psql -U postgres -h "Ubuntu-VM2" -A -t -c "select d.datname, t.spcname from pg_catalog.pg_database d left join pg_catalog.pg_tablespace t on d.dattablespace = t.oid where d.datname = 'DemoAM'"
    DemoAM|pg_default
    evgeniy@Ubuntu-VM2:~$

12. Если всё получилось корректно, то в списке ИБ напротив вашей добавленной ИБ будет зелёный кружок с галкой:
    
    !ВАЖНО! Тестовая ИБ уже готова к размещению в тестовом контуре: конфигурация стоит на полной поддержке без возможности изменения. Имитируется ситуация, когда вы создали ИБ из шаблона поставщика. Нельзя размещать базы с включённой возможностью изменения. Если по каким-то причинам, прежде чем начать работать с базой вам потребовалось в конфигурации включить возможность изменения, то нужно снова выключить возможность изменения и вернуть ИБ к состоянию как от поставщика, чтобы не потерять данные можно просто сохранить конфигурацию поставщика в файл, за затем загрузить эту конфигурацию игнорируя предупреждения, все сделанные изменения, естественно будут потеряны. Если в структуре базы были внесены изменения и вам их нужно сохранить, например, вы, прежде чем выложить в тестовый контур исправили критичную ошибку поставщика, а обновления от него нет. В таком случае, создайте с этой базы файл поставки CF, и его загрузите в конфигурацию. Получите конфигурацию на полной поддержке, без возможности изменения, но уже с вашими изменениями. На качество последующих обновлений от поставщика это сильно не повлияет, с учётом того каким образом предлагается её обновлять, однако будет считаться, что поставщик ваши изменения "удалил", поэтому лучше всё же сначала поместить типовую, свои изменения сохранить в отдельный CF, и они отдельной фиксацией пройдут в изменениях от типового. Во всех клонах базы будут иметь разную конфигурацию, относительно изначальной, в соответствии с веткой, к которой они привязаны, но все они должны быть на полной поддержке без возможности изменения. Ещё см. ниже раздел "Как обновлять базы при работе в EDT".

13. В демонстрационной базе предварительно созданы три ветки:
    
    Основную эталонную базу мы уже добавили и привязали к ветке master, создадим ещё последовательно и привяжем сначала базу версии, затем базу тестирования:
    
    Для просмотра анимации перейдите по ссылке на изображении

Конечно же в реальных проектах, где ИБ может иметь размеры более 50 Гб, копирование может отнять больше времени. Всё будет зависеть от Вашего оборудования. Поскольку хранилище проекта в gitlab ещё не создано, то полная идентичность всех трёх ИБ вполне нормальное явление, так как, по сути, 3 несуществующих указателя веток указывают сейчас в одно место - "в никуда".

14. Далее, нужно проверить корректность формирования сборочной линии, прежде чем это сделать, добавим алгоритм  определения переменной в одноименном справочнике - LockVersion и алгоритм "STD". В логике сборочной линии анализируется значение этой переменной на значение SSL, и в этом случае параметры передаются немного иные, тестовая база создана на БСП версии ранее чем 3.1.5 и код завершение работы пользователей пропатчен до функционала БСП, который есть начиная в версии 3.1.5. Если Вы вдруг захотите попробовать в качестве тестовой ИБ какую-то свою базу, проверьте версию БСП, если она 3.1.5 или выше - тогда алгоритм нужно написать "SSL". После создания дополнительной переменно открываем справочник "Сборочные линии", там уже должен быть один элемент DemoAM, встаём на него и жмём кнопку "Получить текст сборочной линии". Сохраним полученный текст в файл с расширением yaml и откроем редактором vim, он подсвечивает синтаксис yaml. Должно быть примерно следующее:
    
    Если вывод похож как на картинке, за исключением ваших имён серверов СУБД и кластера 1С то переходим к следующему этапу.

2. Настройка системы взаимодействия и интеграции СППР с gitlab в тестовом контуре

   1. Первым делом подключаем систему взаимодействия, если вы это не сделали сразу на шаге 1.4, инструкция как это сделать есть на ИТС: Глава 6. Администрирование информационной базы :: Руководство администратора :: 1С:Предприятие 8.3.19. Документация (1c.ru). Без этого шага вы в следующий не попадёте.

   2. Следующий шаг настройка бота, получение токенов из gitlab и подключение СППР к ней.

      1. Открываем меню Управление сборкой/Сервис/Настройка уведомлений о сборках и подключение к Gitlab API
         Заполняем поля, к полям простые подсказки, я поставил другой аватар для бота, чтобы отличать его от собственных тестовых баз, и жмём "Создать бота"
         
         Обработка сама создаст пользователя СППР, отключит у него аутентификацию 1С и включит аутентификацию ОС для указанного пользователя. В результате должна форма немного изменится, вместо кнопки "Создать бота" появится кнопка "Обновить бота". В списке пользователей должен появиться новый пользователь:
         
         Обработка так же создаст в системе взаимодействия одноименного пользователя и свяжет его с пользователем системы. Нам необходимо доработать пользователя согласно рисунку выше, изменить способ аутентификации и создать ему хороший пароль, запомнить его, он нам пригодится при публикации на веб сервере.

      2. В проектной деятельности, Вам лучше всего будет создать служебную учётную запись СППР в сервисе gitlab, добавить его в проект (потом вы можете этого же пользователя использовать и в других проектах). Но в демонстрационных целях мы засорять сервисы gitlab служебными пользователями не будем, я привяжу свой токен. Открываем наш сервис gitlab, у меня это будет ссылка http://gitlab.чекушкины.рф/-/profile/personal_access_tokens
         
         Теперь пропишем скопированный токен в СППР, чуть позже придётся вернуться к этой настройке, чтобы прописать идентификатор созданного проекта:
         

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

3. Публикация HTTP сервисов СППР на веб сервере. (контур тестирования)

   1. На этом этапе я предполагаю, что вы уже заранее установили на свой ПК веб сервер, настроили его и к нему есть доступ для сервисов веб хуков gitlab. Я в своих примерах буду использовать собственный сервер https://gitlab.чекушкины.рф, для того чтобы у него был доступ к моему СППР, мой локальный сервер Apache редиректится в домен http://linux.чекушкины.рф, однако не все программы понимают кириллицу, и поэтому в ссылках кое где указанные адреса будут выглядеть как http://gitlab.xn--e1agfaq7azal4a.xn--p1ai и http://linux.xn--e1agfaq7azal4a.xn--p1ai, это не ошибка, а нормальная «двуличность» кириллических доменов.
      Есть отличительная особенность, при публикации штатными средствами HTTP и веб сервисов, сделанных в расширении: при публикации ИБ на веб сервере, вы не увидите ни одного HTTP сервиса из расширения, вместо них один единый флаг «Публиковать http сервисы расширений» это особенность поведения конфигуратора. Поэтому, запускаем конфигуратор с повышенными привилегиями (sudo /opt/1C/v8.3/x86_64/1cv8), и публикуем все http сервисы конфигурации:
      
      Если вы всё же захотите в итоге опубликовать вашу СППР в интернете, то для основной публикации базы и для http сервисов сделайте разные публикации, это связано с разными способами аутентификации. Для основной базы будет использоваться стандартная аутентификация. А для http сервисов СППР имя пользователя и пароль нужно задать прямо в публикации.
      Соглашаемся на перезапуск. Откроем конфигурационный файл vim /var/www/DemoAM/default.vrd и добавим логин и пароль для пользователя веб сервиса.
      
      Записываем файл и перезапускаем sudo systemctl restart apache2, либо sudo /etc/init.d/apache2 restart

   2. Для проверки работоспособности веб сервиса получим сборочную линию,  у меня это будет ссылка: http://linux.чекушкины.рф/DemoAM/hs/GetPipeline/DemoAM/ci-module.yml (xn--e1agfaq7azal4a.xn--p1ai) , где DemoAM - имя публикации на веб сервере, hs/GetPipeline - имя HTTP сервиса, второй раз DemoAM - имя сборочной линии, и ci-module.yml - остаток от шаблона HTTP сервиса. В качестве ответа должны получить вывод, аналогичный при нажати и на кнопку "Получить текст сборочной линии":
      

4. Создаём хранилище проекта из контура разработки.

   1. Встаём на любой из трёх ИБ в тестовом контуре (напоминаю, они пока ещё полностью идентичны), но, чтобы имя сформировалось нужное, рекомендую использовать базу, привязанную к ветке версии: dev/101. Откроем и подготовим базу к загрузке в контур разработки, который у нас децентрализован, см. схему в начале раздела, выше. В процессе подготовки происходит следующее: выбранная база копируется в промежуточную базу TempDBForUpload, далее конфигурация полностью снимается с поддержки, выгружается файл ConfigDumpInfo.xml. Далее с этой ИБ создаётся архив MSSQL с суффиксом пользователя в имени в каталоге для обмена, который так же прописан в пакетном задании. К файлу ConfigDumpInfo.xml так же дописывается суффиксом имя базы.
      
      Для просмотра анимации перейдите по ссылке на изображении

   2. Далее пользователю необходимо загрузить два файла см. GIF выше к себе на ПК для присоединения к проекту. Т.е. в обычной ситуации, когда проект уже находится в удалённом хранилище разработчик скачивает файлы из тестового контура, восстанавливает из архива себе базу, при необходимости создаёт её себе в кластере, и заменяет файл ConfigDumpInfo.xml (далее CDI) в рабочем каталоге проекта EDT. Как это сделать останавливаться подробно не стану, это описано подробно в другой моей статье "О синхронизации ИБ с проектом в EDT". Манипуляции с файлом CDI необходимы, чтобы сэкономить время на первичной сборке, это ни много не мало, для конфигурации УХ это около 35 минут на топовом оборудовании. Если ваша конфигурация не большая, или вы ведёте разработку в расширении советами с подменой CDI можно пренебречь. 
      В нашем, демонстрационном случае, хранилища ещё нет, и тестовый контур совмещён с контуром разработки, поэтому восстанавливать файлы из архива не будем, после отработки пакетного файла у нас в информационных базах Postgres и в кластере осталась база TempDBForUpload, уже готовая к эксплуатации, с неё и создадим проект:
      
      Далее делаем проект общим:
      
      Я предлагаю создать папку git проекта DemoCMPrj внутри воркспейса EDT, у меня это будет W:\ws_DemoCM\DemoCMPrj, и проект EDT будет в подкаталоге DemoAM проекта git, именно на эту структура проекта git настроена сборочная линия. В будущем, вы, конечно, можете выбрать другие расположения, как Вы привыкли или как Вам удобнее. Не забываем о том, что итоговая длина пути до каталога src должна быть как можно меньше, согласно рекомендаций разработчиков EDT, в особенности если Ваша конфигурация имеет много вложенных подсистем, имеющих длинные наименования.
      
      Далее в панели "Индексирование", если она не открыта то открыть её через меню "Окно/Показать панель", переносим все файлы из неиндексированных изменений в индексированные, и фиксируем изменения, в реальных проектах настоятельно рекомендую в комментарии к помещению указать версию типовой конфигурации. Например: "ERP  2.5.48.3 Типовая". Когда будете смотреть Git-blame будет сразу ясно по комментарию откуда этот код.
      
      Далее первое  помещение нужно отправить в удалённое хранилище Git, сделаем это в панели 
      "Репозитории GIT":
      
      
      Вводимые каталоги потом будет поменять очень трудно, поэтому смотрим внимательно.
      

   3. Итогом отправки в Git имеем диалог:
      

5. Теперь откроем наш проект в сервисе gitlab (здесь и в шагах далее контур тестирования): у меня это будет ссылка http://gitlab.чекушкины.рф/check/DemoAMPrg/, затем перейдём на Settings/General. Нам нужен Project ID:
   
   Вставляем этот идентификатор куда? Там, где заполняли токен доступа к проекту:
   
   ВАЖНО! Если вы на шаге 2.2 создали токен доступа для другого пользователя (у меня это пользователь ADS (СППР)), не для себя, самое время добавить этого пользователя в члены проекта. Добавлять его нужно с правами Maintainer:
   

6. Следующим шагом будет встраивание в проект и проверка работоспособности сборочной линии. 

   1. Нам нужно в корне проекта создать файл .gitlab-ci.yml, сделаем это сразу непосредственно в сервисе gitlab, однако защита по умолчанию ветки master нам не позволит этого сделать (её конечно же можно снять в Settings/Repository/Protected branches), но мы сделаем по другому: 

   2. Завершим настройки "Демо проекта" в СППР, откроем ветку версии (dev/101) и создадим ветку версии из СППР, тем самым убедимся, что всё получилось хорошо, и запросы от СППР доходят корректно до gitlab. Открываем демо проект, закладка "Разработка"
      

   3. Откроем ветку dev/101
      

   4. Проверим в веб сервисе хранилища: 
      
      Видим, что ветка создалась, но она не защищена. Настроим рекомендуемые параметры веток в удалённом хранилище, открываем в веб сервисе gitlab раздел Settings/Repository/Protected branches. Заменим (усилим) настройки для master (я обманул, можно было настройки конвейера запушить сразу) чтобы никто не смог ничего в ветку master запушить, и таким образом останется только один допустимый способ изменений в ветке master: запрос на слияние и его удовлетворение. Так же добавим более мягкие настройки для ветки dev/101
      

   5. Далее, откроем ветку dev/101: и добавим новый файл в корень проекта:
      
      Сборочная линия готова, автоматически она не стартовала только лишь потому, что для ветки dev/101 настроена на запуск только по двум событиям: web и sheduller. Кроме того, первое задание бы застряло, так как отсутствуют бегуны, которые могли бы эти задания выполнить. Кроме этого, так как в ветке master пока ещё сборочная отсутствует, gitlab будет предлагать различные варианты готовых шаблонов в разделе CI/CD - Pipelines. Чтобы он увидел что сборочная линия уже есть, нужно слить ветку deve/101 в ветку master. Для этого необходимо создать запрос на слияние ветки dev/101 в ветку master. Сделаем это в разделе "Merge requests"
      
      Gitlab помнит, что мы сделали фиксацию в ветке dev/101 и предлагает создать запрос на слияние в ветку master.  Если кнопки нет, то возможно с момента фиксации сборочной линии прошло более одного часа, чуть ниже и правее есть обычная кнопка создания запроса на слияние, отличие в том, что нужно будет выбрать ветку источник и ветку приёмник вручную. Далее, последовательно, записываем и принимаем запрос на слияние:
      
      

   6. Для настройки бегунов гитлаба устанавливаем его из консоли: sudo apt-get install gitlab-runner. Можете, прочитать инструкцию по установке полностью. Я рекомендую, в целях демонстрации поступить проще, запустить только одного бегуна и не устанавливать его в качестве службы. Точнее служба будет создана и запущена сразу после установки её нужно отключить, по тем же причинам, по которым отключали и 1С:Предприятие – запускаемым файлам 1C требуется GUI.

      1. sudo systemctl disable gitlab-runner

      2. sudo systemctl stop gitlab-runner

      3. gitlab-runner register_

      4. Теперь открываем наш проект в gitlab и перейдём в раздел Settings-CI/CD-Runners
         
         
         evgeniy@Ubuntu-VM2:~$ gitlab-runner register
         Runtime platform arch=amd64 os=linux pid=21329 revision=4c96e5ad version=12.9.0

WARNING: Running in user-mode.

WARNING: The user-mode requires you to manually start builds processing:

WARNING: $ gitlab-runner run

WARNING: Use sudo for system-mode:

WARNING: $ sudo gitlab-runner...

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

http://Ubuntu-GLS/

Please enter the gitlab-ci token for this runner:

GR1348941n6Epz2b-RuXWqtJ2Tp4P

Please enter the gitlab-ci description for this runner:

[Ubuntu-VM2]: DemoAM-runner

Please enter the gitlab-ci tags for this runner (comma separated):

build, convertation, gui-command, update

Registering runner... succeeded runner=GR134894

Please enter the executor: docker-ssh, parallels, shell, ssh, kubernetes, custom, docker, virtualbox, docker+machine, docker-ssh+machine:

shell

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

evgeniy@Ubuntu-VM2:~$

5. В процессе регистрации бегун в каталоге ~/.gitlab-runner/ создаст конфигурационный файл config.toml, в нём нужно исправить параметр:
   concurrent = 6
   это означает количество параллельно исполняемых заданий. Запускаем:
   evgeniy@Ubuntu-VM2:~$ gitlab-runner run

Runtime platform arch=amd64 os=linux pid=22539 revision=4c96e5ad version=12.9.0

Starting multi-runner from /home/evgeniy/.gitlab-runner/config.toml... builds=0

WARNING: Running in user-mode.

WARNING: Use sudo for system-mode:

WARNING: $ sudo gitlab-runner...

Configuration loaded builds=0

listen_address not defined, metrics & debug endpoints disabled builds=0

[session_server].listen_address not defined, session endpoints disabled builds=0

6. После запуска бегуна в gitlab его должен увидеть (обновите страницу, раскройте секцию Runner’ы):
   

7. Далее, необходимо установить несколько переменных окружения в разделе Settings-CI/CD-Variables, они есть в тексте сборочной линии в этапе StagesAndVariables:
   # Переменные ниже должны быть определены на сервере сборки
   #L_PLATFORM_1C: '/opt/1C/v8.3.17-1549/x86_64/1cv8' # Путь к запускаемому толстому клиенту Linux
   #L_PLATFORM_1C_tc: '/opt/1C/v8.3.17-1549/x86_64/1cv8c' # Путь к запускаемому тонкому клиенту Linux
   # Переменные ниже могут быть определены на сервере сборки
   #CI_DEBUG_TRACE: 'true'

Я определю только те, которые нужны сейчас - пути к платформе, вы можете ещё и отладку включить:

8. Осталось последнее, настроить веб хуки gitlab, для этого перейдём в раздел Settings-Webhooks, и вставим ссылку на второй HTTP сервис СППР http://linux.xn--e1agfaq7azal4a.xn--p1ai/DemoAM/hs/BS/file.json , где подчёркнутую часть ссылки Вам нужно заменить на свой веб сервер: 
   

9. Добавьте пользователя, под которым заходите в СППР в раздел уведомлений для ветки master (иначе не получите уведомлений от бота о сборке):
   

10. Далее, переходим в gitlab, раздел CI/CD-Pipelines и запускаем сборочную линию, на видео процесс будет немного быстрее. чем у вас первый раз, так как первый раз заполняется кэш хранилища бегуна, кэш метаданных для утилиты ring в каталоге сборки. На видео собирается параллельно 3 ветки, но вам рекомендую начать сборку с какой-то одной.
    
    Для просмотра анимации перейдите по ссылке на изображении

7. Сейчас у ИБ для ветки версии и ветки тестирования не включён флаг копирования ИБ перед сборкой из родителя, в этом случае, прежде чем ваша база будет обновлена, допустим это ветка тестирования, из ветки версии будет скопирована ИБ с самыми свежими "тестовыми примерами" (ошибками), а затем этот клон будет обновлён до конфигурации ветки тестирования, тогда в сборочную линию добавится ещё один этап, копирование:
   

8. Разница в длительности сборки не большая - 30 секунд, на больших ИБ может достигать десятки минут, 50 Гб - ~6 минут. Такой подход позволяет, быстро получить с продуктивного контура копию ИБ, накатив на неё ветку версии с выполненными задачами и проверить работоспособность функционала на свежих данных. Ещё одна выгода - в продуктивном контуре отладка как правило отключена, а ветка версии всегда в тестовом контуре, где отладка включена. Идеальный вариант делать такие сборки до начала рабочего дня (по расписанию). То же самое с веткой тестирования, её как правило собирают два раза в сутки, один раз в ночь, второй раз в обед (так же по расписанию). Ну и всегда можно запустить сборку по требованию - из веб интерфейса.
   

7. На этом настройка демонстрационного контура базы закончена. ККК2

к2