–уководство пользовател€
–асширение 1—:—ѕѕ–: «”правление сборкой
GLI».1

ќглавление

–уководство пользовател€ –асширение 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 в актуальном состо€нии. ѕодсистема рассчитана исключительно на клиент - серверную архитектуру тестовых »Ѕ. »спользует систему взаимодействи€ дл€ оповещени€ пользователей о результатах сборок, создании веток исправлени€ ошибок и технических проектов в Git, уведомлени€ о проблемах прин€ти€ запросов на сли€ние. Ѕез системы взаимодействи€ функциональность будет сильно ограничена. ќднако существует возможность использовани€ системы в режиме, который используетс€ по умолчанию в системе как резервный — посредством отправки уведомлений на электронную почту пользователей. ѕодсистема автоматически переключаетс€ в резервный режим при отсутствии возможности отослать уведомление через систему взаимодействи€ (включа€ и вариант, когда система взаимодействи€ отключена) и восстанавливает рассылку через —¬, при восстановлении соединени€ с сервером взаимодействи€.


ѕодсистема позвол€ет:



ќграничени€:



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

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

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





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

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

ѕроцессы работы ошибками и техническими проектами описаны в руководстве пользовател€ —ѕѕ–

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

–§–Є–≥—Г—А–∞3

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

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

*** ѕри недоступности системы взаимодействи€, включа€ еЄ полное отключение используетс€ автоматически резервный режим рассылки уведомлений на электронную почту, указанную в настройках пользователей —ѕѕ–. —ообщени€ на электронную почту полностью функциональны, и позвол€ют так же открывать по ссылкам объекты —ѕѕ–, использу€ в качестве ссылок внешние навигационные ссылки на объекты —ѕѕ–. ƒл€ открыти€ таких ссылок из писем из почтовых программ в 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 - переменные. описанные в справочнике "јлгориты определени€ переменных":

ServerName

ѕараметры.»Ѕ.—”Ѕƒ.Ќаименование

UserName

ѕараметры.»Ѕ.—”Ѕƒ.»м€ѕользовател€

Password

ѕараметры.»Ѕ.—”Ѕƒ.ѕароль


–езультат такого запроса €вл€етс€ простой список »Ѕ на сервере —”Ѕƒ. ѕолученные имена »Ѕ сопоставл€ютс€ с реквизитом "ѕолное им€" элементов справочника »Ѕ.

ѕри выводе дерева информационные базы, которые физически присутствуют на сервере —”Ѕƒ маркируютс€ полем "ƒоступность", дл€ недоступных (тех базах, которые присутствуют в справочнике, но отсутствуют в —”Ѕƒ) ƒоступность будет равно Ћожь.

—остав реквизитов корневого элемента и подчинЄнных элементов немного отличаетс€, но в целом одинаков:

Ќаименование реквизита

Ќазначение дл€ корневого элемента

Ќазначение дл€ подчиненного элемента

ѕримечание

ќсновное

Ќаследуема€ »Ѕ

-

»Ѕ, с которой была получена копи€

¬ некоторых случа€х можно "—копировать [базу] из родител€", затем переподчинить еЄ другой. ¬ручную реквизит не редактируетс€, используетс€ штатный перенос drag & drop.

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

ќсновной объект сборки

—сылка на элемент справочника ¬етки с типом "ќсновна€ ветка проекта" или "¬етка версии" 

ƒл€ первого уровн€: ссылка на ветку версии
ƒл€ второго уровн€: ссылка на технический проект, ошибку, или общую ветку тестировани€.

ќбща€ ветка тестировани€ - специальный механизм, вместе с прив€занной к ней »Ѕ дл€ тестировани€ позвол€ет в удобной форме поддерживать сценарии тестировани€ и исправлени€ ошибок, подробнее см. —правочник "¬етки"

«амещаетс€ при сборке

-

ѕеред сборкой информационной базы, база будет скопирована из родительской

”добно, когда родительска€ база содержит тестовые примеры с ошибками, например копи€ продуктивной базы или это база прототипа (моделировани€), в этом случае ошибочна€ ситуаци€, присутствующа€ в родительской базе после сборки базы исправлени€ ошибки, котора€ подчинена родительской, должна отсутствовать. ѕри этом после сборки базы будут содержать идентичные тестовые данные.

¬ажно - не следует в таких "«амещаемых" базах создавать и хранить какие-то контрольные примеры, так как они будут уничтожены при очередной сборке.

Ќе собирать

ѕри наступлении событи€ сборки (фиксации изменений в ветку, или по расписанию) »Ѕ не будет обновлена изменени€ми в св€занной с объектом сборки веткой Git. 

”добно дл€ долгоживущих стендов, например дл€ баз тестировани€ интеграции. ѕо окончании разработки можно наполнить »Ѕ тестовыми примерами, и дать коллегам с нею работать, при этом »Ѕ гарантированно не будет изменена. ѕри необходимости можно в любой момент подключитьс€ к такой »Ѕ в отладке, например, чтобы расследовать проблемные ситуации.

“аблична€ часть "ƒополнительные объекты сборки"

“аблична€ часть предназначена дл€ хранени€ ссылок на объекты сборки полученные в св€занной с объектом сборки ветке через запросы на сли€ние. ћеханизм в основном предназначен дл€ отображени€ баз в объектах сборки (техпроекты и исправлени€ ошибок), в которых можно посмотреть разрабатываемый функционал или исправление ошибки. ƒоступно по навигационной ссылке "»нформационные базы" у объектов сборки.

‘ормирование наименовани€ »Ѕ

ѕолное наименование

«аполн€етс€ вручную, содержит им€ эталонной »Ѕ.

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

ƒолжно быть таким же, как и на сервере —”Ѕƒ, если изменить им€ только в справочнике, база станет не доступной (см. описание механизма выше)

ѕсевдоним дл€ клонов

«аполн€етс€ вручную

-

»спользуетс€ дл€ автоматического формировани€ наименовани€ »Ѕ. 
Ќапример, если корнева€ база имеет ѕолное им€ "MainDB"  не имеет псевдонима, а объект сборки прив€зан к ветке 
"TP/00-00000077", и суффикс не заполнен то автоматическое им€ подчиненной будет "MainDB.TP.00-00000077"

Ќаименование корневой »Ѕ

-

Ќе измен€етс€, определ€етс€ по цепочке родительских »Ѕ.

«аполн€етс€ псевдонимом дл€ клонов (см. ниже) при его отсутствии ѕолным именем корневой »Ѕ.

¬етка (на форме заголовок скрыт)

-

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

ƒл€ корневого элемента поле скрыто.

—уффикс имени

-

«аполн€етс€ вручную, требуетс€, если к одному объекту сборки необходимо две или более тестовых »Ѕ.

Ќапример "MainDB.TP.00-00000077.ThisYear" и "MainDB.TP.00-00000077.LastYear"

Ќастройки »Ѕ - секци€ скрыта по умолчанию дл€ подчиненных »Ѕ, видимость можно включить параметром ниже

»ндивидуальные параметры »Ѕ

-

¬ключает видимость секции Ќастройки »Ѕ дл€ подчиненной базы

ѕри создании подчинЄнной »Ѕ пол€ ниже копируютс€ из родительской базы.

ѕользователь

ќпредел€ет им€ пользовател€ »Ѕ в кластере 1—, этот пользователь должен обладать административными привилеги€ми 

ѕароль

ѕароль пользовател€ »Ѕ в кластере

 ластер

Ёлемент справочника " ластеры 1—", в котором хран€тс€ параметры кластера 1—, в котором размещена »Ѕ.

—”Ѕƒ

Ёлемент справочника "—”Ѕƒ", в котором хран€тс€ настройки доступа и параметры —”Ѕƒ, в которой будет хранитьс€ »Ѕ

 аталог —”Ѕƒ

Ёлемент справочника "–азмещени€ баз на —”Ѕƒ", подчинЄн справочнику "—”Ѕƒ". —одержит ссылку на каталог сервера —”Ѕƒ, где будут физически хранитьс€ файлы »Ѕ

“аблична€ часть "ƒополнительные переменные"

ѕеременна€

—лужит дл€ обозначени€ имени переменных, используемых в скриптах конвейера и пакетных файлах

ћожно задавать любые идентификаторы, по правилу регул€рных выражений [A-Za-zј-яа-€0-9_]+

јлгоритм получени€

¬ыражение на встроенном €зыке 1—, выполн€етс€ в безопасном режиме.

¬ контексте выражени€ —труктура ѕараметры, имеюща€ три пол€: »Ѕ - ссылка на текущий элемент справочника "»нформационные базы", Ётап - им€ текущего этапа (Stage) конвейера строкой, —борочна€Ћини€ - ссылка на элемент справочника "—борочные линии", результат выражени€ может быть строкой, либо типом, допускающим не€вное преобразование в строку.

 нопка "«аполнить дополнительные переменные"

«апускает алгоритм скрипт, указанный на закладке "»нформаци€ об »Ѕ" справочника "“ипы —”Ѕƒ" скрипт, например sqlcmd -S ~!ServerName -U ~!UserName -P ~!Password -u -s "~!Delimiters" -h -1 -d ~!DBName -b -Q "SELECT type,name,physical_name FROM sys.database_files" должен возвращать текст, далее текст передаЄтс€ в алгоритм разбора на встроенном €зыке 1—, который обрабатывает полученный текст и извлекает из него необходимые дополнительные переменные информационной базы, например дл€ »Ѕ MS-SQL важными дополнительными характеристиками €вл€ютс€ логические имена файлов данных и лога транзакций, а так же физический путь хранени€ данных файла с данными и журнала транзакций. Ёти параметры необходимы дл€ корректного автоматизированного копировани€ »Ѕ, например дл€ функции "—копировать из родител€"



ѕеред копированием »Ѕ функцией "—копировать из родител€" можно помен€ть у приЄмной базы:  ластер, —”Ѕƒ,  аталог —”Ѕƒ. ¬ этом случае база будет скопирована и размещена на другой —”Ѕƒ и в другом кластере. Ёто удобно, когда проект »Ѕ наход€тс€ в разных контурах проекта (ѕродуктивный, “естовый контур,  онтур разработки).

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

Pipeline cannot be run.

Included file `http://gitlab.test.ru/sppr/hs/GetPipeline/CI_YML_TEST/ci-module.yml` does not have valid YAML syntax!

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

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

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

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

stages:

    - ~!Stages


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


StagesAndVariables

Lock

Copy

GetCF

Fetching

Convertation

Build

TestQQ

Update

Unlock

OnFailureUnlock


» этап 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

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

»мена переменных 
StagesStageRef зарезервированы. ќстальные переменные формируютс€ по принципам, описанным в —правочник "јлгоритмы определени€ переменных", там же описан механизм сворачивани€ нескольких заданий в одно.


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


—правочник “ипы —”Ѕƒ

—правочник предназначен дл€ хранени€ типов баз —”Ѕƒ, поддерживаемых 1—:ѕредпри€тием. 

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

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

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


–азделитель колонок запросов - используетс€ в предопределенном алгоритме "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, используема€ дл€ формировани€ имени заданий. ƒл€ неЄ определены два алгоритма получени€ значени€:

ƒл€ общего задани€

јлгоритм получени€

[  ]

—тр«аменить(ѕараметры.»Ѕ.Ќаименование,"/",".")

[V]

"United"


¬ этом случае если в шаблоне задани€ или самом задании не будет определено других переменных, получающих значение параметров информационных баз дл€ сборки и св€занных с ними веток, то будет получено значение "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/**/*

ќтчет ѕодготовка описани€ версии по техпроектам и ошибкам

ќтчет предназначен дл€ подготовки описани€ релиза. ”ровень детализации рассчитан таким образом, чтобы описание обновлени€, выводимое средствами Ѕ—ѕ не делать вручную, а просто скопировать из сформированного отчета:

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

 

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

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

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

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

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

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


ƒл€ ошибок, раздел€€сь пустой строкой, вывод€тс€ секции "ѕубликуемое описание", закладка "ѕризнание" и "ќписание" закладка "»справление"

ƒл€ реализованных идей выводитс€ описание реализации идеи в техническом проекте колонка "ќписание реализации идеи, исправлени€ ошибки" закладки "»деи и ошибки"


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

—правочник ќшибки


»зменены логика формы списка и формы элемента. ”лучшена эргономика работы с исправлением ошибок в варианте "¬ разных ветках", т.к. разные состо€ни€ исправлени€ в ветках приводили к неразберихе и не соответствию общему статусу ошибки. ƒл€ этого были расширены и дополнены состо€ни€ исправлени€ ошибок в ветке и статусов ошибки, так чтобы они соответствовали друг другу:

—татус ошибки

—осто€ние исправлени€ ошибок

ѕризнана

“ребуетс€ исправление

»справлена

»справлена

ѕроверена и исправлена

»справлена и проверена*

Ќе зарегистрирована

-**

«арегистрирована

Ќе рассмотрена*

Ќе признана

»справление не планируетс€

ќтозвана

-***

Ќе планируетс€ исправл€ть

»справление не планируетс€

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

** ѕри первой же записи ошибка переходит в статус "«арегистрирована" а дл€ всех веток версий выставл€етс€ состо€ние "Ќе рассмотрена", в случае если ошибка возвращаетс€ в статус "Ќе зарегистрирована"  (кнопкой "¬ернуть на регистрацию") в этом статусе состо€ние исправлени€ ошибок игнорируетс€, и общий статус ошибки всегда "Ќе зарегистрирована"

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


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

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

—правочник “ехнические проекты

¬ форму технического проекта добавлены элементы "—борка" - номер сборки , заполн€етс€ после успешной сборки технического проекта. –еквизит очищаетс€ автоматически, при передаче задач процесса, св€занных с техническим проектом на проверку.

–§–Є–≥—Г—А–∞4 ¬ажно! Ќеобходимо до начала сборки или в процессе еЄ передать задачу процесса, св€занную с техническим проектом "Ќа проверку", в противном случае, если сборка уже закончилась, реквизит не будет обновлЄн, более того, он будет очищен при передаче на проверку. ¬ этом случае, в отчет "ѕодготовка описани€ версии по техпроектам и ошибкам" технический проект включен не будет.

Ќа закладке "ƒополнительно" добавлена кнопка создани€ запроса на сли€ние   в ветку версии. 

“ак же, на закладке "ƒополнительно" возращЄн реквизит "»м€ базовой ветки". ѕри указании фиксации в этом поле файл отличий (diff) будет производитьс€ между веткой техпроекта и указанной фиксацией, такой способ указани€ помогает корректно загрузить изменени€ в случае, когда перед сли€нием в ветку версии ветка техпроекта обновл€лась до текущего состо€ни€ ветки версии (это делаетс€ очень часто, чтобы исключить конфликты сли€ни€ при помещении ветки техпроекта в ветку версии). 

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



—правочник ¬етки

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


¬ активной фазе проекта может быть зарегистрировано много ошибок, требующих подтверждение исправлени€. –екомендуетс€ в таких фазах не исправл€ть ошибки в ветке версии проекта, либо в одной ветке исправлени€ ошибок, а под каждую заводить отдельную от ветки исправлени€ ошибок, при отметке "»справлено" в элементе справочника "ќшибки" будет автоматически сформирован и прин€т (если нет конфликтов) запрос на сли€ние в ветку тестировани€, которую рекомендуетс€ пересоздавать после выпуска каждого релиза. ѕри подтверждении тестировщиком или автором ошибки исправлени€ будет сформирован автоматически запрос на сли€ние в ветку версии. “аким образом в ветке версии будут только подтвержденный функционал. ѕо событию "detached pipe" могут быть запущены регрессивные тесты сливаемой в ветку версии ветки исправлени€ ошибки. јвтоматического прин€ти€ запросов на сли€ние в ветку версии не предусмотрено. ќтветственный за сборку релиза сам должен проверить и прин€ть все исправлени€ в ветку версии. ѕри нажатии на кнопку "ѕересоздать в Git" ветка тестировани€ удал€етс€ в хранилище и создаЄтс€ заново от указател€ ветки версии, после чего определ€ютс€ удовлетворЄнные запросы на сли€ние в ветку тестировани€, которых не было в ветке версии (по учетным данным —ѕѕ–), —ѕѕ– заново формирует запросы из веток исправлени€ ошибок в ветку тестировани€. 

ѕодчиненный справочник —борки версии


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

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


¬ процессе записи статуса производитс€ попытка определить тип версии. ≈сли в наименовании фиксации содержатс€ текстовые строки RDef, описание версии, описание релиза, то сборке присваиваетс€ статус "‘инальна€" и выставл€етс€ флаг публикации. 


ƒата и врем€ сборки определ€ютс€ по данным сервера —ѕѕ–.


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

ќбработка предназначена дл€ настроек бота уведомлений системы взаимодействи€ (—¬), указани€ св€зей id проекта в Gitlab, приватного ключа пользовател€ —ѕѕ– в Gitlab  настроек уведомлений дл€ администраторов сборок.


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

Ѕот единый дл€ всех проектов. ѕосле первоначального создани€ бота, вместо кнопки "—оздать бота" будет присутствовать кнопка "ќбновить бота"

–§–Є–≥—Г—А–∞5 ¬ажно! »зображение бота хранитс€ в —¬, так что замена изображени€ в копи€х »Ѕ, не отв€занных от —Ѕ приведЄт к изменению изображени€ в основной базе.

¬ поле "ѕользователь ќ—" необходимо указать пользовател€, которым будут олицетворены все запросы от веб сервера к —ѕѕ–, этот пользователь будет ассоциирован с пользователем бота в части аутентификации операционной системой. ≈сли используетс€ веб сервер Apache, не поддерживающий анонимную аутентификацию тогда следует задать отдельно пользователю - боту пароль и использовать другой способ аутентификации.

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


–§–Є–≥—Г—А–∞6 ¬ажно! ≈сли база —ѕѕ– опубликована на веб сервере в виде тонкого клиента, то дл€ 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 eventsMerge 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 дл€ каждого проекта указать следующие настройки:

¬арианты и особенности сценариев учета исправлени€ ошибок в —ѕѕ– при использовании расширени€ «”правление сборкой GLI»

¬ расширении поддерживаютс€ несколько сценариев учета исправлений ошибок. ¬не зависимости от варианта при наступлении событи€ сборки —ѕѕ–, дл€ уведомлений ориентируетс€ по следующим критери€м:

  1. — точки зрени€ Git сборка происходит ветки. Git не знает что он собирает, по этому вс€ информаци€ кого уведомл€ть получаетс€ из —ѕѕ–.

  2. ќбъектом сборки считаетс€ любой объект, ссылающийс€ на ветку сборки (элемент справочника «ќшибки» в поле «¬етка исправлени€» шапки или в поле «¬етка исправлени€» в “„ «»справлени€ в ветках» или в поле «¬етка разработки» справочника «“ехнические проекты»), у которого не заполнен реквизит «—борка» и статус либо «»справлена», либо «»справлена и проверена». ” справочника «ќшибки» реквизит «—борка» в зависимости от способа исправлени€ ошибки (в разных ветках или в одной) может быть либо внизу, над кнопками:

    либо, если исправление ветки ведЄтс€ в разных ветках, в табличной части «»справлени€ в ветках»:

    “ехнический проект:

    «начение пол€ очищаетс€:

    1. ѕри записи элемента справочника «ќшибки» со статусом «»справлено» или «»справлена и проверена», либо в шапке, либо в табличной части «¬етки»

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

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

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


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

Ѕез индивидуальной »Ѕ, дл€ проверки исправлени€ используетс€ обща€ ветка тестировани€ ветки версии.

— выделенной, прив€занной к объекту сборки (ошибке или ветке) »Ѕ.

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

»Ѕ прив€зана к ветке версии.

ѕор€док уведомлений о собранных исправлений ошибок такой же, как и дл€ »Ѕ, прив€занной к ветке исправлени€ ошибок. “акой вариант удобен при начальном формировании ветки версии, например, сразу после того, как в новую ветку версии поместили обновленную от поставщика конфигурацию проекта, как правило ещЄ сырую и требующую рефакторинга. ¬ этих случа€х, релиза ещЄ не было и фиксации удобно делать пр€мо в ветку версии. ƒалее, после публикации первого релиза (или получени€ первой работоспособной базы, обычно это происходит одновременно) предполагаетс€ ввести запрет от непосредственных фиксаций в ветку версии (по крайней мере запретить делать фиксации дл€ участников проекта с уровнем доступа «–азработчик», оставить только дл€ администраторов проекта).

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

»Ѕ прив€зана к техническому проекту.

¬ ветках технических проектов регистрируют особый сорт ошибок, которые как правило ещЄ не дошли до релиза. „исто технически уведомлени€ ничем не отличаютс€ от варианта исправлени€ ошибки «— выделенной, прив€занной к объекту сборки (ошибке или ветке) »Ѕ.» ќшибки подобного рода вы€вл€ютс€ при внутреннем тестировании в »Ѕ, св€занной с веткой технического проекта. ≈сли технический проект ещЄ активен, как правило ошибку добавл€ют в этот же технический проект, где она прописываетс€ на закладке «»деи и ошибки» в остальном работа с ошибкой не отличаетс€ от обычной ошибки, исправл€емой в ветке исправлени€ ошибки. “ак же, в рамках технических проектов исправл€ютс€ ошибки, найденные в выпущенных релизах и исправление таких ошибок, может привести к изменению кода будущего функционала, который в насто€щий момент дорабатываетс€. ѕодробнее о таких ошибках можно прочитать здесь: 9.6. –абота с ошибками, требующими проектировани€ :: 1—:ѕредпри€тие 8.  онфигураци€ «—истема проектировани€ прикладных решений». –едакци€ 2.0. –уководство пользовател€ (1c.ru). ѕри сборке ветки если в техническом проекте нового функционала не реализовали (задач процессов на проверку не было передано) – номер сборки в “ѕ остаЄтс€ прежним, а номер сборки прописываетс€ только в ошибке. ¬ажным плюсом €вл€етс€ возможность не описывать подробно изменени€ в метаданных ошибки, так как все изменени€ ветки технического проекта будут загружены в таблицу ќћƒ вместе с данными технического проекта. —ледует отметить, что графа «ќписание реализации идеи, исправлени€ ошибки» не используетс€ в части ошибки при формировании отчЄта: «ќтчет ѕодготовка описани€ версии по техпроектам и ошибкам» дл€ вывода исправлений используетс€ текст с соответствующей закладки ошибки «»справление».

—ценарии создани€ веток в Git и взаимосв€зь веток Git с одноименным справочником «¬етки» в —ѕѕ–.

–азработчик, при выполнении доработок должен св€зать объект доработки в —ѕѕ– и указать —ѕѕ– в какой ветке производилась доработка или исправление ошибки. ”казание веток в объектах сборки позвол€ет автоматизировать операции – автоматическое формирование запросов на сли€ние при передаче в тестирование и получение метаданных доработок из Git, при разработке в техническом проекте. ƒелать это можно двум€ способами, описанными ниже.

—оздание веток из —ѕѕ–

”тилита расшир€ет возможности типового функционала дл€ работы с ветками Git. ќсновна€ ветка проекта - master вводитс€ автоматически при создании нового проекта в —ѕѕ–. ¬ Git на создаЄтс€ по умолчанию при создании первой фиксации в хранилище. ¬се остальные ветки можно создавать в —ѕѕ– через нажатие кнопки с пиктограммой: . ѕри нажатии на кнопку в удалЄнном Git будет предприн€та попытка создани€ ветки, если попытка успешна – будет выдано соответствующее сообщение, при неудачном создании будет выдано диагностическое сообщение. ƒл€ получени€ ветки в локальный клон хранилища разработчику необходимо выполнить операцию ѕолучить из удаленного хранилища (Fetch).

—оздание веток в —ѕѕ– при первичном помещении ветки в удаленное хранилище

¬нешне это может выгл€деть по-разному, однако технически при по€влении в удаленном хранилище фиксации с новой веткой производитс€ попытка св€зать эту ветку с соответствующим элементом справочника «¬етки», найти соответствующий объект сборки, и подставить элемент справочника «¬етки» в него, тем самым указав ветку разработки или исправлени€ ошибки в объекте сборки. ≈сли такого элемент в справочнике ветки отсутствует, предпринимаетс€ попытка определить родительскую ветку версии, и при отсутствии неопределенностей элемент справочника «¬етки» будет создан в —ѕѕ–, о чем пользователь получит уведомление в системе:


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



1ќписание соответствует версии 1.0.2.6, дополнено изменени€ми версии 1.0.2.15, остальные изменени€ и исправлени€ ошибок по ссылке ќписание обновлений