Руководство прикладного разработчика#

В руководстве приведены инструкции для прикладного разработчика компонента Сервис управления конвейером DevOps (DPM/PipeWork) (DPMS) (далее по тексту документа — "компонент") продукта Platform V DevOps Pipeline Management (DPM).

Системные требования программного компонента#

Системные требования приведены в разделе "Системные требования" Руководства по установке.

Подключение и конфигурирование#

Подключение с использованием графического пользовательского интерфейса#

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

Открыть web-браузер и обратиться по адресу http://{dpm-ipAddress}/dpm/front/main/loginpage
где {dpm-ipAddress} — адрес сервера DPM;
В открывшейся странице авторизоваться: ввести логин и пароль.

Подключение с использованием Public API#

Способ подключения#

Подключение к Public API осуществляется посредством вызова методов API.
Доступные методы Public API DPM перечислены в Swagger по адресу: https://<Адрес сервера DPM>:8080/dpm/swagger-ui.html
Доступные методы Public API QGM перечислены в Swagger по адресу: https://<Адрес сервера QGM>:8080/qgm/swagger-ui.html

Вызов метода DPM из Jenkins#

Для обращения к api DPM из Jenkins необходимо выполнить следующий набор действий:

Создать личный токен в DPM;
Добавить личный токен DPM в Jenkins;
Настроить скрипт Jenkins на использование токена.

Подробно о том, как создать личный токен DPM приведено в настоящем Руководстве, в разделе "Использование программного компонента" в подразделе "Личный токен (Создать токен DPM для авторизации из Jenkins)".

Добавить личный токен DPM в Jenkins#

В Jenkins перейдите в раздел Add Credentials
Выберите тип Username with password
Заполнить поля:
1. Username — ваш логин в DPM;
2. Password — сгенерированный токен из DPM;
3. ID — имя, по которому в Jenkins JOB происходит вызов данных кредсов (переменная CredentialsID);
4. Description — описание (необязательно к заполнению, например, My token from DPM)
Нажмите ОК для сохранения;
Убедитесь, что в списке отображаются новые учетные данные.

Создать Jenkins pipeline используя созданные ранее учётные данные#

Для авторизации можно использовать пример кода приведённого ниже.

Для проверки работоспособности:

заменить dpmtokensample на своё значение ID из Jenkins credentials;
заменить test на ключ проекта, к которому имеется доступ;
в url указать адрес сервера.

Остальные значения в этом коде менять не нужно:

withCredentials([
usernamePassword(credentialsId: 'dpmtokensample',
usernameVariable: 'dpmlogin',
passwordVariable: 'token')
]) {
httpRequest customHeaders:[[name:'login', value:dpmlogin],[name:'token', value:token]], url: 'http://<Адрес сервера>/dpm/api/user-public/subject-vars/test'
}

Получение значений id для построения запросов к API на примере готовых запросов#

Для целей настройки может потребоваться вызывать методы API из клиентов типа Postman и т.п., при этом в теле запроса требуется указывать значения идентификаторов объектов. Для получения значений идентификаторов удобно считывать эти значения из консоли (окна браузера, открытого в Режиме разработчика).

Обратите внимание
Все ID приведены в качестве примеров и НЕ АКТУАЛЬНЫ для промышленной эксплуатации.

"nexusId":

Откройте консоль;
Перейдите к созданию сервиса;
В поле Nexus выберите нужный пункт;
В консоли на вкладке Network найдите ExternalAppName.

"regexpVersionTemplate":

Откройте консоль;
Перейдите к созданию сервиса;
В консоли на вкладке Network найдите regexpTemplates;
Раскройте его.

"fssId":

Откройте консоль;
Зайдите в приложение для отображения списка сервисов;
В консоли на вкладке Network найдите fssRaoList.

"releaseActivityObject":

Откройте консоль;
Зайдите в сервис;
В консоли на вкладке Network найдите ReleaseActivityObjectView.

"raoKey":

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

Примеры API запросов#

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

Обратите внимание
Все ID, ключи и данные приведены в качестве примеров и НЕ АКТУАЛЬНЫ для промышленной эксплуатации.

Создание приложения#

Endpoint (DPM service):

POST http://localhost:8081/dpm/api/user-public/fss/create

Headers:

Body (raw json):

{
"name": "NEWFSS",
"key": "key02vsvssvrs",
"configurationItem": "ololo",
"lead": 8,
"automatedSystem": 37,
"subjectVars": []
}

Создание сервиса#

Endpoint (DPM service):

POST http://localhost:8081/dpm/api/user-public/rao/create

Headers:

Body (raw json):

{
"nexusId": 24,
"name": "nameofservi",
"key": "kiddsd01",
"nexusClassifier": "distrib",
"nexusExtension": "jar",
"repository": "dpmrepository",
"groupId": "ru.sbertech.dpm",
"artifactId": "dpmrepository",
"regexpVersionTemplate": 22,
"regexp": "(\\d+)[.](\\d+)[.](\\d+)",
"releasePattern": "$1",
"releaseCandidatePattern": "$0",
"fssId": 41,
"login": null,
"token": null,
"subjectVars": [],
"nexusCreds": null
}

Создание профиля сервиса#

Endpoint (DPM service):

POST http://localhost:8081/dpm/api/user-public/rao-profile/

Headers:

Body (raw json):

{
 "configuredPipeline": 0,
 "name": "string",
 "profileStatus": "ACTIVE",
 "rank": 0,
 "raoProfileType": "OTHER",
 "regexp": "string",
 "releaseActivityObject": 38959,
 "releaseActivityObjectVersions": [
 0
 ]
}

Получить значение переменных по ключу#

Endpoint (DPM service):

GET localhost:8080/dpm/api/user-public/subject-vars/4FP

Headers:

Body (none):

Замечание:

4FP — это ключ приложения/сервиса, из которого запрошены данные.

Добавить поменять удалить переменные по ключу#

Endpoint (DPM service):

POST localhost:8080/dpm/api/user-public/subject-vars/4FP

Headers:

Body (raw json):

{
"subjectVars": [
{
"name": "Stage",
"value": "neDeploy"
},
{
"name": "new",
"value": null
},
{
"name": "test",
"value": null
}
],
"createNew": true
}

Замечания:

4FP — это ключ приложения/сервиса, в котором обновляем данные;
"createNew": если флаг true, то все переменные, которые переданы в body, будут добавлены в приложение или сервис, если они отсутствуют. Если флаг false они будут проигнорированы, если переменных с таким значением "name" не создано ранее. Если поле "name" совпадёт с уже существующей переменной в приложении, то она будет перезаписана отправленным значением независимо от значения флага "createNew";
null в значении переменной = удалить переменную.

Отметить РК готовым к поставке или снять отметку#

Endpoint (DPM service):

POST localhost:8080/dpm/api/user-public/rc/ready-for-complex-release

Headers:

Body (raw json):

{
"key": "TEST_AK_001",
"originalVersion": "2.0.12",
"status": false
}

Добавить новый РК в DPM со стартом конвейера#

Endpoint (DPM service):

PUT localhost:8080/dpm/api/user-public/ci/rc-add

Headers:

Body (raw json):

{
 "raoKey" : "TEST_AK_001",
 "version" : "5.6.7"
}

Замечание:

raoKey — это ключ сервиса, в который будет добавлен РК указанной версии.

permissions:

MANAGE_RAO, CREATE_HIERARCHY_AS, CREATE_HIERARCHY_FSS, EDIT_GENERAL_HIERARCHY_AS, EDIT_GENERAL_HIERARCHY_FSS

Получить переменные от запущенного конвейера релиз-кандидата#

Endpoint (DPM service):

GET http://localhost:8080/dpm/api/user-public/rc/pipeline-vars/TEST_AK_001/1.0.2/

Headers:

Body (none):

Замечания:

слеш (/) на конце обязателен;
TEST_AK_001 — ключ сервиса;
1.0.2 — версия РК. Это то значение, которое возвращает переменная ${version}.

Обновить переменные в запущенном конвейере релиз-кандидата#

Endpoint (DPM service):

PUT http://localhost:8081/dpm/api/user-public/pipeline-var/create

Headers:

Body (raw json):

{
 "externalKey": "69823",
 "vars": {
 "param1": "новоезначениепараметра param1",
 "param2": "новоезначениепараметра param2"
 }
}

Замечание:

externalKey — это значение переменной ${externalKey} в фазе.

Обновить Release-link в Release-Notes релиз-кандидата#

Endpoint (QGM service):

PUT http://localhost:8082/qgm/v1/rn/release-link

Authorization (basic Auth):

Body (raw json):

{
 "artifactId": "dpmrepository",
 "groupId": "ru.sbertech.dpm",
 "repository": "dpmrepository-public",
 "version": "1.2.5",
 "releaseLink": "<ссылка на релиза в трэкере>"
}

Замечание:

Ссылка будет обновлена в РК, который подходит под соответствующие параметры gav + версия.

Создать QGM сервис в DPM через запрос#

Endpoint (DPM service):

POST http://localhost:8080/dpm/api/automatization/qgm/service/create

Headers:

token apitokendpm

Body (raw json):

{
"repository": "reponame",
"groupId": "ru.sberteh.test",
"artifactId": "artifact123",
"name": "qgmServiceName",
"ci": "",
"asKey": "dpmProjectKey"
}

Замечание:

asKey — ключ проекта DPM, в котором будет создан сервис QGM.

Настройка DPM#

Первоначальная настройка DPM после установки изложена в Руководстве по установке, раздел "Первоначальная настройка DPM".

Общие настройки системы#

Раздел общих настроек системы требует наличия у пользователя разрешения "Общие настройки DPM" и доступен только глобальным администраторам DPM.

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

При выборе раздела — откроется страница, содержащая соответствующие настройки системы.

Список настроек системы#

Список фиче-флагов — включение/отключение отдельных функциональных возможностей DPM;
Этапы конвейера — настройка этапов конвейера;
Шаблоны конвейеров — настройка глобальных шаблонов конвейеров;
Quality Gates — настройка Quality Gates;
Сервисные фазы — настройка параметров, специфичных для конкретных сервисных фаз;
Управление техокнами — согласование технических окон;
Шаблоны версионирования — настройка глобальных шаблонов наименования артефактов;
Внешние приложения — настройка доступных для пользователя стендов Nexus и Jenkins;
Домены Delegated — перечисление доменов, с которыми поддерживается делегирование;
Release Notes — настройка учетных записей для работы с RN;
Роли и разрешения — настройка прав пользователей;
Сообщения пользователям — настройка сообщений, отображаемых пользователям, а также ссылок на документацию, доступную по ссылке из UI.

Настройка прав#

Права в системе#

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

Редактирование прав#

После установки в системе создаются три роли:

DPM Administrator — администратор всей системы;
DPM Auditor — аудитор (для доступа к системе аудита);
DPM TW Administrator — администратор технологических окон.

Для добавления новой роли нажмите кнопку Добавить роль.
Для изменения прав и/или состава участников роли перейдите по ссылке Изменить в строке соответствующей роли.

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

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

добавьте новых пользователей — кликните курсором мыши в поле Пользователи и отметьте пользователей для предоставления доступа к роли;
и/или удалите из списка существующих пользователей — в поле Добавлены кликните "-" справа от ФИО пользователя.

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

добавьте новые разрешения — кликните курсором мыши в поле Разрешения и отметьте требуемые разрешения;
и/или удалите из списка существующие разрешения — в поле Разрешения кликните "Х" справа от названия разрешения.

Поле ввода всей необходимой информации нажмите кнопку Сохранить.

Настройки Внешних приложений#

Типы Nexus:

Nexus — Nexus2 maven репозиторий;
Nexus3 — Nexus3 maven репозиторий;
Nexus Registry — Nexus3 парсинг docker образов по html; (buildurlpattern: "${nexusInfo.nexusUrl}/service/rest/repository/browse/" +"${nexusInfo.repository}/v2/" +"${nexusInfo.groupId}/" +"${nexusInfo.artifactId}/tags/");
Docker Registry — Nexus3 парсинг docker образов по api.

Настройка доступных для пользователя стендов Nexus и Jenkins#

Доступные стенды Nexus, Jenkins, Docker Registry, ELK#

Глобальный администратор управляет списком доступных пользователю стендов Nexus и Jenkins (только эти стенды будут доступны для синхронизации артефактов и запуска job).
Для перехода к настройке стендов — в разделе общих настроек DPM перейдите в раздел Внешние приложения.

Откроется страница с перечнем стендов.

Добавление стенда#

Для добавления стенда нажмите кнопку Добавить приложение в левой верхней области страницы.

Откроется диалог создания нового стенда.

Поля:

Тип — выберите тип стенда Nexus или Jenkins и другие;
Название — наименование стенда (будет отображаться для пользователей);
URL — адрес стенда;
Логин — логин учетной записи;
Токен — токен/пароль учетной записи;
Aliases — список значений, которые пользователи в своих настройках могут использовать вместо URL стенда.

Обратите внимание:
Взаимодействие со внешней системой осуществляется по тому протоколу, который для этой системы указан в URL. Поэтому для взаимодействия со внешней системой по защищенному протоколу в URL должен быть указан защищенный протокол.

После ввода значений нажмите кнопку Сохранить в правом нижнем углу диалога.

Редактирование стенда#

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

Доступы для обращения ко внешним сервисам (Jenkins, Nexus)#

DPM применяет настройки сделанные на уровне Сервиса, а если таких настроек нет, то будут применены настройки Приложения, иначе Проекта.
Существует глобальный ТУЗ (настраивается администраторами DPM), он будет использован в случае, если нет переопределяющих настроек.

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

При автоматическом запуске фазы:

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

Для ручного запуска:

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

Для задания/изменения доступов:

При редактировании сохраненных ранее логина и токена, стирается токен (согласно требованиям безопасности). Если изменять логин/токен не требуется, то нажмите Отменить.

Настройка доступов на уровне Проекта#

Перейдите к списку проектов выбрав в навигационном меню Все Проекты
Перейдите в проект, затем перейдите в меню: Разделы → Доступы к внешним ресурсам
Выберите в левой колонке тип настраиваемой системы
С помощью поля Поиск по URL или названию инстанса укажите один из нескольких доступных серверов (заводятся администраторами DPM);
Ввести Логин и токен, нажмите Сохранить.

Настройка доступов на уровне Приложения#

Находясь в приложении на экране списка сервисов, перейдите в меню Разделы → Доступы к внешним ресурсам
Выберите в левой колонке тип сервиса
С помощью поля Поиск по URL или названию инстанса укажите сервер;
Ввести Логин и токен, нажмите Сохранить.

Настройка доступов на уровне Сервиса#

Находясь в настраиваемом Сервисе, перейдите в меню Настройки сервиса → Доступы к внешним ресурсам
Укажите тип сервиса в левой колонке
С помощью поля Поиск по URL или названию инстанса укажите сервер (список актуализируется администраторами DPM);
Ввести Логин и токен, нажмите Сохранить.

Указание логина/пароля Jenkins job на уровне отдельной ФАЗЫ конвейера#

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

Указание личных токенов для ручного запуска фаз#

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

Войдите в профиль пользователя — кликните Аватар пользователя, отображаемый в нижней части левой динамической панели и выберите Мой профиль
В разделе Доступы найдите нужный Jenkins в левой части окна, задайте токен в правой части

Настройка проектов#

Проекты#

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

Список всех проектов доступен на главной странице DPM Все проекты.

Создание проекта#

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

Откроется страница создания нового проекта.

На этой странице требуется заполнить, как минимум, обязательные поля.

Наименование (обязательное) — наименование проекта;
Уникальный ключ (обязательное) — используется в URL для обращения к страницам проекта (задается однократно и не подлежит изменению);
Описание проекта — описание проекта.
Ответственный (обязательное) — пользователь, ответственный за проект.

Дополнительно, переходя по соответствующим вкладкам, можно:

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

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

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

Глобальный администратор создает проект, назначая ему ответственного пользователя, который далее определит администраторов и других пользователей.
Администратор DPM не может быть добавлен в качестве Ответственного пользователя проекта.
Пользователь создаётся при первом входе в DPM (без этого действия его нельзя назначить ответственным за проект).

Редактирование проекта#

Перейти в режим редактирования проекта можно двумя способами:

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

Откроется страница Настройка проекта.

Отредактируйте необходимые параметры и нажмите кнопку Сохранить.

Настройка этапов конвейера#

Этапы конвейера#

Для перехода к настройке этапов — в разделе общих настроек DPM перейдите в раздел Этапы конвейера.

Откроется страница с перечнем этапов конвейера.

Создание этапа#

Для создания этапа конвейера нажмите кнопку Создать новый этап

Откроется диалог создания нового этапа.

Поля:

Название — имя этапа;
Лейбл — назначение;
Цвет этапа — цвет для отображения этапа;
Описание — описание этапа;
Available stages — словарь stage к этому этапу.

После ввода значений нажмите кнопку Сохранить в правом нижнем углу окна.

Редактирование этапа#

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

Настройка Quality Gates#

Quality Gates#

Для перехода к настройке Quality Gates — в разделе общих настроек DPM перейдите в раздел Quality Gates.

Откроется список текущих настроек Quality Gates.

Создание Quality Gate#

Для создания Quality Gate нажмите кнопку Создать Quality Gate

Откроется панель создания Quality Gate.

Поля:

Название — имя для Quality Gate;
Описание — Описание создаваемого QG;
Статусы для валидации — список возможных статусов QG;
Условия прохождения на этапе;
Валидатор — указывает валидатор QG;
Учетная запись — для чтения и публикации QG.

После ввода значений нажмите кнопку Сохранить в правом нижнем углу панели.

Редактирование Quality Gate#

Для перехода к редактированию QG — на странице с перечнем Quality Gates перейдите по ссылке Редактировать в строке редактируемой QG.
Откроется окно с информацией и настройками Quality Gate.
Отредактируйте необходимые поля и нажмите кнопку Сохранить в правом нижнем углу окна.

Настройки QG#

Для настройки QG job — в разделе общих настроек DPM перейдите в раздел Сервисные фазы.

Выберите вкладку Настройки QG.

Настройки QG job по умолчанию для публикации Nexus classifiers:

Job (путь до job для публикации): /job/AtlassianDevelopment/job/_TEST_FOLDER/job/SET_QG_FLAG
Jenkins (Jenkins сервис с job для публикации): jenkins default
Параметры (необходимые для публикации через jenkins job):

Параметр	Значение
nexusUrl	http://nexus.<your_domain>.ru:8099/nexus
groupId	${groupId}
artifactId	${artifactId}
nexusCredentials	NEXUS_DEV_CREDS
version	${version}
nexusRepo	${repositoryName}

Параметр для задаваемых QG (Параметр Jenkins job, в который передается перечень выбранных пользователем Quality Gates для публикации): keysList;
Login: пользователь jenkins, от имени которого будет выполняться job в jenkins;
Token: token пользователя jenkins, от имени которого будет выполняться job в jenkins.

Настройка глобальных шаблонов конвейеров#

Глобальные шаблоны конвейеров#

Для перехода к настройке шаблонов конвейеров — в разделе общих настроек DPM перейдите в раздел Шаблоны конвейеров.

Откроется страница с перечнем шаблонов конвейеров.

Создание шаблона конвейеров#

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

Откроется окно создания шаблона конвейеров.

Поля:

Название — имя шаблона конвейеров;
Описание (опционально) — описание шаблона конвейеров.

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

Редактирование шаблона конвейеров#

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

Настройка шаблона конвейеров#

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

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

Откроется Редактор схемы шаблона конвейера

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

Настройка глобальных шаблонов наименования артефактов#

Шаблоны наименования артефактов#

Шаблоны наименования артефактов задают правила определения релиз-кандидатов в репозитории.
Для перехода к настройке шаблонов — в разделе общих настроек DPM перейдите в раздел Шаблоны версионирования.

Откроется страница с перечнем шаблонов наименования артефактов.

Создание шаблона#

Для создания шаблона — нажмите кнопку Создать шаблон

Откроется диалог создания шаблона версионирования.

Поля:

Название — наименование шаблона;
Регулярное выражение для группировки — регулярное выражение, по которому в указанной директории репозитория артефакты будут регистрироваться в проекте;
Шаблон версии — выражение для формирования релизов, по которым группируются релиз-кандидаты;
Шаблон релиз-кандидата — выражение, на основе которого в проекте будут отображаться полученные релиз-кандидаты;
Описание — описание шаблона.

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

Миграция на текущую версию#

Установка текущей версии описана в Руководстве по установке.

Миграции, необходимые при переходе на текущую версию, выполняются при установке обновления компонента.

После установки обновления компонента — выполнять какие-либо миграции от прикладного разработчика не требуется.

Быстрый старт#

Простой пошаговый пример использования#

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

(подготовительный этап, вне DPM) Создайте в Nexus репозиторий для публикации дистрибутивов: настройку доступных репозиториев — см. подраздел "Доступы для обращения во внешние сервисы (Jenkins, Nexus)" раздела "Подключение и конфигурирование" настоящего Руководства;
(подготовительный этап, вне DPM) Продумайте состав операций, выполняемых конвейером по обработке дистрибутива и подготовьте соответствующие Jenkins jobs для добавления в конвейер;
(в DPM, глобальный администратор DPM) Создайте Проект (в т.ч. укажите ответственного за проект) — см. подраздел "Настройка проектов" раздела "Подключение и конфигурирование" настоящего Руководства;

Обратите внимание:
Для пользователя, назначенного ответственным за проект или приложение, наличие разрешений в отношении этого проекта или приложения не проверяется, соответственно, ответственный может выполнять любые операции в этом проекте или приложении.
В частности, ответственный за проект или приложение может настроить роли в этом проекте или приложении и, соответственно, делегировать пользователям-носителям роли те разрешения, которые перечислены для этой роли (см. подразделы "Роли" и "Ответственные за проект и приложение" раздела "Авторизация" Руководства по безопасности).

В проекте:
1. Задайте хранилище дистрибутивов — см. подраздел "Настройки Внешних приложений" раздела "Подключение и конфигурирование" настоящего Руководства;
2. Настройте роли пользователей — см. подраздел "Установка ролей группам" раздела "Использование программного компонента" настоящего Руководства;
Создайте Приложение — см. раздел "Использование программного компонента" настоящего Руководства;
В Приложении создайте Сервис — см. подраздел "Создание сервисов" раздела "Использование программного компонента" настоящего Руководства;

Сервис — набор дистрибутивов, выпускаемых командой разработки. Соответствует Group ID + Artifact ID в Nexus.
Например, DPM состоит из отдельных сервисов, у каждого из которых свой репозиторий кода: mail service, audit service, core и т.д. Каждый их этих сервисов отдельно версионируется.
Иерархией Приложение-Сервис можно пользоваться для разграничения прав и определения общих переменных (адресов стендов тестирования, параметров запуска и т.д.).
Проект и Приложение служат для группировок основного объекта работы — Сервисов.

Создайте конвейеры, по которым будут тестироваться дистрибутивы — см. подраздел "Настройка конвейера" раздела "Использование программного компонента" настоящего Руководства;
Определите конвейеры в профили (для связки отдельных видов дистрибутивов со своими конвейерами) — см. подраздел "Работа с профилями конвейеров" раздела "Использование программного компонента" настоящего Руководства;
Активируйте сервис (для получения дистрибутивов из Nexus и запуска конвейеров согласно настройкам, заданным в конвейерах и профилях) — см. подраздел "Запуск конвейера" раздела "Использование программного компонента" настоящего Руководства.

Использование программного компонента#

Требуемые разрешения#

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

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

Сценарий использования	Требуемое разрешение	Уровень
Создание Сервисов	Создание сервисов	Приложение
Синхронизация Сервисов	Управление сервисами и синхронизацией с Nexus	Проект, Приложение
Редактирование Сервисов	Общая настройка проекта или Общие настройки приложений или Управление сервисами и синхронизацией с Nexus	Проект, Приложение
Архивация релиз-кандидатов	Просмотр приложения и дочерних сервисов	Приложение
Настройка конвейера	Настройки конвейера	Проект, Приложение
Работа с профилями конвейеров	Настройка профилей конвейеров	Проект, Приложение
Действия над конвейерами (копирование, удаление экспорт/импорт)	Настройки конвейера	Проект, Приложение
Указание и переопределение ответственных за этап	Настройка ответственных за этап	Проект, Приложение
Указание и переопределение ответственных за фазу в конвейере	Назначение ответственных за фазу	Проект, Приложение
Архивация сервисов	Управление сервисами и синхронизацией с Nexus	Проект, Приложение
Управление технологическими окнами	Управление техокнами	Проект, Приложение
Настройка групп пользователей	Управление группами	Проект
Управление доступом на основе ролей	Управление ролями	Проект, Приложение
Настройка конвейера поставки	Управление поставками	Проект
Управление Release Notes проекта	Общая настройка проекта	Проект

Создание Сервисов#

Сервис — набор дистрибутивов, выпускаемых командой разработки. Соответствует Group ID + Artifact ID в Nexus.
Например, DPM состоит из отдельных сервисов, у каждого из которых свой репозиторий кода: mail service, audit service, core и т.д. Каждый их этих сервисов отдельно версионируется.

Для запуска дистрибутивов по конвейеру:

Создайте Сервис (свяжите DPM с Nexus);
Сконфигурируйте конвейер;
Добавьте конвейер в профиль;
Активируйте Сервис;
Следите за состоянием конвейеров дистрибутивов и управляйте их очередью.

Создание Сервиса#

Перейдите на страницу приложения и нажмите кнопку Создать сервис:

Заполните наименование и ключ сервиса. Данные параметры могут быть изменены после создания сервиса:

Наименование — имя Сервиса, отображаемое пользователю (потом можно поменять в любой момент);
Ключ — уникальный адрес сервиса в пределах DPM (потом можно поменять в любой момент);

Перейдите к настройке репозитория нажатием кнопки "К настройке репозитория".

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

Пример настройки maven репозитория Nexus2;
Пример настройки maven репозитория Nexus3;
Пример настройки репозитория Nexus Registry;
Пример настройки репозитория Docker Registry.

Пример создания сервиса Nexus2 maven repository#

Данный тип сервиса для поиска дистрибутивов использует файл maven-metadata.xml
Дистрибутивы будут обнаружены DPM в том случае, если в файле есть информация о них в тегах <version>

Выберите тип Maven репозиторий из Nexus

Выберите Nexus из списка предустановленных глобальным администратором

Заполните поля:

URL до папки c дистрибутивами:
- вставьте URL до конечного каталога, содержащего версии релиз-кандидатов (при этом нижеследующие поля будут заполнены автоматически)
- или вручную заполните отдельные поля в строгом соответствии с размещением дистрибутива в Nexus (см. ниже пример со скриншотом):
  ВАЖНО: после сохранения сервиса — ИЗМЕНЕНИЕ этих значений НЕ ДОПУСКАЕТСЯ
  - Nexus — сервер, на котором хранятся дистрибутивы (выберите из предустановленных администратором в системе). Произвольный ввод не допускается.
  - Репозиторий — корневая папка в Nexus, например Dpmrepository-public;
  - Group ID — последующие директории исключая конечную, содержащую версии РК;
  - Artifact ID — конечная директория, содержащая различные версии РК;
Extension — расширение артефактов. Требуется для генерации прямых ссылок на дистрибутивы. Например, zip, jar, war. Потом можно поменять. Влияет на генерацию ссылок для РК, а также на передаваемые ссылки в М36 и ФПД;
Classifier — часть имени файла, нужно для генерации прямых ссылок на дистрибутивы через fullArtifactpath. Потом можно поменять. Влияет на генерацию ссылок для РК, а также на передаваемые ссылки в М36 и ФПД.

Второй вариант получения значений полей Group ID и Artefact ID — это файл maven-metadata.xml или pom.xml

Таким образом, пример сервиса, дистрибутив которого размещен в Nexus2 maven репозитории будет выглядеть так:
(Выделенный раздел раскрывается при клике по ссылке Все настройки)

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

Пример создания сервиса Nexus3 maven repository#

Данный тип сервиса для поиска дистрибутивов использует файл maven-metadata.xml
Дистрибутивы будут обнаружены DPM в том случае, если в файле есть информация о них в тегах <version>

Выберите тип Maven репозиторий из Nexus

Выберите Nexus из списка предустановленных глобальным администратором

Заполните поля:

URL до папки c дистрибутивами:
- вставьте URL до конечного каталога, содержащего версии релиз-кандидатов (при этом нижеследующие поля будут заполнены автоматически)
- или вручную заполните отдельные поля в строгом соответствии с размещением дистрибутива в Nexus (см. ниже пример со скриншотом):
  ВАЖНО: после сохранения сервиса — ИЗМЕНЕНИЕ этих значений НЕ ДОПУСКАЕТСЯ
  - Nexus — сервер, на котором хранятся дистрибутивы (выберите из предустановленных администратором в системе). Произвольный ввод не допускается.
  - Репозиторий — корневая папка в Nexus, например maven-proxy (в данном случае важно, что в столбце формат указано maven2);
  - Group ID — последующие директории исключая конечную, содержащую версии РК;
  - Artifact ID — конечная директория, содержащая различные версии РК;
Extension — расширение артефактов. Требуется для генерации прямых ссылок на дистрибутивы. Например, zip, jar, war. Потом можно поменять. Влияет на генерацию ссылок для РК, а также на передаваемые ссылки в М36 и ФПД;
Classifier — часть имени файла, нужно для генерации прямых ссылок на дистрибутивы через fullArtifactpath. Потом можно поменять. Влияет на генерацию ссылок для РК, а также на передаваемые ссылки в М36 и ФПД.

Таким образом в DPM получаем следующие заполненные настройки в соответствии с примером:
(Выделенный раздел раскрывается при клике по ссылке Все настройки)

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

Пример создания сервиса Nexus3 NEXUS_REGISTRY#

Данный тип сервиса использует html для поиска образов в Nexus3.
Эта возможность зависит от настроек Nexus и доступна не для всех репозиториев.

Выберите тип из Nexus Docker образы

выберите Nexus из списка предустановленных глобальным администратором Nexus Registry

В поле репозиторий укажите корневую папку DOCKER_REGISTRY, например nuget-hosted

В поле путь до образа укажите все последующие папки исключив v2 и конечную папку с именем образа. Например:

В поле Имя образа укажите конечную папку как в примере:

Таким образом заполненные настройки выглядят так:
(Для раскрытия выделенного сегмента выберите Все настройки)

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

Пример создания сервиса Docker Registry#

Данный тип сервиса использует api для поиска образов в Nexus3.

Выберите тип хранилища

Выберите из списка доступных Docker Registry нужный. Список актуализируется администраторами DPM.

В поле "Путь до образа" укажите Component name
Внимание: обязательно отсутствие слеша в начале и в конце пути

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

Проверка синхронизации и настройка группировки#

Синхронизация — получение информации о релиз-кандидатах (РК), т.е. версиях указанного дистрибутива, хранящихся в указанном репозитории

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

После обнаружения через кнопку Настроить группировку перейдите к редактированию правил парсинга

Укажите правила и нажмите Сгруппировать для их проверки

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

Далее задайте параметры, с помощью которых DPM правильно распарсит список дистрибутивов (релиз-кандидатов). Можно выбрать конвенцию наименования из стандартных (из списка Версионирование) или настроить ее, редактируя поля ниже:

Регулярное выражение — по нему DPM находит нужные дистрибутивы, которые будут отображаться пользователю.
Шаблон версии — правило для группировки дистрибутивов по версиям, для задания правила можно использовать скобочные группы регулярного выражения. В дальнейшем будет возможность использовать эту группировку при работе со списком дистрибутивов (фильтрация, поиск) и при создании профилей.
Шаблон релиза — правило, по которому дистрибутив будет отображаться в DPM. Например, $1 обозначает первую скобочную группу, например релиз 7. $1.$2 обозначает первые две скобочные группы, например релиз 7.22.
Exclude regexp — исключающее регулярное выражение: используйте, если хотите исключить дистрибутивы.

Если в репозитории будут дистрибутивы, которые не соответствуют регулярному выражению и не были исключены, они сохранятся в версии Unknown c префиксом Wrong RegExp for RC. Для того чтобы они не отображались, используйте переключатель

Настройка автоматизации запуска конвейеров#

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

Настроить автоматизацию — будут созданы правила запуска конвейеров на новых РК, которые обнаружит DPM. Эти правила можно отредактировать в любой момент.
Не запускать — новые РК будут появляться в DPM, выбрать любой доступный конвейер можно будет вручную. Добавить или изменить правила можно в любой момент.

Синхронизация Сервисов#

После создания сервиса он может находиться в нескольких статусах:

Черновик/Не синхронизирован — если сервис создан в соответствии с данной инструкцией или скопирован из другого сервиса;
Синхронизируем дистрибутивы/Активен — если сервис создавался по полной CI цепочке. Данный вариант не рассматривается в инструкции т.к. он готов к использованию.

Статус "Черновик" или "Не синхронизирован" присваивается тем сервисам, которые не получают информацию о релиз-кандидатах из Nexus.

Сервисы не синхронизируются автоматически до момента задания правил, которые должны быть применены к обнаруженным дистрибутивам. Т.е. до синхронизации пользователь должен указать, что должен делать DPM с обнаруженными дистрибутивами, которые попадают под REGEXP сервиса.
При этом в общем случае существует всего 2 варианта:
Вариант 1: отобразить релиз-кандидат в списке, но не запускать на нём каких-либо конвейеров;
Вариант 2: запускать конвейер. Здесь можно указать набор правил, по которым будут запускаться конвейеры. Например, для версии 4 один конвейер, а для 5 другой. Правил может быть много, применяется первое правило, под которое попадает версия РК с верхнего до нижнего.
Эти правила называются профилями конвейеров, подробно о них можно прочитать в разделе Работа с профилями конвейеров.

После сохранения созданного сервиса или подачи команды Действия -> Обновить вручную DPM произведёт поиск версий РК в NEXUS и применит к ним настройки, которые указаны в профилях сервиса.
При первой синхронизации есть важное исключение, а именно профиль будет применён только к последней обнаруженной версии РК.

Обратите внимание, что после первой активации только последний опубликованный дистрибутив будет запущен по конвейеру (в соответствии с профилем), остальные сохранятся в DPM и для них будет доступен ручной выбор конвейера.

Статус синхронизации можно контролировать в верхней части страницы:

Активный — синхронизация успешно завершена;
Синхронизируем дистрибутивы, может занять несколько минут — выполняется опрос Nexus;
Временно потеряна связь — попытка синхронизации не удалась. DPM автоматически повторит попытку через некоторое время. Причину можно проверить в разделе История сервиса (Настройки сервиса → История);
Проблемы с Nexus — несколько попыток синхронизации провалилось, автоматическая синхронизация прекращена. Причину можно проверить в разделе История сервиса (Настройки сервиса → История).

Ручная синхронизация сервиса#

Обычно синхронизация проходит автоматически раз в 10 минут. Чтобы не ждать этого времени можно инициализировать её вручную через "…" → Обновить вручную

Отключение автоматической синхронизации сервиса#

При необходимости временного отключения обновления сведений из Nexus выберите "…" → Отключить репозиторий

В этом случае все ранее обнаруженные РК останутся в сервисе. Для включения сервиса достаточно будет нажать кнопку Синхронизация, это вернёт автоматическое обновление из Nexus.

Обратите внимание, что после деактивации DPM перестанет опрашивать Nexus на обновления по вашему Сервису, но для уже синхронизированных дистрибутивов можно будет запустить конвейер вручную, и все запущенные до деактивации конвейеры продолжат работу.

Для остановки работы конвейеров выполнить одно из действий:

Остановите отдельный дистрибутив;
В очереди на запуск выделите все требуемые дистрибутивы и отложите их выполнение/удалить из очереди;
На основной странице Сервиса выберите дистрибутивы и архивируйте их.

Ручное добавление РК (CI) — без синхронизации с Nexus#

Существует возможность самостоятельного добавления дистрибутива в DPM без процесса синхронизации.
Находясь в сервисе, на экране гонки релиз-кандидатов, нажмите Действия → Добавить релиз-кандидат

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

Редактирование Сервисов#

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

Для редактирования Сервиса:

Перейдите на страницу Приложения к списку Сервисов;
Кликом по иконке "три точки" откройте контекстное меню редактируемого Сервиса и выберите Редактировать

Измените требуемые параметры (подробнее в разделе Создание Сервисов);
После нажатия кнопку Сохранить отобразится окно со списком получившихся изменений. Могут быть переименованы релиз-кандидаты (дистрибутивы), версии, по которым они сгруппированы, какие-то релиз-кандидаты могут быть добавлены или заархивированы. Если у архивируемых релиз-кандидатов был выполняющийся конвейер, то он будет остановлен. ;
Подтвердите вносимые изменения.

Архивация релиз-кандидатов#

Те РК, движение которых по конвейеру более не требуется (например, развернутые в промышленную эксплуатацию или в отношении которых принято решение не развертывать ввиду необходимости доработки), можно архивировать — т.е. перенести в архив и тем самым исключить из основного Списка релизов.

Архивация РК#

Для архивации РК:
Находясь в списке РК сервиса, выберите РК для архивации и нажмите кнопку Архивировать.

Просмотр архива РК#

При необходимости архивированные РК можно посмотреть в Архиве релиз-кандидатов, для перехода в который:
Находясь в списке РК сервиса, нажмите кнопку Настройки сервиса и выберите пункт всплывающего меню Архив релиз-кандидатов.

Восстановление РК из архива#

Для восстановления РК из архива:

Находясь в списке РК сервиса, нажмите кнопку Настройки сервиса и выберите пункт всплывающего меню Архив релиз-кандидатов.
Выберите РК для восстановления из архива и нажмите кнопку Разархивировать.

Настройка конвейера#

Создание конвейера#

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

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

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

Создание конвейера Сервиса#

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

Перейдите на страницу Сервиса;
Кликом по иконке "три точки" откройте контекстное меню редактируемого Сервиса и выберите Конвейеры Сервиса;

На странице конвейеров нажмите кнопку Создать конвейер

Заполнить:
1. Наименование конвейера;
2. Описание (опционально).

Настройка наполнения и порядка этапов конвейера#

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

Перейдите по ссылке Редактировать, отображаемой около заголовка Схема конвейера.

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

Сохраните схему конвейера нажатием кнопки Сохранить.

Настройка фаз#

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

Перейдите в настройки этапа — нажмите иконку "шестеренка", отображаемую в правом верхнем углу этапа, в открывшемся диалоге нажмите кнопку Настроить фазы

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

Выберите тип фазы:
1. Jenkins — в фазе выполняется Jenkins job;
2. Ручная фаза — подходит для ручного тестирования, можно оставлять комментарии. Например, пункт о протоколе тестирования;
3. Сервисная — можно выбрать подтип:
  1. Для публикации Quality gates в виде Nexus classifier (будет использована shared lib);
  2. Для подготовки к передаче дистрибутива в ФПД (фонд программ и документации).
    Подробное использование QG описано в разделе Quality Gates в Nexus
Задайте Название фазы (обязательно), отображающее смысл выполнения задания, например, Deploy IFT.
Выберите Критичность — т.е. степень обязательности запуска фазы.
Выберите Режим запуска (обязательно) — автоматический, ручной или по условию.
1. при ручном — перед запуском фазы будет создана задача на ответственного за этап пользователя (или на нескольких), запуск произойдет после подтверждения.
2. при автоматическом — запуск фазы произойдет сразу после публикации артефактов в Nexus или после перехода на эту фазу.
3. при по условию — фаза будет запущена только в случае выполнения заданного условия, подробнее см. в разделе Условия запуска фаз.
Режим валидации (обязательно) — в случае ручного режима переход на следующую фазу/этап всегда будет происходить после подтверждения ответственного пользователя. В случае автоматического (ручной для Failed) режима переход к следующей фазе/этапу будет автоматическим при условии положительного статуса задания (Jenkins job), и автоматический подтверждает или отклоняет выполнение фазы согласно ответу от Jenkins.
Введите Job URL (обязательно для типа Jenkins фазы) — полный URL Jenkins job. URL будет провалидирован: если вашего Jenkins нет в списке, обратитесь к администраторам.
Задайте учетную запись Jenkins, из под которой запустится фаза. Вводить значения следует в тех случаях, когда для конкретного запуска не подходят настройки с верхних уровней: учетная запись, от имени которой будут проходить запуски на выбранном Jenkins, может быть задана на странице редактирования Сервиса, Приложения или Проекта (подробнее в разделе "Доступы для обращения во вешние сервисы (Jenkins, Nexus)").
Добавьте Ответственных за фазу — указанным пользователям (вместо ответственных за этап) будут поступать задачи подтверждения этапов.
Укажите Параметры запуска для параметризованных Jenkins job (подробнее в разделе Настройка параметров).
Jenkins stages (опционально) — этапы pipeline job, статусы прохождения которых необходимо фиксировать в DPM, влияют на прохождение фазы.
Нажмите кнопку Сохранить.

Настройка параметров#

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

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

Если для ввода запрашиваемого параметра необходим выбор из списка, то можно:

Задайте эти значения через Enter.

Используйте любую внутреннюю переменную, например, Переменные Приложения и Сервиса или переменную, которую будет возможность обновлять из Jenkins.

Настройки запрашиваемого параметра:

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

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

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

Post-action фазы#

Фазы, расположенные в этом блоке будут выполнены даже если фаза основного блока была провалена. Например, если тесты или деплой не успешны и вы понимаете, что в таком случае нужен откат, то в постэкшн добавляете job отката, который запускается по условию (не пройдена такая-то фаза в первом блоке).
Настройка этого типа фаз полностью аналогична настройке обычных фаз.
Для добавления post-action фазы воспользуйтесь кнопкой Добавить в панели Post-action фазы.

Использование глобальных переменных в конвейере#

Для передачи данных между разными Jenkins job можно использовать глобальные переменные.
Например, регистрируем переменную NeedLT (Требуется нагрузочное тестирование), в одной job проверяем, какие модули изменены, проставляем в DPM значение переменной NeedLT true или false. Затем job, в рамках которой должно выполняться нагрузочное тестирование, передаем текущее значение переменной.

Подробное описание в разделе "Переменные конвейера. Обновление значений из Jenkins".

Подгрузка новых настроек конвейера в процессе выполнения#

Возможно два вида выполнения конвейера на РК:

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

Если подгрузка изменений конвейера включена, то на экране Релиз-Кандидата с запущенным конвейером лейбл с источником конвейера будет подсвечен синим

Работа с профилями конвейеров#

В DPM существует возможность задать условия, по которым сконфигурированные заранее конвейеры будут автоматически назначены на новых релиз кандидатов.
Профиль можно использовать как маршрутизатор дистрибутивов по конвейерам.
Например, дистрибутивы, в наименовании которых есть постфикс -hotfix, должны идти по конвейеру для хотфиксов, остальные по конвейеру minor или major.
Перед созданием профиля убедитесь, что у вас уже создан Сервис и конвейер для него.

Создание профилей#

Для создания нового профиля:

Перейдите в меню Настройки сервиса → Конвейеры Сервиса находясь на экране релизов
Нажатием кнопки Профили конвейеров открыть панель Профили конвейера
В открывшейся панели нажмите кнопку Создать профиль
Заполнить условия применения профиля (сопоставить набор дистрибутивов с конвейером):
Название — любое понятное пользователям название, не влияет на применение конвейера.
Дистрибутивы выбранные — способ отбора релиз-кандидатов под правило применения конвейера:
- По версии — укажите цифру версии. Например, если указать 17, то данный профиль будет применен ко всем РК версии 17. Например: 17.0.1 или 17.12.3
- По RegExp — отбор посредством регулярного выражения, например:
  - 2.0.3 — применится только к версии 2.0.3;
  - (\d+)[.](\d+)[.](0) — применится ко всем РК, у которых последняя группа цифр равна 0. Например, 2.0.0, 2.5.0, 16.3.0;
  - (2)[.](\d+)[.](\d+) — применится ко всем РК с версией 2.
После синхронизации дистрибутивов укажите действие с РК, попадающим под условия профиля: запустить конвейер автоматически или не запускать.
Сохраните изменения нажатием кнопки Сохранить

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

Порядок применения профилей#

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

В меню профилей конвейера нажмите кнопку Изменить порядок

Изменить порядок профилей перетаскиванием.

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

Работа с глобальными конвейерами#

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

Например, релиз-кандидат 1.0.0 был запущен по глобальному конвейеру.
После внесения изменений в глобальный конвейер, опубликованный после этого 1.0.1 будет использовать новую версию конвейера, а 1.0.0 нужно остановить и запустить с глобальным конвейером заново через меню Действия → Перезапустить.

Создание глобального конвейера#

В ранее созданном Проекте или Приложении:

Зайдите в окно Настройка Проекта/Приложения (в списке проектов/приложений перейдете по ссылке Редактировать или находясь в окне проекта/приложения нажмите кнопку Разделы);
Зайдите во вкладку Глобальные конвейеры

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

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

Переменные используются в настройках фазы в параметрах запуска Jenkins (в поле значения параметра начните вводить ${ далее система подскажет варианты):

Описание различных переменных приведено в разделе "Переменные (параметры) в DPM".

Переопределение переменных#

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

Перейдите в окно Настройка Приложения или на страницу конвейеров Сервиса;
Найдите нужный конвейер, откройте переменные и задайте новые значения.

Действия над конвейерами (копирование, удаление экспорт/импорт)#

Возможные состояния конвейеров:

Настроен (Available) — полностью настроенный конвейер, который можно добавить в профиль или применить к отдельному релиз-кандидату;
Черновик (Draft) — черновик конвейера, не хватает настроек;
Импортированный — нужна доработка, подробнее см. ниже в подразделе "Экспорт и импорт конфигураций";
Архивный (Archived) — архивные конвейеры, которые больше не используются.

Инструкция по созданию конвейера.
Для перехода к списку конвейеров Сервиса (для глобальных конвейеров):

Откройте страницу Сервиса;
В меню Настройки сервиса выберите Конвейеры Сервиса

На странице конвейеров доступно создание, редактирование, удаление, копирование, импорт в json и экспорт конвейеров.

Копирование конвейеров#

В рамках одного Сервиса#

Для создания копии конвейера перейдите в общем списке напротив нужного нажать Действия и выбрать в выпадающем меню Дублировать. Копия будет доступна для редактирования.

Экспорт и импорт конфигураций#

Настройки конвейера можно выгрузить в JSON.

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

Перейдите на страницу конвейеров;
В строке действий с конвейером выберите Экспортировать в JSON

Скачается файл настроек.

Для импорта:

Перейдите к списку релиз-кандидатов, в меню Настройки сервиса выберите Конвейеры Сервиса;
Нажмите кнопку Импортировать;
Перетащите JSON на форму (или следуйте подсказкам на форме)

Нажмите кнопку Импортировать.

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

Редактирование конвейеров#

Для редактирования конвейеров перейдите на страницу конвейеров (меню Настройки сервиса → Конвейеры Сервиса).
Функция редактирования доступна для конвейеров в статусах Available и Draft.
В строке, соответствующей нужному конвейеру, перейдите по ссылке Редактировать.

Архивирование конвейеров#

Для архивирования конвейеров перейдите на страницу конвейеров (меню Настройки сервиса → Конвейеры Сервиса).
Функция архивирования доступна для конвейеров в статусах Available и Draft.
В строке, соответствующей нужному конвейеру, нажмите кнопку "Еще" и во всплывающем меню выберите Архивировать.

Условия запуска фаз#

В зависимости от данных релиз-кандидата, значений переменных можно задать режим запуска фазы: в момент, когда дойдет очередь до фазы, проверятся условия, по которым выберется режим запуска.
Например, если статус предыдущей фазы тестирования FAILED, режим запуска текущей фазы делаем ручным, в противном случае — автоматический.
Условия проверяются сверху вниз, если ни одно из условий не выполняется (т.е. не равно true), то используется дефолтный режим запуска:

Условия описываются логическим выражением, для его описания доступны следующие операции:

Вид операции	Операция
Операции над логическими выражениями	AND, and, && OR, or, \|\|
Операции проверки условий (с вариантами написания)	IS, is, == IS NOT, is not, != contains — значение операнда содержит строку, пример: ${version} contains "2.0" in ("a", "b", "c") — значение операнда входит в список "a", "b", "c", пример ${RC.phase.buildResult.D#0} in ("UNSTABLE", "FAILURE")
Операнды	Строковые значения: Встроенные переменные (${version}, ${fullArtifactPath} и т.д.) Переменные конвейера (значения могут быть обновлены из Jenkins) Переменные Приложения, Сервиса Строки в двойных кавычках, "SUCCESS", "FAILURE", "TRUE", "FALSE", любые другие true, false, null
Возможные значения логических выражений	true, false, null

Если переменная Приложения/Сервиса не была задана, то в условиях запуска фаз и параметрах Jenkins она будет проверяться в том же виде, в каком была добавлена в настройки: #{thisRAO.test} будет передана в Jenkins и проверен в условиях запуска как #{thisRAO.test}.

Примеры условий:
${version} == #{КЛЮЧ_СЕРВИСА.lastVersion} and (${time_param} in ("MORNING", "DAY") or ${needLT.ST} != false)
Текущая версия совпадает с последней версией Сервиса (КЛЮЧ_СЕРВИСА можно посмотреть на странице Сервиса или скопировать из URL) и выполняется одно из условий: значение переменной time_param входит в список "MORNING", "DAY" или needLT на этапе ST не равно false.

Указание и переопределение ответственных в конвейере#

Указание ответственных#

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

Для указания ответственных за фазу:

Перейдите к списку конвейеров (Страница Сервиса → Настройки сервиса → Конвейеры сервиса);
В строке настраиваемого конвейера перейдите по ссылке Редактировать;
Перейдите в настройки этапа — нажмите иконку "шестеренка", отображаемую в правом верхнем углу этапа, в открывшемся диалоге нажмите кнопку Настроить фазы
На экране настройки нужной фазы нажмите Добавить в поле Ответственные за фазу

Введите ответственных;
Укажите режим подтверждения

Если необходимо разделить пользователей имеющих право подтверждать задачу и перезапускать её, то включите Разделить права

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

ответственные смогут подтвердить задачу, но не смогут перезапустить фазу;
пользователи, имеющие право на перезапуск, не могут подтвердить задачу;

Сохраните изменения.

Включение возможности переопределения ответственных#

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

Перейдите к списку конвейеров (Страница Сервиса → Настройки сервиса → Конвейеры сервиса)
Находясь в списке конвейеров нажмите Настроить в столбце Ответственные

Включите возможность переопределения напротив соответствующей фазы

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

Переопределение ответственных#

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

Перейдите к списку конвейеров (Страница Сервиса → Настройки сервиса→ Конвейеры сервиса);
Находясь в разделе конвейеров Приложений или Сервисов, перейдите по ссылке в столбце Ответственные нужного конвейера

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

Внесите нужные изменения.

Критичность выполнения фазы (опциональность)#

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

Задание критичности исполнения фазы#

Для задания опциональности любой фазы используется блок Критичность в окне настройки фазы.

Всего доступно 3 состояния:

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

Определение условий критичности фазы#

В блоке Критичность выберите пункт По условию

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

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

Задайте статус в поле То. Фаза примет этот статус только в том случае, если сработает условие в поле Если

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

Можно задать любое количество условий, но будет применено либо первое, которое вернёт True (на этом проверка будет закончена) либо, если ни одно из условий не вернуло True, фаза останется в статусе По умолчанию.

Условия запуска этапов#

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

Условия запуска этапа. Данные условия проверяются в первую очередь.
QG проверки. Эти условия будут запущены если пройден первый этап проверки.

Первая ступень условий запуска этапа#

Для настройки условий запуска этапов в настройках конвейера нажмите на иконку "шестеренка" этапа → По условию

Указать условия:

Выражения будут проверены от верхнего к нижнему (их можно менять местами перетаскивая);
Если условие вернёт true, то остальные выражения не будут проверены, и будет выполнено действие в блоке То

Результатом условия может быть 3 варианта:

Запустить этап — этап будет запущен как обязательный;
Запустить этап как опциональный — этап будет запущен как опциональный (как будто на нем включен чекбокс опционального);
Пропускать — этап будет пропущен.

Обратите внимание
Условия запуска этапа (до проверки QG) выполняются один раз. При перезапуске этапа они будут проигнорированы.

Вторая ступень условий запуска этапа — в зависимости от флагов Quality Gates#

Анализ флагов QG как условий выполнения этапов изложен ниже в подразделе Настройка проверки QG для управления запуском фаз работающего конвейера.

Quality Gates в DPM#

Общая информация о Quality Gates#

Quality Gate (QG) — это запись (отметка) о прохождении какой-то проверки для определённой версии Релиз-Кандидата.

Результат прохождения каждой отдельной проверки фиксируется (публикуется) в QG посредством установки флага.
Флаг может принимать только одно из значений из списка Статусов для публикации, предопределенных для этой QG. Существует множество способов публикации флагов: сервисные фазы конвейеров, API, библиотека DPMPipelineUtils и др.

Важно

QG — это виды проверок, а конкретные флаги публикуются как результаты проверок конкретных артефактов, для каждого из которых DPM нужно создать соответствующий QG-сервис.

Значения опубликованных флагов хранятся до момента полного останова конвейера (т.е. при выполнении в отношении конвейера, запущенного для конкретной версии РК, Действия Прервать — опубликованные флаги сохранятся, а Действия Остановить — исчезнут, и останутся лишь в Истории флагов).

Таким образом, работа с QG предполагает 3 основных направления:

Создать QG сервисы(ы) и определить какие QG использовать:
- общие для всех проектов (настраиваются глобальным администратором DPM)
- и/или создать QG в проекте.
Опубликовать флаги QG как результаты выполненных проверок (см. ниже подраздел "Ограничения на публикацию и проверку через DPM стандартных Quality Gate")
Проверить значения флагов QG как условия выполнения других шагов конвейера.

Типы QG#

QG может быть:

определённой или рекомендованной каким-либо регламентом (стандартные Quality Gate) или
созданной пользователем в конкретном проекте, под конкретные ситуации и задачи (кастомный Quality Gate).

Стандартные Quality Gates — это отметка о прохождении какой-либо проверки, и она может иметь статусы:

ok (пройдена);
err (провалена).

Кастомные Quality Gates — это тоже отметка, но:

создаваемая пользователем проекта в рамках проекта (не носит обязательный характер и не привязана к какому-то сервису или регламенту);
может иметь любые статусы дополнительно к ок и err (например skipped, ASdFGWRE142, deploy_ready);
может иметь любую логику, которую определяет сам пользователь, настраивая конвейер (например err = проверка пройдена, а ок = проверка провалена).

Где хранятся Quality Gate, куда их публиковать#

Раньше Quality Gate хранились в Nexus, но с апреля 2021 публиковать и проверять можно только в сервисе QGM.
Если для публикации использовались фазы QG, то ничего не изменится, они продолжат функционировать, но публиковать будут в QGM.
Для новых конвейеров настоятельно рекомендуется использовать только Публикацию Quality Gate в QGM.

Ограничения на публикацию и проверку через DPM стандартных Quality Gate#

Не все стандартные флаги доступны для самостоятельной публикации пользователем через DPM, а также не все проверяются в QGM.
Это связано с тем, что некоторые флаги представляют собой проверки в отдельных сервисах по ряду параметров, их самостоятельная публикация невозможна т.к. по сути является нарушением процедуры проверки, принятой в организации.
Например, флаги OSS и SAST.
Флаг SAST — проставляется автоматически, если вы подключили в вашей сборочной job SAST сканирование — именно его результат отправляется в SALM сервис (сервис безопасности) и проверяется в дальнейшем флагами SAST SALM CI и SAST SALM CD.
Предположим, пользователь опубликует эти флаги в QGM сервис самостоятельно и после этого запустит проверку в DPM.
При проверке DPM отпросит SALM-сервис о результате сканирования OSS и SAST (если они проходили для этого дистрибутива). Хэш коммита для проверки в SALM-сервисе будет взят из ReleaseNotes. Таким образом даже если в QGM есть флаг, подтверждающий успешную проверку, она может провалиться в DPM по причинам:

Проверка провалена или не запускалась для данного хэша коммита;
Проверка пройдена, но хэш коммита изменился.

Создание QGM сервиса#

Все автоматически перенесённые и созданные сервисы QGM доступны в разделе Мои сервисы.
Допустимо создание только одного уникального QGМ сервиса.
Невозможно создать дубликат сервиса QGM, если такой же сервис уже существует в каком-либо проекте.

Для создания нового сервиса QGM отдельно от сервиса DPM (например, если сервис DPM был создан ранее) нажмите кнопку Создать QG сервис (необходимо обладать ролью Управление Quality Gates).

Удаление и Перенос QGM сервисов#

Удаление или перенос QG сервиса между проектами не предусмотрены.

Настройка справочника QG в DPM#

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

Изменение справочника QG доступно ролям пользователей, у которых есть разрешение Управление Quality Gates.

Для настройки кастомного QG в рамках проекта:

Перейдите в окно проекта и нажмите кнопку Управление Quality Gates, в открывшемся меню выберите Доступные Quality Gates;
Нажмите кнопку Добавить QG
В открывшейся панели создания QG введите:
- Название — название нового QG;
- Описание (отобразится на запущенном конвейере, и пользователи вашего конвейера увидят это описание) — опишите, какие проверки проходят в рамках данного QG;
- Статусы для публикации: — перечислите необходимые статусы для данного QG. По умолчанию указаны ok и err, но можно их удалить и добавить свои. При необходимости задать разные учетные записи на запись и чтение QG нажмите Разделить права:.
- Логин для чтения и публикации: — логины ТУЗ, под которыми будет выполняться запись и чтение QG.
Если сначала в конвейер добавили QG qg1, а затем название qg1 изменили на qg2, то в конвейере останется qg1 — изменения не применятся в конвейер, так как этот справочник используется как подсказка и прямой связи между ним и настройками конвейера нет.

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

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

Обратите внимание
Флаги с отметкой Общий доступны всем командам.
Созданные пользователем флаги доступны только в рамках соответствующего проекта и НЕ имеют отметки Общий.

Переопределение учётных записей чтения и публикации#

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

Пример флага, в котором можно менять настройки прав учётных записей (есть ссылка "Задать"):

Пример флага, в котором нельзя менять настройки прав учётных записей (нет ссылки "Задать"):

Если ТУЗ имеет право на чтение и запись, достаточно указать его в соответствующем поле:

При необходимости разграничить чтение и запись по разным учётным записям — следует активировать переключатель Разделить права и в соответствующих разделах указать нужные ТУЗы.
В примере ниже user может читать флаги, но не публиковать, TUZadministrator может публиковать, но не читать.

Также возможны варианты задания отдельных ТУЗ только на чтение или только на публикацию. Для этого требуется активировать переключатель Разделить права и заполнить только одно поле.

Задать/переопределить ТУЗ на чтение и публикацию флагов#

Кто может выполнить действие: пользователь с ролью, для которой задано разрешение Управление Quality Gates (см. в разделе "Задать/переопределить пользовательские права")

Шаги:

Зайдите в свой проект в DPM и далее перейдите в подраздел Управление Quality Gates → Доступные Quality Gates
Напротив нужного QG перейдите по ссылке Задать. В появившейся форме в поле Логин для чтения и публикации укажите соответствующие ТУЗ (их может быть несколько) и нажмите кнопку Сохранить
Обратите внимание, что на запись и чтение флагов можно задать разные учетные записи

Задать/переопределить ТУЗ для групп флагов#

Группы флагов — это объединенные в группу флаги. Например, этап CDP — которым централизовано задается учетная запись на чтение или запись.
Создает группы флагов, а также определяет права на чтение и запись для ТУЗ, глобальный администратор DPM.
Глобальный администратор может предоставить возможность переопределять ТУЗ и его права для какой-либо группы флагов. В этом случае у пользователя с разрешением Управление Quality Gates будет доступна ссылка Задать другую, после нажатия на которую появится стандартное окно редактирования учетных записей.

Кто может выполнить действие: пользователь с ролью, для которой задано разрешение Управление Quality Gates.

Шаги:

Зайдите в свой проект в DPM и далее перейдите в подраздел Управление Quality Gates → Доступные Quality Gates.
Перейдите по ссылке N групп.

При необходимости скорректируйте учетные записи и нажмите кнопку Сохранить.

Публикация QG в QGM#

Для публикации флагов в QGM необходимо использовать новый тип сервисной фазы — Публикация Quality Gate в QGM (в этом случае публикация в Nexus не происходит).
В фазе Публикация Quality Gate в Nexus есть возможность публиковать только ok флаги, но публикация будет и в Nexus, и в QGM.

Для настройки публикации QG:

Перейдите в окно Редактирование конвейера
Перейдите в настройки этапа — нажмите иконку "шестеренка", отображаемую в правом верхнем углу этапа, в открывшемся диалоге нажмите кнопку Настроить фазы
Выберите тип фазы Сервисная фаза → Публикация Quality Gate в QGM;
Добавьте Флаги QG для публикации. В одной фазе можно публиковать сразу несколько QG
Выберите режим публикации:
1. В режиме публикации По умолчанию можно задать флаг, который будет публиковаться у этого QG в рамках этой фазы всегда.
  - Если добавить условие публикации, то название режима изменится на По условию, при этом условия будут проверяться в заданном в настройках порядке: сначала первое (верхнее) и т.д.
  - Если при проверке не выполнено ни одно условие, то будет выполнено действие по умолчанию: это может быть публикация флага и пропуск публикации;
2. Если при ручном запуске фазы выбрать При запуске фазы, то ответственный за запуск сможет указать флаг сам.

(–) Quality Gates в Nexus#

QG в NEXUS больше не хранятся. Для публикации и проверки флагов используется QGM.
Хотя фазы публикации QG автоматически публикуют флаги в QGM, настоятельно рекомендуется использовать только фазы Публикация Quality Gate в QGM. Подразделы, отражающие старую практику публикации QG в Nexus, и оставленные для обратной совместимости, помечены (–).

(–) Список доступных для создания QG#

В данный момент DPM поддерживает проставление QG в Nexus из перечисленного ниже списка:

QG.CI.1 Static Code Analysis
QG.CI.2 API First Check
QG.CI.3 SAST
QG.CDL.1 BVT
QG.CDL.2 Dev LT
QG.CDL.3 Smoke ST
QG.CDL.4 Smart Regress ST
QG.CDL.5 NF ST
QG.CDL.6 Smoke IFT
QG.CDL.7 Smart Regress IFT
QG.CDL.8 NF IFT
QG.CDL.9 DAST
QG.CDL.10 LT
QG.CDP.1 Smoke UAT
QG.CDP.2 Smart Regress UAT
QG.CDP.3 NF UAT

(–) Настройка конвейера для добавления флагов QG в Nexus#

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

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

Обратите внимание

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

(–) Размещение QG#

Эта настройка позволит выкладывать результат фазы в виде QG по результату прохождения фазы. Для настройки произведите следующие действия:

Найдите нужный этап в конвейере, в рамках которого требуется настроить добавление флагов в Nexus, и перейдите в настройки этого этапа — нажмите иконку "шестеренка", отображаемую в правом верхнем углу этапа, в открывшемся диалоге нажмите кнопку Настроить фазы
В левой части экрана выберите фазу, на этапе которой требуется размещение QG
В правой части экрана выберите типа фазы Сервисная фаза, тип действия Публикация Quality Gate в Nexus

Настройте:
- Опциональная — следующие фазы будут запущены без ожидания результатов или с обязательным ожиданием.
- Quality Gates — список QG, которые будут добавлены, можно добавить несколько.
- Режим запуска.
- Режим валидации фазы.
В приведенном примере, будут добавлены QG CDL 2 Dev LT, GS CDL 4 Smart Regress ST, GC CDL9 DUST.
Механизм добавления QG будет запущен автоматически, и если QG будут успешно добавлены, то выполнение Pipeline будет продолжено.
Конвейер ниже добавляет QG только если будут успешно выполнены предшествующие фазы.
Сохраните конфигурацию этапа и конфигурацию конвейера, предварительно:
- убедитесь, что все этапы в вашем конвейере настроены корректно — по значку в правом верхнем углу экрана;
- поверьте настройку — обновлять ли запущенные релиз-кандидаты.
Активируйте ранее созданный/измененный конвейер.
Убедитесь, что конвейер по умолчанию именно тот, который был ранее создан или отредактирован.
Теперь ваши новые релиз кандидаты, будут автоматически добавлять QG.

(–) Рекомендации использования и технические ограничения#

Если в вашем конвейере, ранее уже были проставлены флаги в Nexus и настроено добавление этих же флагов в Nexus при помощи DPM, ошибки не возникнет, и будут добавлены только те флаги, которых в Nexus не было.
DPM отработает корректно и на странице релиз кандидата будет отображено, что все стадии выполнены успешно.
Тем не менее добавлять один и тот же флаг в Nexus несколько раз не рекомендуется!
Работа QG JOB устроена следующим образом: она добавляет все QG, настроенные в рамках фазы, а также, проверяет, успешно ли они были добавлены в Nexus.
Если на этапе проверки наличия будет получена ошибка, фаза будет считаться неуспешной.
На данный момент DPM не позволяет работать с пользовательскими QG, а дает возможность обрабатывать предустановленный список.

Настройка проверки QG для управления запуском фаз работающего конвейера#

Добавление проверки QG доступно в конвейерах Проекта, Приложения, Сервиса.
Для настройки:

Перейдите в окно Редактирование конвейера;
Перейдите в настройки этапа, для которого требуется проверка QG — нажмите иконку "шестеренка", отображаемую в правом верхнем углу этапа, в открывшемся диалоге нажмите кнопку Настроить Quality Gates

Настройка проверки QG, общих для всех проектов#

Общие QG — универсальные для всех проектов (они перечислены и создаются в общих настройках DPM).

Для настройки проверки общих Quality Gates в открывшейся боковой панели "Настройки проверки Quality Gates":

Выберите QG:
- для добавления QG нажмите кнопку Добавить проверку
- для изменения настройки QG, проверка которой ранее уже добавлена для этапа, перейдите по ссылке Изменить в строке этой QG
В открывшейся области настройки проверки QG укажите:
- Проверять — выберите проверяемый QG
- Перед запуском / После выполнения этапа — выбор этапа, не запускаемого при "проваленном" QG:
  - Перед запуском — трактуется как Предусловие: не запустится настраиваемый этап конвейера;
  - После выполнения — трактуется как Постусловие: не запустится следующий этап конвейера;
- Опциональность проверки — DPM в любом случае попытается проверить QG. Но для Опциональных проверок: если QG не будет найден или проверка будет провалена, то на прохождение конвейера это не повлияет: соответствующий этап будет запущен;
- Для некоторых проектов (по согласованию с отделом безопасности) доступна проверка не последнего флага QG, а любого: например, если для QG хотя бы раз была пройдена интеграционная проверка, то считается, что несмотря на последующие проваленные проверки, QG пройден;
Сохраните настройку QG — нажмите кнопку Сохранить в области настройки проверки QG.
Сохраните весь конвейер — нажмите кнопку Сохранить в окне Редактирование конвейера.

Общие QG проверяются по правилу: пройден только в случае получения флага ok.
Если получен err, любой другой или не получен совсем, то QG считается проваленным.

Настройка проверки кастомных QG#

Для настройки проверки кастомного QG в открывшейся боковой панели "Настройки проверки Quality Gates":

Выберите кастомный QG из справочника:

Или добавьте новый QG. Для добавления нового QG (требует разрешения Управление Quality Gates) нажатием кнопки Добавить + откройте справочник Доступные Quality Gates проекта и добавьте QG в справочник
В отличие от общих QG, для кастомных QG можно изменить условия проверки: например, если в проекте есть флаг passed для QG, то нужно указать в DPM, считается ли QG пройденным/проваленным при получении такого флага
Сохраните настройку QG — нажмите кнопку Сохранить в области настройки проверки QG.
Сохраните весь конвейер — нажмите кнопку Сохранить в окне Редактирование конвейера.

Работа с QG-сервисами в DPM#

Обратите внимание
QG-сервисы создаются в рамках проекта в DPM.
Управление QG-сервисами требует наличия у пользователя разрешения Управление Quality Gates, разрешения выдает ответственный за проект.

При необходимости создать QG-сервисы в существующем проекте в DPM обратитесь к администратору проекта.
Для получения прав доступа (например, на просмотр опубликованных флагов и RN) обратитесь к администратору проекта. Обратите внимание, что для предоставления прав сначала необходимо войти в DPM.

Создать QG-сервис в проекте DPM#

Кто может выполнить действие: пользователь с ролью, для которой задано разрешение Управление Quality Gates.

Шаги:

Зайдите в свой проект в DPM и далее перейдите в подраздел Управление Quality Gates → Мои сервисы
В подразделе Мои сервисы нажмите кнопку Создать QG-сервис, в появившейся форме заполните поля: Название, Ссылка на проект в Nexus и нажмите кнопку Сохранить.
Поля Group ID, Artifact ID, Репозиторий Nexus и Конфиг. элемент (КЭ) заполняются автоматически.
В одном проекте не может быть несколько QG-сервисов с одинаковыми GAV-параметрами.

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

Просмотр истории опубликованных флагов#

Раздел История флагов аналогичен разделу флаги QGM, в нем собраны все флаги, которые публиковались по всем РК в сервисах данного проекта.

Для просмотра необходимо обладать ролью Просмотр Quality Gates или Управление Quality Gates, этом возможны варианты:

если роль определена на уровне проекта, то будет доступен просмотр всех флагов проекта по всем сервисам;
если роль определена на уровне приложения, то будет доступен просмотр только флагов по сервисам, входящим в приложение.

Зайдите в свой проект в DPM и далее перейдите в подраздел Управление Quality Gates → История флагов
В открывшемся окне можно увидеть историю опубликованных флагов по всем QG-сервисам, к которым у вас есть доступ в рамках текущего проекта.
Для удобства обработки данных используйте фильтр.

Цепочки фаз#

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

Создание и настройка цепочки фаз#

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

Для настройки критичности запуска блока (всей цепочки), а также настройки названия цепочки, нажмите на иконку "шестеренка" над ней

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

Переменные (параметры) в DPM#

Переменные описаны в файлах:

ContextParamProcessor содержит описание переменных с обращением вида ${};
ComplexParamProcessor содержит описание переменных фаз и QG;
OutOfContextParamProcessor содержит описание переменных с обращением вида #{} или this.

Использование переменных в DPM#

Запуск фазы по условию#

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

Пример:
${RC.phase.status.AB1} == "SUCCESS" — если фаза с ключом AB1 в статусе SUCCESS, то запустить фазу 2 иначе пропустить.

Примечание:
Проверка статуса фазы возможна только для Jenkins фаз и не доступна для ручных.

Иногда при таком обращении запуска не происходит. Узнать актуальное значение ${RC.phase.status.AB1} можно добавив в последующую фазу переменную со значением ${RC.phase.status.AB1}.

Передача значений переменных из Jenkins в DPM#

Для передачи значения переменной из Jenkins в DPM необходимо выполнить 3 условия:

Подключить в Jenkins библиотеку;
Настроить Jenkins Job Pipeline;
Настроить фазу конвейера.

Пример простейшей Jenkins Job для передачи значения параметра#

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

Создайте Jenkins pipeline.
Отметьте флаг.

Это — параметризованная сборка для русского интерфейса

либо This project is parameterized для англоязычного
Создайте строковые (String) параметры:
dpmPhaseID и textfromdpm

В Pipeline script скопируйте текст и введите адрес сервера:

@Library("DPMPipelineUtils@1.0") _ 

node("Linux_Default"){ 
stage('Set variable') { 
setDpmVarOnServer('<Адрес сервера>:8080', env.dpmPhaseID, "my_var", textfromdpm) 

} 
}

Настройка фазы конвейера#

В фазе конвейера:

Укажите URL созданной ранее Jenkins job;
Укажите 2 параметра, которые будут переданы в Jenkins:
- textfromdpm — в поле значение указывается текст, на который будет изменено значение переменной;
- dpmPhaseID — уникальный идентификатор фазы, в поле значения укажите ${externalKey}

Примечания:
Если в конвейере нет переменной my_var, она будет передана из Jenkins со значением textfromdpm
Если в конвейере есть переменная my_var, её значение будет заменено на textfromdpm
Переменная конвейера может быть указана при редактировании конвейера

Просмотреть историю значений переменных для конкретного РК можно в окне выбранного РК — выберите в меню Разделы пункт История переменных конвейера

Настройки переменных (виды параметров)#

Открытый и Безопасный параметры#

Как настроить:

Доступен для автоматических и ручных фаз.
Настраивается переключением на иконку открытого или закрытого замка.

На что влияет:
Видимость значения параметра для пользователя и в других фазах. Открытый параметр отображается всегда. Закрытый не отображается.

Простой и Запрашиваемый параметры#

Как настроить:

Доступен только для ручных и запускающихся по условию фаз.
Настраивается переключателем Запрашивать при запуске.

На что влияет:
Запрашиваемый параметр позволяет дополнительно:

возможность выбора из нескольких предопределённых значений;
запретить вводить своё значение;
настроить автоматический парсинг переменных;
возможность указать предопределенное значение при автоматическом запуске.

Запрашиваемый параметр с возможностью указать своё значение#

Как настроить:

Ввести как минимум 2 значения в запрашиваемом параметре;
Нажатием на иконку "шестеренка" проверить наличие установленного флажка Можно ввести своё значение

На что влияет: В примере пользователь сможет кроме предложенных 111111 и 2222 ввести и передать в jenkins любое свое значение, которое не предустановлено в настройках.
Также можно выбрать сразу несколько значений и добавить пользовательские, например передать в Jenkins 111111,2222, что-то еще.

Запрашиваемый параметр с выбором только предопределённых значений#

Как настроить:

Ввести как минимум 2 значения в запрашиваемом параметре;
Нажатием на иконку "шестеренка" снять отметку флажка Можно ввести своё значение

На что влияет:
В примере пользователь сможет выбрать только из предложенных 111111 и 2222 ввести или передать в jenkins пустой параметр. Ввести своё значение не получится.
Также можно выбрать сразу несколько значений, например передать в Jenkins 111111,2222 или 2222,111111.

Запрашиваемый параметр с выбором только одного значения из списка#

Как настроить:

Ввести как минимум 2 значения в запрашиваемом параметре;
Нажатием на иконку "шестеренка" снять флажок Можно ввести своё значение;
Снять флажок Можно выбрать несколько значений из списка

На что влияет:
В примере пользователь сможет выбрать только ОДНО из предложенных 111111 или 2222 либо передать в jenkins пустой параметр. Ввести своё значение не получится.

Дополнительные настройки парсинга запрашиваемых параметров#

В разделе Значения переменных можно указать дополнительные настройки:

Если в конвейере задана переменная param1 со значением ${version},XXX,YYY,ZZZ,${raoName}

Не разделять значения переменной#

Отобразит пользователю значение переменной с игнорированием разделителей (запятых)

Показать только разделённые значения#

Отобразит пользователю значения переменной разбитые по разделителям (разделители — это запятые)

Переиспользование значений переменных (пример)#

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

Пример:
В конвейере заданы 2 переменные param1 и param2.
Значения параметров, которые заданы в конвейере:
param1 = by_default_param1
param2 = by_default_0000000

Могут быть получены в любой фазе запросом значений этих параметров ${param1} и ${param2} соответственно.
Для получения значения из фазы существует формула: ${RC.phase.переменная.ключ_фазы}
В конвейере есть несколько фаз в которых используются данные переменные, причём в каждой фазе используется не значение по умолчанию, а своё собственное.
Для упрощения в первой фазе обе переменные принимают значения из единиц, во второй из двоек, в третьей из троек и тд.
Таким образом для первой фазы при нажатии на иконку "три точки" будет отображено:

А для третьей фазы:

Предположим, требуется получить значение переменных из фазы №1
Для param1 указываем ${RC.phase.param1.F1}
Для param2 указываем ${RC.phase.param2.F1}
Где F1 это ключ фазы этапа, его можно найти в настройках фазы этапа:

В DPM это будет выглядеть так:

Как получить значение этих параметров из фазы №3
Сначала найти ключ фазы №3 в настройках этапа выделив её:

Указать формулы вычисления параметров подставив значения в ${RC.phase.переменная.ключ_фазы}
Для param1 указываем ${RC.phase.param1.F3}
Для param2 указываем ${RC.phase.param2.F3}
Пример в DPM:

Переменные Приложения и Сервиса#

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

У Приложения и Сервиса пользователь может добавить свои переменные.
У Сервиса дополнительно есть встроенные переменные:

Переменная	Пример использования
groupId	#{КЛЮЧ_СЕРВИСА.groupId}
artifactId	#{КЛЮЧ_СЕРВИСА.artifactId}
nexusUrl	#{КЛЮЧ_СЕРВИСА.nexusUrl}
lastVersion	#{КЛЮЧ_СЕРВИСА.lastVersion}
lastVersionUrl	#{КЛЮЧ_СЕРВИСА.lastVersionUrl}
lastSuccessVersion	#{КЛЮЧ_СЕРВИСА.lastSuccessVersion.НАЗВАНИЕ_ЭТАПА.ПАРАМЕТР} #{DPM_RAO.lastSuccessVersion.ЭТАП.fullArtifactPath} — получить ссылку на скачивание дистрибутива, который успешно прошел ЭТАП позже всех (свежая успешная версия на этапе ЭТАП), в сервисе с ключом DPM_RAO

Использовать переменную можно несколькими способами:

#{DPM_RAO.lastSuccessVersion.ЭТАП.fullArtifactPath} — через определенный ключ сервиса, например, DPM_RAO;
#{thisRAO.lastSuccessVersion.ЭТАП.fullArtifactPath} — через зарезервированное слово thisRAO. Может быть использовано в глобальном конвейере, при этом вместо thisRAO будет подставлен ключ того сервиса, где запускается конвейер;
#{this.lastSuccessVersion.ЭТАП.fullArtifactPath} — через зарезервированное слово this.

Для использования в параметр запуска job при настройке конвейера требуется ввести #{КЛЮЧ_СЕРВИСА.groupID}

Создание переменной Приложения/Сервиса#

Зайти в окно Настройка Приложения/Сервиса;
Нажмите кнопку Добавить;
Заполните ключ (он будет использоваться при передаче в Jenkins) и значение;
Сохраните Приложение/Сервис.

Обратите внимание, что переменные могут быть двух типов: открытые и безопасные.
Значение безопасных переменных после сохранения не отображается. При вызове безопасных переменных в конвейере их значение также не будет отображено, но в Jenkins будет передано сохранённое значение.
При обновлении безопасных переменных с использованием Public API безопасные параметры изменят тип на открытые.
При получении значений безопасных переменных через Public API значения не выводятся.

Использование параметров#

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

#{thisRAO.var_name} — где переменная var_name добавлена в Сервисе, вместо thisRAO при запуске конвейера подставится ключ Сервиса;
#{thisFSS.var_name} — вместо thisFSS при запуске конвейера подставится ключ Приложения;
#{this.var_name} — значение переменной var_name будет браться сначала с уровня Сервиса, если на этом уровне переменная не задана, то возьмется с уровня Приложения.

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

#{thisRAO.test} будет передан в Jenkins и проверен в условиях запуска как #{thisRAO.test}.

В настройках конвейера перейдите к блоку параметров;
В значение параметра введите строку вида:

#{key.var_name}, где key — ключ Приложения/Сервиса, var_name — название переменной, заданное на Приложении/Сервисе
или
#{thisRAO.var_name} для переменной Сервиса или #{thisFSS.var_name} для Приложения

Список зарезервированных переменных:

Зарезервировано
'dpm', 'Dpm', 'DPM',
'lastversion', 'lastVersion', 'LastVersion', 'LASTVERSION',
'rc', 'RC',
'global', 'Global',
'const', 'Const',
'rao', 'Rao', 'RAO',
'as', 'As', 'AS',
'fss', 'Fss', 'FSS',
'pipeline', 'Pipeline', 'PIPELINE',
'asname', 'asName', 'AsName', 'ASNAME',
'fssname', 'fssName', 'FssName', 'FSSNAME',
'raoname', 'raoName', 'RaoName', 'RAONAME',
'groupid', 'groupId', 'GroupId', 'GROUPID',
'artifactid', 'artifactId', 'ArtifactId', 'ARTIFACTID',
'version', 'Version', 'VERSION',
'repositoryname', 'RepositoryName', 'RepositoryName', 'REPOSITORYNAME',
'externalkey', 'externalKey', 'ExternalKey', 'EXTERNALKEY',
'nexusnrl', 'nexusUrl', 'NexusUrl', 'NEXUSURL',
'nexusurl', 'nexusUrl', 'NexusUrl', 'NEXUSURL',
'artifactpath', 'artifactPath', 'ArtifactPath', 'ARTIFACTPATH',
'extension', 'Extension', 'EXTENSION',
'classifier', 'Classifier', 'CLASSIFIER',
'fullartifactpath', 'fullartifactPath', 'fullArtifactPath', 'FullArtifactPath', 'FULLARTIFACTPATH',
'this', 'This', 'THIS',
'RN', 'rn',

Ключ Сервиса отображается около названия сервиса:

Пример заполненного параметра (после ввода "#{key" DPM подскажет имеющийся параметр):

Переменные Релиз-кандидата (запуска конвейера)#

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

Все переменные в DPM хранятся как строки.
Если переменная конвейера var1 имеет значение true, то обратиться к ней можно через ${var1}=="true"

Переменные дистрибутива#

В значениях параметра можно указать:

Макрос	Что передастся в job
${asName}	Проект
${fssName}	Приложение
${fssKey}	Ключ приложения
${raoName}	Сервис
${raoKey}	Ключ сервиса
${stepName}	Название этапа
${groupId}	groupId артефакта в Nexus
${artifactId}	artifactId артефакта в Nexus
${imageName}	Имя образа
${tag}	Тэг образа
${phaseLevel}	Уровень фазы в этапе (0=первая строка, 1 вторая строка, 2 третья и т.д.)
${version}	version артефакта в Nexus
${dpmVersion}	Версия дистрибутива, отображаемая в DPM (настроить можно при редактировании Сервиса в поле Шаблон версии)
${dpmRelease}	Название набора дистрибутивов, по которым они группируются в Сервисе (настроить можно при редактировании Сервиса в поле Шаблон релиза)
${repositoryName}	Репозиторий Nexus
${artifactPath}	Путь до артефакта в настройке job
${nexusUrl}	url инструмента (nexus external app) из админки, который указан в Сервисе в поле Nexus
${fullArtifactPath}	Адрес дистрибутива с классифайером и расширением для Nexus
${pullImagePath}	Адрес дистрибутива с классифайером и расширением для Registry
${baseArtifactPath}	Возвращает структуру ${repositoryName}/${groupid}/${artifactid}/${version}/${artifactid}${version}${classifier}.${extension}
${imagePath}	Местоположение дистрибутива Registry
${extension}	Расширение дистрибутива в Nexus (задается в настройках Сервиса)
${classifier}	Классифайер дистрибутива в Nexus (задается в настройках Сервиса).
${lastJobActor}	Информация о пользователе, подтвердившем запуск в формате "User: Фамилия Имя Отчество. Login: доменный логин. Email: доменная почта"
${externalKey}	ID фазы, в которой был запущен job
${dpmSubRelease}	Название, по которому группируются релизы в DPM (поле Группа релизов при настройке сервиса). Если это поле не заполнено в настройках сервиса (пункт группа релизов) то вернётся null
${creationDate}	Дата создания РК DPM (обнаружения в Nexus или создания через CI). (unix timestamp в ms)
${dpmRcUrl}	Вернёт ссылку для адресной строки браузера по которой можно перейти к РК (в формате сервер/ключ_сервиса/РК)
${packageFullArtifactPath}	Список артефактов в поставках
${packageFullArtifactVersions}	Список версий в поставках

Переменные из контекста запущенного конвейера#

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

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

Переменная конвейера	Значение переменной
${RC.phase.buildResult.КЛЮЧ_ФАЗЫ}	Статус выполнения job. Если job не была выполнена на момент использования переменной, значение null. Возможные значения: ABORTED FAILURE NOT_BUILT SUCCESS UNSTABLE
${RC.phase.buildDescription.КЛЮЧ_ФАЗЫ}	Описание конкретного запуска Jenkins job (currentBuild.description), запущенного из фазы. Этот параметр можно использовать для передачи данных из job в конвейер без использования специальной библиотеки.
${RC.phase.dpmStartTime.КЛЮЧ_ФАЗЫ}	Время в формате Unix-time запуска фазы конвейера (момент, когда процесс выполнения конвейера дошел до указанной фазы). Если фаза не запустилась на момент использования переменной, значение null.
${RC.phase.dpmEndTime.КЛЮЧ_ФАЗЫ}	Время в формате Unix-time завершения фазы конвейера (когда пройдена валидация). Если фаза не завершилась на момент использования переменной, значение null.
${RC.phase.dpmDuration.КЛЮЧ_ФАЗЫ}	Длительность в миллисекундах выполнения фазы (включая время простоя до начала техокна, время ожидания подтверждения пользователя и т.д.). Если фаза не завершилась на момент использования переменной, значение null.
${RC.phase.jobStartTime.КЛЮЧ_ФАЗЫ}	Время в формате Unix-time запуска Jenkins job из DPM (момент, когда DPM отправил запрос в Jenkins на постановку задачи в очередь). Если job не запустилась на момент использования переменной, значение null.
${RC.phase.jobEndTime.КЛЮЧ_ФАЗЫ}	Время в формате Unix-time завершения Jenkins job (момент, когда DPM получил статус job). Если job не завершилась на момент использования переменной, значение null.
${RC.phase.jobDuration.КЛЮЧ_ФАЗЫ}	Длительность в миллисекундах выполнения Jenkins job (приближение к "чистому" выполнения job, сюда входит время, пока Jenkins ставил задачу в очередь). Если job не завершилась на момент использования переменной, значение null.
${RC.phase.buildUrl.КЛЮЧ_ФАЗЫ}	Ссылка на номер билда в Jenkins. Если Jenkins не поставил в очередь задачу на момент использования переменной, значение null.
${RC.phase.status.КЛЮЧ_ФАЗЫ}	Статус фазы. Возможные значения: CANCELED — Запуск отклонен пользователем FAIL — Фаза завершена не успешно (после пользовательского или автоматического подтверждения Jenkins build result) SUCCESS — Фаза завершилась успешно (после подтверждения) ERROR — Ошибка запуска SCHEDULED — Запланирован запуск MANUAL_RUN — Фаза на подтверждении запуска пользователем MANUAL_VALIDATION — Фаза на подтверждении Jenkins build result пользователем IN_PROGRESS — В процессе опроса Jenkins CREATED — Фаза еще не запускалась INTERRUPTED — Прервано выполнение SKIPPED — Фаза пропущена. Подробнее в разделе "Условия запуска фаз" MANUAL_PROCESS — Ручная фаза (без вызова Jenkins) в процессе выполнения

Пример использования#

Проверка значений параметров запуска job#

Для ручных фаз#

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

Важно помнить, что до момента запуска задачи значения могут измениться (например, если их изменили на уровне сервиса или приложения).
В таком случае в Jenkins будет отправлено другое значение, которое можно будет просмотреть нажатием иконки "три точки".
Аналогично автоматическим фазам ниже.

Для автоматических фаз#

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

Комбинирование переменных#

Переменные можно комбинировать с произвольным текстом и другими переменными, например, следующий пример валидный:
${asName}/Мой текст/${RC.phase.buildUrl.D#0}

Переменные конвейера. Обновление значений из Jenkins#

Использование переменных в качестве параметров#

При конфигурации Jenkins Job в разделе параметров можно использовать системные и пользовательские переменные окружения. DPM использует функционал String Literals в реализации Apache Commons [StrSubstitutors].
Для передачи значения переменной в Jenkins, достаточно экранировать название переменной специальными мета-символами, например так: ${НАЗВАНИЕ_ПЕРЕМЕННОЙ}.
На картинке ниже приведен пример корректно заполненной Jenkins Job, которой в качестве параметров будут переданы соответствующие значения.

Пользовательские переменные DPM#

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

На странице настройки конвейера добавьте параметр

Для обновления переменной в DPM из Jenkins job — в параметрах job передайте встроенную переменную ${externalKey};
Как настроить job, которая сможет обновить значение перемой, описано в разделе "Задать переменную в DPM";
Далее вызывайте такую переменную несколькими способами:

Способ обратиться к значению переменной	Пример
${НАЗВАНИЕ_ПЕРЕМЕННОЙ.НАЗВАНИЕ_ЭТАПА.КЛЮЧ_ФАЗЫ}	${result.ST.D#0} передастся значение, обновленное в текущем конвейере фазой с ключом D#0 этапа ST.
${НАЗВАНИЕ_ПЕРЕМЕННОЙ.НАЗВАНИЕ_ЭТАПА}	${result.ST} передастся значение, последнее обновленное фазой этапа ST.
${НАЗВАНИЕ_ПЕРЕМЕННОЙ}	${result} передастся последнее обновленное значение (с любого этапа/фазы).

Технические ограничения:
На данный момент в названиях переменных можно использовать следующие символы: A-Za-zА-Яа-яЁё0-9_ (латинские и русские буквы, цифры, нижнее подчеркивание).
Для названия ключей фазы, дополнительно можно использовать символ решетки #.
Однако, использовать русские символы в названиях переменных не рекомендуется — данный функционал был реализован только в целях обратной совместимости.

Пример
Есть две фазы в степе DEV одна называется Deploy1 (и ее ключ Dpl#1), вторая Deploy2 (и ее ключ Dpl#2). В рамках фазы с ключом Dpl#1 вы заполняете из Jenkins job переменную result значением A1, далее в следующей фазе с ключом Dpl#2 вы заполняете ту же переменную result значением B2. Теперь во все последующие фазы всех этапов можно передавать переменные:
${result.DEV.Dpl#1}=A1
${result.DEV.Dpl#2}=B2
${result.DEV}=B2
${result}=B2
Далее решено заполнить эту переменную еще раз в следующем этапе под названием ST в фазе Deploy1 (с ключом Dpl#3) и передали в нее значение C3. Теперь:
${result.ST.Dpl#3}=C3
${result.ST}=C3
${result.DEV}=B2
${result}=C3

Управление установкой дистрибутивов#

Для перехода к настройке управления установкой:

Находясь на экране Сервиса, выберите вкладку Управление установкой.

На экране будут отображены этапы и релиз-кандидаты, ожидающие прохождения соответствующих этапов.

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

Откроется панель "Порядок установки"

Для настройки порядка прохождения этапов перейдите по ссылке "Редактировать", отображаемой в строке соответствующего этапа (данная настройка требует наличия у пользователя ролей: Управление сервисами и синхронизацией с Nexus + Настройки конвейера)

В строке редактируемого этапа будет доступно изменение количества одновременно устанавливаемых РК и правила приоритизации РК

Устанавливается одновременно — задаёт количество одновременно выполняемых этапов от разных релиз-кандидатов.
Также можно установить флаг "Не ограничено" — в этом случае снимаются ограничения на одновременный запуск этого этапа в текущем Сервисе.
По правилу — определяет приоритет запуска одного и того же этапа относительно разных релиз-кандидатов:
- Первым пришёл — первым установился;
- Последним пришёл — первым установился;
- Новый прерывает установку предыдущего.

Архивация сервисов#

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

Действия для архивации сервиса#

Нажмите иконку "три точки", отображаемую в правом верхнем углу соответствующего объекта, и во всплывающем меню выберите Архивировать

Подтвердите действие нажатием Архивировать Сервис

Если в этот момент на Сервисе были активные релиз-кандидаты, то после архивации Сервиса их прохождение по конвейерам остановится.

Расположение архивных сервисов#

Все заархивированные Сервисы можно найти перейдя на вкладку Архив со списка активных Сервисов

Восстановление объекта из архива#

Для восстановления из архива:

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

Подтвердите восстановление нажатием Восстановить Сервис

Восстановленный объект появится в общем списке.

Технологические окна#

В DPM существует возможность задать для этапов промежутки времени (называемые технологическими окнами), на протяжении которых допускается запускать процессы этапа, могущие повлиять на действия пользователей и т.п. — например, процессы развертывания.
Если Технологические окна не настроены, значит запуск таких процессов возможен в любой момент времени.
Контроль осуществляется только по настроенным параметрам. Это значит, что если технологические окна настроены на определённый этап, например ПСИ, но не настроены для ИФТ, то время запуска этапа ИФТ не будет контролироваться.
Технологические окна могут быть настроены для этапов на уровне проекта, приложения или сервиса. В текущей реализации технологические окна влияют только на Jenkins фазы.

Индикация наличия технологических окон#

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

Настойка технологических окон#

Перейдите к Сервису, для которого настраивается техокно, и нажмите меню Настройки сервиса → Техокна

Выберите Создать расписание

Выберите этап, время технологического окна и в зависимости от настроек Проекта нажмите кнопку Сохранить / Согласовать.
- Если для этапа появляется кнопка Сохранить, то больше действий не требуется.
- Если для этапа появляется кнопка Согласовать, то технологическое окно должно быть согласовано администратором Проекта.
  Данный параметр зависит от общих настроек DPM (устанавливается администратором Сервиса).
В примере ниже:
- Техокна этапов DEV и IFT не требуют валидации, поэтому сразу после настройки активны (находятся в статусе Подтвердил). Для того чтобы запуск этих этапов был возможен только в периоды, указанные в технологических окнах, требуется:
  - только применить это расписание.
- Техокно этапа UAT имеет статус На рассмотрении — т.к. на уровне общих настроек DPM задано согласование технологических окон для этого этапа администратором Проекта. Сейчас технологическое окно НЕ активно, указанные параметры не применяются к этапу и запуск этого этапа возможен в любое время. Для того чтобы запуск этих этапов был возможен только в периоды, указанные в технологических окнах, требуется:
  1. согласовать это технологическое окно — согласует администратор Проекта;
  2. применить это расписание.

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

Настройка валидации техокон этапов администратором Проекта#

Для настройки валидации технологических окон по каждому из этапов:

Перейдите в общие настройки DPM нажатием на иконку "гаечный ключ", отображаемую в нижней части левой боковой динамической панели;
В открывшемся меню общих настроек DPM выберите Этапы конвейера

Перейдите по ссылке Редактировать, отображаемую в строке изменяемого этапа;
Для этапов, которые требуют валидации устанавливается флаг Валидация

Сохраните изменения.

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

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

Нажмите на иконку "гаечный ключ", отображаемую в нижней части левой боковой динамической панели;
В открывшемся меню общих настроек DPM выберите Управление техокнами
Выберите группы задач в соответствующей вкладке

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

Группы пользователей#

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

Создание групп пользователей#

Для создания групп(ы) пользователей:

Перейдите в настройки проекта — находясь в разделе Все проекты, перейдите по ссылке Редактировать, отображаемой в строке настраиваемого проекта
Перейдите на вкладку Группы
Нажмите кнопку Добавить группу

В открывшейся панели заполните поля:
- Название группы — будет фигурировать в дальнейших настройках;
- Описание — комментарий для понимания;
- Добавить участников — для добавления участников начните вводить имена пользователей.

Нажмите кнопку Сохранить в нижней части экрана.

Установка ролей группам (выдача прав группам)#

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

Установка ролей групп на уровне Проекта#

Перейдите в настройки проекта — находясь в разделе Все проекты, перейдите по ссылке Редактировать, отображаемой в строке настраиваемого проекта
Перейдите на вкладку Роли/Доступы
Перейдите по ссылке Изменить, отображаемой в строке той роли, которую требуется предоставить группе
В открывшейся панели кликните мышью поле Пользователи и выберите из выпадающего списка группы, которым следует предоставить редактируемую роль

Нажмите кнопку Сохранить.

Установка ролей групп на уровне Приложения#

Перейдите в настройки приложения — находясь в списке приложений проекта, перейдите по ссылке Редактировать, отображаемой в строке настраиваемого приложения
Перейдите на вкладку Роли/Доступы
Перейдите по ссылке Изменить, отображаемой в строке той роли, которую требуется предоставить группе
В открывшейся панели кликните мышью поле Пользователи и выберите из выпадающего списка группы, которым следует предоставить редактируемую роль

Нажмите кнопку Сохранить.

Указание групп в ответственных#

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

Наивысший приоритет имеют пользователи и группы, которые указаны на уровне фазы конвейера;
Если на уровне фазы конвейера не указаны ответственные, то осуществляется поиск на уровне ответственных за этап Приложения;
Если нет ответственных за фазу и не настроены ответственные за этап, DPM использует настройки Приложения (пункт Ответственный в параметрах Приложения).

Указание группы в ответственных за фазу#

При настройке фазы конвейера выберите пункт Добавить в разделе Ответственные за фазу

Установите курсор в поле. Будет отображен список возможных групп. Выберите щелчком нужные

Укажите стратегию подтверждения;
Сохраните изменения.

Указание группы в ответственных за этап#

Выберите пункт Ответственные за этап находясь на экране Приложения

Войдите в настройки нужного этапа нажатием соответствующей кнопки в правой части экрана. В зависимости от текущих настроек кнопка может называться:
Настроить (если ответственные не указаны) или Редактировать (если за этап уже указаны ответственные)

Установите курсор в поле. Будет отображен список возможных групп. Выберите щелчком нужные

Укажите стратегию подтверждения;
Сохраните изменения.

Указание ответственных за Приложение#

Группу нельзя указать в ответственных за всё Приложение, ответственным всегда является один пользователь.

Для указания ответственного перейдите в окно Настройка приложения нажатием кнопки "Настройки", отображаемой в правом верхнем углу окна приложения.

Укажите в соответствующем пункте нужного пользователя

Сохраните изменения.

Управление доступом на основе ролей#

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

глобального администратора;
проекта;
приложения.

Настройка ролей на уровне глобального администратора#

В общих настройках DPM пользователям могут быть установлены следующие права:

глобальный администратор;
администратор тех. окон;
аудитор;
администратор ролей.

Для настройки:

Перейдите в общие настройки нажатием на иконку "гаечный ключ", отображаемую в нижней части левой боковой динамической панели (доступна пользователям с повышенными правами);
В открывшемся меню общих настроек DPM выберите Роли и разрешения
Нажмите кнопку Добавить роль (если требуется создание новой роли) или Изменить (если требуется отредактировать существующие настройки)

Укажите название роли, пользователей и предоставляемые разрешения:

Сохраните изменения нажатием кнопки Сохранить.

Настройка ролей на уровне Проекта#

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

просмотр проекта и дочерних объектов (приложений, сервисов, РК);
управление конфигурацией конвейеров (создание, редактирование, удаление, импорт и экспорт);
управление движением конвейеров (запуск, пауза, останов, смена);
управление тех. окнами;
управление ролями;
управление группами;
переопределение ответственных в конвейере (без редактирования конвейера);
управление ответственными за этап приложения;
управление сервисами;
управление профилями сервисов;
пропуск м36;
создание приложений и сервисов в проекте;
изменение настроек проекта, приложения, сервиса;
перезапуск этапов;
перезапуск фаз.

Для настройки:

Перейдите в настройки проекта — находясь в разделе Все проекты, перейдите по ссылке Редактировать, отображаемой в строке настраиваемого проекта
Перейдите на вкладку Роли и Доступы
Нажмите кнопку Добавить роль
Укажите название, пользователей и права, которые будут выданы пользователям

Сохранить изменения нажатием кнопки Сохранить.

Настройка ролей на уровне Приложения#

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

управление конвейерами;
управление движением конвейеров;
управление тех. окнами;
управление ролями;
переопределение ответственных в конвейере (без редактирования конвейера);
переопределение ответственных за этап приложения;
управление сервисами;
управление профилями сервисов;
пропуск м36;
изменение ответственного за приложение;
создание и копирование сервисов;
изменение настроек приложения и сервиса;
перезапуск фаз;
перезапуск этапов.

Для настройки:

Перейдите в настройки приложения — находясь в списке приложений проекта, перейдите по ссылке Редактировать, отображаемой в строке настраиваемого приложения
Перейдите на вкладку Роли и Доступы
Нажмите кнопку Добавить роль
Укажите название, пользователей и права, которые будут выданы пользователям

Сохранить изменения нажатием кнопки Сохранить.
На вкладке Роли/Доступы установить пользователям, которые будут работать с поставками, роль Управление поставками

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

Настройки конвейера поставки#

Для создания конвейера поставок

Перейдите в Настройки поставок → Конвейеры

Нажмите кнопку Создать новый

Дальнейшее создание конвейера аналогично созданию конвейера на уровне Проекта/Приложения/Сервиса.
Отличия конвейера поставки от конвейера Проекта/Приложения/Сервиса:

Нельзя добавить проверку QG в этапах. Все добавленные проверки будут удалены.
Наличие тиражируемых фаз.
Некоторые фазы нельзя запускать без тиражирования QG, QGM, М36. Поскольку они привязаны к РК сервиса.
ФПД фазы нельзя запустить в конвейере поставок.

Отметить дистрибутив готовым к поставке#

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

Отметить Релиз-Кандидат готовым к поставке вручную#

Находясь на экране Релиз-кандидата:

Выберите Не готов к поставке → Пометить готовым к поставке

На Релиз-кандидате появится лейбл Готов к поставке

Отметить Релиз-Кандидат готовым к поставке через API#

Для отметки Релиз-кандидата готовым к поставке можно использовать Public API.
Пример запроса

Результат аналогичен отметке в ручном режиме

Отметить Релиз-Кандидат готовым к поставке при создании поставочного конвейера#

Нажмите кнопку Найти и добавить вручную на странице поставок

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

Нажмите Добавить в список готовых.

Отметить Релиз-Кандидат готовым к поставке с помощью сервисной фазы#

В обычном конвейере добавить сервисную фазу Готовность к поставке

Запуск дистрибутивов по общему (поставочному) конвейеру#

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

Соберите набор дистрибутивов из списка готовых к поставке отметив их флажками

Нажмите кнопку Создать поставку

Укажите название поставки, после чего будет разблокирована кнопка Далее к выбору конвейера

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

Нажмите кнопку Запустить поставку
После этого на вкладке Активные поставки появится один общий конвейер, по которому будут запущены все дистрибутивы этой поставки.

Работа в конвейере поставок#

В отличие от конвейера Проекта/ Приложения/ Сервиса в поставочных конвейерах присутствуют бандл фазы (тиражируемые фазы).
Пример этапа с тиражируемой фазой:

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

Старт тиражируемой фазы с ручным запуском#

Нажмите кнопку Запустить под фазой

При необходимости укажите параметры запуска;
Фаза будет скопирована для каждого РК входящего в поставку и запущена по очереди

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

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

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

Нажмите на иконку "три точки", отображаемую напротив нужной фазы:

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

Либо, в случае ожидания действий пользователя:

Переменные страницы поставок#

Помимо стандартных переменных для фазы поставки доступны дополнительные:
${phaseLevel} — Данная переменная полезна для тиражируемых фаз. Возвращает число в соответствии с очерёдностью запуска. Первая фаза вернёт 0;
${packageFullArtifactPath} — возвращает список ссылок на дистрибутивы поставки через разделитель ';';
${packageFullArtifactVersions} — возвращает список GroupID=Version дистрибутивов поставки через разделитель ';'.

Личный кабинет (профиль пользователя)#

Личный кабинет позволяет:

Самостоятельно актуализировать почтовый ящик и включать/отключать рассылку;
Хранить токены для доступа к разным стендам Jenkins;
Получать информацию о том в каких группах состоит пользователь;
Создавать токены для доступа к DPM из Jenkins не используя пароль.

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

Вкладка "Я в группах"#

Вкладка позволяет узнать о группах, в которые включен пользователь.

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

Личный токен (Создать токен DPM для авторизации из Jenkins)#

Преимущества использования токена:

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

Личный кабинет DPM позволяет хранить пароли и токены, но мы рекомендуем использовать токены.

Значением токена является GUID — статистически уникальный 128-битный идентификатор, записываемый в виде строки из 32 шестнадцатеричных цифр, разбитой на группы дефисами. Токен генерируется вызовом метода генерации случайного UUID UUID.getrundomUUID класса java.util.uuid. Токен формируется непосредственно внутри компонента.

Создание личного токена в DPM#

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

Выберите Создать токен

Задайте имя токена и нажать Сгенерировать

Скопируйте токен

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

Инструкция как использовать созданный токен для авторизации из Jenkins описана в разделе "Подключение с использованием Public API"

Создание токенов Jenkins и настройка профиля для авторизации из DPM#

Создание токенов в Jenkins#

В Jenkins нажмите на свое ФИО в правом верхнем углу

В левом меню перейдите к пункту Настроить

Нажмите кнопку Add new token

Задайте имя токена и нажмите кнопку Generate

Скопируйте сгенерированный токен кликом по иконке

Сохранение личного токена от Jenkins в DPM для запуска задач#

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

Выберите в списке стенд, на котором был сгенерирован токен, вставьте скопированное значение, нажмите Сохранить

Использование сохранённого в DPM токена из Jenkins при запуске задач или изменение установленный по умолчанию#

Токен сохранённый в профиле пользователя может быть использован только при ручном типе запуска.
Учётные данные, из-под которых DPM запускает задачу, зависят от типа задачи и настройки проекта:

При автоматическом запуске фазы токен из личного кабинета не может быть использован. DPM ищет учётные данные в порядке: В фазе → На сервисе → В приложении → В проекте → Глобальная учётная запись;
Если в фазе конвейера прописаны логин и пароль, то независимо от типа запуска в первую очередь будет использована эта учётная запись, но при ручном типе запуска её можно изменить;
При ручном типе запуска (если в фазе не прописаны учётные данные) в первую очередь используются логин и пароль из профиля подтвердившего запуск пользователя. Кроме того, можно самостоятельно указать логин и пароль из-под которых будет запущена задача. Если в профиле нет подходящих токенов и ничего не задано явно, будет произведён поиск: На сервисе → В приложении → В проекте → Глобальная учётная запись.

Глобальная учетная запись имеет ограниченный доступ к стендам и скриптам. Запуск из-под неё возможен не всегда.
Пример ручного запуска, когда в фазе прописаны логин пароль. Для использования сохранённого в профиле пароля следует перезапустить фазу с удалением учетных данных фазы или указать их самостоятельно нажав ИЗМЕНИТЬ.

Пример ручного запуска, когда в фазе нет указанных явно логина и пароля. Фаза будет запущена с использованием логина и пароля от текущего стенда из профиля (если такая пара была сохранена).
Если в профиле нет учётных данных или требуется указать другие учетные данные нажмите кнопку ИЗМЕНИТЬ.

Дополнительное меню Релиз-Кандидата#

Меню Релиз-Кандидата может быть вызвано кликом по ссылке Дополнительно

Подписаться на РК

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

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

О релиз-кандидате

Позволяет увидеть состав Релиз-Кандидата.

Данная информация собирается из файла release-notes. Если файл отсутствует, то проверяется pom.xml
Для добавления задачи в список:

Выполнить запрос issueKey = номер_задачи, например issueKey = DPMT-777 и нажмите enter

Отметьте нужные задачи и нажмите кнопку Добавить задачи в список

Обновить мета-данные

Переопрашивает файл Release-Notes

История

Здесь содержится история движения Релиз-Кандидата по конвейеру, пример истории приведён ниже:

Переменные конвейера

Раздел позволяет отслеживать значения переменных конвейера и их историю изменения в фазах

Управление Release Notes проекта#

Кнопка перехода в раздел Release Notes расположена в правом верхнем углу главного окна проекта:

Назначить учетную запись для доступа к Release Notes можно в разделе Доступы к внешним ресурсам настроек проекта:

Задать/переопределить ТУЗ на чтение/запись Release Notes#

Кто может выполнить действие:

пользователь с ролью, для которой задано разрешение Общая настройка проекта (как правило, роль Администратор проекта);
см. раздел "Задать/переопределить пользовательские права".

Зайдите в свой проект в DPM и далее в настройки проекта → в закладку Доступы к внешним ресурсам → подраздел Release Notes → перейдите по ссылке Задать/Изменить:

В открывшейся форме укажите ТУЗ на чтение и запись RN и нажмите кнопку Сохранить

Задать/переопределить пользовательские права#

Кто может выполнить действие:

ответственный за проект (указывается в заявке на создание проекта в DPM);
пользователь с ролью, для которой задано разрешение Общая настройка проекта (как правило, роль Администратор проекта).

Зайдите в свой проект в DPM и далее в настройки проекта → в закладку Роли/Доступы → нажмите кнопку Изменить напротив той роли, в которую необходимо добавить разрешения.

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

Разрешение Управление Quality Gates — создание новых QG-сервисов, создание кастомных флагов на уровне проекта, определение прав для ТУЗ на чтение и запись флагов, просмотр истории опубликованных флагов и RN.
Разрешение Просмотр Quality Gates — просмотр истории опубликованных флагов, просмотр доступных QG и заданных для них ТУЗ (без возможности внесения изменений).
Разрешение Просмотр Release Notes — просмотр истории опубликованных RN.

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

Часто встречающиеся проблемы и пути их устранения#

Типовые проблемы не выявлены.

В случаях сбоев диагностику ситуации следует начинать с проверок:

Подключения клиента (компьютера пользователя) к сети;
Доступности сервера DPM;
В случае неудачной аутентификации — корректности логина/пароля при входе в DPM;
В случае ошибок обращения к Jenkins — корректности логина/пароля Jenkins, указываемых в профиле пользователя DPM для соответствующего экземпляра Jenkins.