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

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

Подсистема предназначена для упрощения рутинных операций в части выпуска новых релизов системы и поддержки сборочных линий Gitlab CI/CD в актуальном состоянии. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Использует систему взаимодействия для оповещения пользователей о результатах сборок, создании веток исправления ошибок и технических проектов в Git, уведомления о проблемах принятия запросов на слияние. Без системы взаимодействия функциональность будет сильно ограничена. Однако существует возможность использования системы в режиме, который используется по умолчанию в системе как резервный — посредством отправки уведомлений на электронную почту пользователей. Подсистема автоматически переключается в резервный режим при отсутствии возможности отослать уведомление через систему взаимодействия (включая и вариант, когда система взаимодействия отключена) и восстанавливает рассылку через СВ, при восстановлении соединения с сервером взаимодействия.

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

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

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

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

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

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

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

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

    • Ошибки

• Вести справочник "Сборочных линий", представляющих собой динамически формируемый шаблон сборочной линии проекта, подключаемый в конвейере 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 нового релиза из конвейера вставить во вложения нового релиза

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

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

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

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

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

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

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

HKEY_CLASSES_ROOT\e1c]
@="URL:e1c Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\e1c\DefaultIcon]
@="\"C:\\Program Files (x86)\\1cv82\\common\\1cestart.exe\""

[HKEY_CLASSES_ROOT\e1c\shell]

[HKEY_CLASSES_ROOT\e1c\shell\open]

[HKEY_CLASSES_ROOT\e1c\shell\open\command]
@="\"C:\\Program Files (x86)\\1cv82\\common\\1cestart.exe\" /url \"%1\""

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

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

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

Имя сервера СУБД: наименование, по которому идентифицируется именно этот сервер СУБД в скриптах, например в 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.