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

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

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

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

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

Проекты, приложения, сервисы — Создание и настройка#

Проекты#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения#

Приложения служат для группировки сервисов.
На уровне приложения можно настроить роли пользователей, конвейеры и учетные данные для доступа ко внешним сервисам (Jenkins, Nexus и др.), которые будут применяться ко всем сервисам только этого приложения.
Учетные данные для доступа ко внешним сервисам, заданные на уровне приложения, более приоритетны, чем заданные на уровне проекта.

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

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

Перейдите на страницу проекта и нажмите кнопку Создать приложение, расположенную в верхней правой области.
Заполните обязательные параметры: наименование, уникальный ключ, ответственный. Данные параметры могут быть изменены после создания сервиса:
- Наименование (обязательное) — имя Приложения, отображаемое пользователю (потом можно поменять в любой момент);
- Ключ (обязательное) — уникальный адрес Приложения в пределах DPM (потом можно поменять в любой момент);
- Ответственный (обязательное) — пользователь, ответственный за приложение (потом можно поменять в любой момент).

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

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

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

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

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

Сервисы#

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

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

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

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

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

В открывшейся вкладке выберите тип настраиваемого репозитория:
- Nexus2;
- 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 и для них будет доступен ручной выбор конвейера.

Оперативная синхронизация сервиса выполняется посредством принятия web-hooks от Nexus, отправляемых им в момент записи дистрибутива в Nexus непосредственно после создания сервиса, для получения списка уже существующих РК (дистрибутивов, созданных в Nexus до момента создания сервиса в DPM) – в списке РК этого сервиса можно подать команду ручной синхронизации - «Обновить вручную».

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

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

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

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

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

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

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

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

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

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

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

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

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

Список релиз-кандидатов (РК)#

О релиз-кандидате#

Позволяет увидеть состав Релиз-Кандидата.

Данная информация собирается из файла release-notes. Если файл отсутствует, то проверяется pom.xml.

Для добавления задачи в список выполните следующее:

Выполнить запрос issueKey = номер_задачи, например, issueKey = DPMT-777, и нажмите enter.
Отметьте нужные задачи и нажмите кнопку Добавить задачи в список:

История конвейера#

Здесь содержится история движения Релиз-Кандидата по конвейеру, пример истории приведен ниже:

Темная тема#

Для страницы Релиз-Кандидата можно включить "темную тему" пользовательского интерфейса c помощью переключателя, расположенного в правой части экрана:

Формат отображения конвейера#

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

Горизонтальный вид#

Вертикальный вид#

Масштабирование конвейера#

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

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

По умолчанию выбран статичный режим:

Меню "Разделы" Релиз-Кандидата#

Меню Разделы Релиз-Кандидата может быть вызвано нажатием кнопки Разделы в правом верхнем углу экрана:

Release Notes#

Позволяет посмотреть опубликованные Release Notes и историю изменений:

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

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

Подписки#

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

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

Обновить данные#

Переопрашивает файл Release-Notes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данная операция требует разрешения "Управление сервисами и синхронизацией с Nexus".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка полномочий пользователя в DPM#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При настройке фазы конвейера выберите пункт Добавить в разделе Ответственные за фазу:
Установите курсор в поле. Будет отображен список возможных групп. Выберите щелчком нужные:
Укажите стратегию подтверждения;
Сохраните изменения.

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

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

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

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

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

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

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

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

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

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

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

Назначение ответственного за приложения;
Просмотр проекта и дочерних объектов;
Общая настройка проекта;
Просмотр Quality Gates;
Просмотр Release Notes;
Настройка профилей конвейеров;
Управление техокнами;
Назначение ответственных за фазу;
Управление Quality Gates;
Управление сервисами и синхронизацией с Nexus;
Переопределение параметров конвейера;
Подтверждение М36;
Пропустить шаг или сделать опциональным;
Настройка ответственных за этап;
Управление группами;
Перезапуск фаз;
Создание приложений;
Управление конвейером релиз-кандидата;
Управление ролями;
Удаление приложений;
Перезапуск этапов;
Настройки конвейера;
Управление поставками.

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

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

Роль "Внешние пользователи проекта"#

На уровне проекта пользователи могут быть добавлены в роль "Внешние пользователи проекта".

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

Для роли заданы следующие права:

Настройка ответственных за этап;
Перезапуск фаз;
Просмотр проекта и дочерних объектов;
Управление конвейером релиз-кандидата;
Перезапуск этапов;
Настройка профилей конвейеров;
Просмотр Quality Gates;
Просмотр Release Notes;
Назначение ответственных за фазу;
Пропустить шаг или сделать опциональным.

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

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

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

Перейдите в настройки проекта — находясь в разделе Все проекты, перейдите по ссылке Редактировать, отображаемой в строке настраиваемого проекта.
Перейдите на вкладку Роли и Доступы.
Нажмите кнопку Изменить в строке с ролью "Внешние пользователи проекта".
Укажите пользователей, которым будет присвоена данная роль. В списке отображаются только те пользователи, у которых был ранее задан параметр "isExternalUser": true в таблице users в БД (по умолчанию false):
Сохраните изменения нажатием кнопки Сохранить.

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

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

Просмотр приложения и дочерних сервисов;
Настройка профилей конвейеров;
Просмотр Quality Gates;
Управление техокнами;
Назначение ответственного за приложения;
Назначение ответственных за фазу;
Общие настройки приложений;
Создание сервисов;
Управление сервисами и синхронизацией с Nexus;
Переопределение параметров конвейера;
Подтверждение М36;
Пропустить шаг или сделать опциональным;
Настройка ответственных за этап;
Перезапуск фаз;
Просмотр Release Notes;
Управление конвейером релиз-кандидата;
Управление ролями;
Удаление приложений;
Перезапуск этапов;
Настройки конвейера.

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

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

Управление 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.
При необходимости, создайте новую роль, нажав кнопку Добавить роль, и задайте в ней необходимые разрешения и пользователей.

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

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

Типы 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Указание логина/пароля Jenkins job на уровне отдельной фазы конвейера#

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

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

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

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

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 = проверка пройдена, а ок = проверка провалена).

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

Не все стандартные флаги доступны для самостоятельной публикации пользователем через DPM, а также не все проверяются в QGM.
Это связано с тем, что некоторые флаги представляют собой проверки в отдельных сервисах по ряду параметров, их самостоятельная публикация невозможна т.к. по сути является нарушением процедуры проверки, принятой в организации.
Например, флаги OSS и SAST.
Флаг SAST — проставляется автоматически, если SAST сканирование подключено в сборочной job — именно его результат отправляется в 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 в рамках проекта:

На странице проекта DPM нажмите кнопку Разделы в правом верхнем углу экрана и далее в контекстном меню выберите Управление 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.

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

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

Настройка проверки 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 проверяются по правилу: пройден только в случае получения флага 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-сервисам, к которым у вас есть доступ в рамках текущего проекта.
Для удобства обработки данных используйте фильтр.

Конвейеры — Создание и настройка#

Уровни, на которых может быть создан конвейер#

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

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

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

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

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

Перейдите на страницу Сервиса;
Кликом по иконке "три точки" откройте контекстное меню редактируемого Сервиса и далее выберите Конвейеры Сервиса:
На странице конвейеров нажмите кнопку Создать конвейер:
Заполните:
1. Наименование конвейера;
2. Описание (опционально).
Настройте этапы (см. ниже).
Сохраните конвейер.

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

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

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

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

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

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

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

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

Перейдите в настройку фаз — в открывшемся диалоге настроек этапа нажмите кнопку Настроить фазы.
Сформируйте порядок фаз, в каждой из которых может быть вызвано одно задание. Фазы могут быть добавлены в один уровень — тогда их выполнение будет идти параллельно. Фазы, добавленные в разные уровни, будут выполнены последовательно.
Выберите тип фазы:
1. Jenkins — в фазе выполняется Jenkins job;
2. Ручная фаза — подходит для ручного тестирования, можно оставлять комментарии. Например, пункт о протоколе тестирования;
3. Argo-фаза — обеспечивает возможность развертывания образов на стенды с использованием Argo CD. Подробнее см. раздел Argo фаза;
4. Сервисная — можно выбрать подтип:
  1. Для публикации Quality gates в виде Nexus classifier (будет использована shared lib);
  2. Для подготовки к передаче дистрибутива в ФПД (фонд программ и документации).
    Подробное использование QG описано в разделе Quality Gates.
Задайте Название фазы (обязательно), отображающее смысл выполнения задания, например, 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, влияют на прохождение фазы.
Нажмите кнопку Сохранить.

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

Для добавления проверки Quality Gates на этапах конвейера в диалоге настроек этапа нажмите кнопку Настроить Quality Gates.

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

Режим запуска этапа#

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

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

Описание этапа#

Описание этапа конвейера (опционально) доступно для каждого добавленного этапа в текстовом поле Описание этапа.

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

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

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

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

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

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

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

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

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

Post-action фазы#

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

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

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

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

Argo-фаза#

Argo-фаза обеспечивает возможность установки образов в Kubernetes с использованием Argo CD в качестве инструмента.

Взаимодействие DPM и Argo CD#

Argo CD контролирует изменение приложения и обеспечивает доставку изменений в проект Openshift/Kubernetes.

Описание устанавливаемого приложения хранится в приложении (application) Argo CD. Настройки (устанавливаемого дистрибутива, стенда для установки и т.п.) хранятся в манифесте. Манифест хранится в BitBucket или ином репозитории исходного кода в YAML-файлах kustomization.yaml и values.yaml.

Пример файла kustomization.yaml:

imageApp:
  path: registry.hostname.ru/dev/c01234567/c02345678_dev/demo-microservice@sha256:{sha256}
  containerApiPort: 8080
  livenessProbe:
    httpGet:
      path: /backend/health111
      port: 8080
  readinessProbe:
    httpGet:
      path: /backend/health
      port: 8080
  terminationMessagePath: /dev/termination-log
  terminationMessagePolicy: File
  imagePullSecrets: registry.secret
serviceApp:
  port: 8080

Пример файла values.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmGlobals:
  chartHome: ../../charts
helmCharts:
- name: java-app
  releaseName: java-app
  valuesFile: values.yaml
  valuesInLine:
    imageApp.path:  registry.hostname.ru/dev/c01234567/c02345678_dev/demo-microservice@sha256:1234567899012345678901234567890
# - name: ingress
#   releaseName: ingress
#   valuesFile: values.yaml
# - name: egress
#   releaseName: egress
#   valuesFile: values.yaml

Данные файлы хранятся в папке, имя которой отражает стенд для установки (например, environments/dev). Параметр Argo-фазы указывает, на какой именно стенд следует устанавливать сервис. Подробности изложены в подразделе Настройка и запуск Argo фазы.
По команде от DPM Argo CD считывает манифест и при обнаружении изменений выполняет установку согласно текущим настройкам, указанным в манифесте.

Примечание

Часто при работе с Argo CD используется периодическая автоматическая синхронизация (опрос) файлов манифестов со стороны Argo CD. Для использования Argo CD c DPM такая автоматическая синхронизация отключена — для управления установкой только со стороны DPM.

Процесс установки#

В DPM процесс установки в Kubernetes c использованием Argo CD состоит из следующих шагов:

DPM обновляет файлы манифеста в репозитории исходного кода (BitBucket CD): обновляются значения в файле kustomization.yaml, они переопределяют значения, указанные в файле values.yaml;
DPM вызывает метод Public API Argo CD для запуска установки;
Argo CD считывает настройки из файла манифеста;
Argo CD выполняет установку указанного дистрибутива в указанный стенд;
DPM периодически запрашивает у Argo CD статус установки.

Настройка и запуск Argo фазы#

Вычисление ссылки на образ#

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

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

Способы вычисления ссылки на образ:

при использовании шаблонного этапа CI;
при использовании пользовательской CI Jenkins job;
при использовании DPM-сервиса для образов в Registry.

При использовании шаблонного этапа CI#

Шаблонный этап CI записывает ссылку на образ в Release Notes.

Чтобы вычислить ссылку на образ для передачи в Argo-фазу выполните следующие действия:

Создайте Jenkins job для вычисления значения и передачи ссылки на образ в активный конвейер релиз-кандидата (РК) с помощью API DPM в параметр imageDigest. Подробности приведены ниже в описании метода для передачи значения в активный конвейер.
Перед Argo-фазой добавьте Jenkins фазу "Вычисление ссылки на образ", где будет вызываться Jenkins job, созданная в п.1.
В поле "Registry" Argo-фазы добавьте переменную ${imageDigest}.

Описание метода для передачи значения в активный конвейер:

Endpoint (DPM service):

PUT http://\{адрес_сервера\}/dpm/api/user-public/pipeline-var/create

Headers:

login USER

token TOKEN (для междоменных операций достаточно только токена без логина)

Body (raw json):

{
"externalKey": "69823",
"vars": {
"imageDigest": "ссылка на вычисленный образ"
}
}

Примечание

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

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

При использовании пользовательской CI Jenkins job#

Чтобы вычислить ссылку на образ для передачи в Argo-фазу, выполните одно из следующих действий:

Доработайте Jenkins job так, чтобы ссылка на образ передавалась в currentBuild.description:
1. Убедитесь, что в Jenkins job помимо записи собранного дистрибутива в Nexus3 есть шаг записи образа в Registry.
2. В Jenkins job сборки добавьте логику возвращения ссылки на образ в currentBuild.description job.
3. Убедитесь, что в currentBuild.description отсутствуют другие значения. Если созданная Jenkins job предусматривает возвращение других значений, необходимо сделать дополнительную Jenkins job и соответствующую фазу для нее для сбора результата.
4. Добавьте пользовательскую CI Jenkins job в конвейер DPM.
5. В поле "Registry" Argo-фазы добавьте переменную вида ${RC.phase.buildDescription.КЛЮЧ_ФАЗЫ_CI}. КЛЮЧ_ФАЗЫ_CI — ключ, который есть у каждой фазы, значение которого находится справа от ее названия:
Добавьте шаг передачи ссылки на образ в активный конвейер релиз-кандидата (РК) с помощью API DPM в параметр imageDigest:
1. В Jenkins job загрузки образа в Registry добавьте шаг передачи ссылки на образ в активный конвейер релиз-кандидата (РК) с помощью API DPM в параметр imageDigest.
2. Перед Argo-фазой добавьте Jenkins-фазу "Вычисление ссылки на образ", где будет вызываться job, созданная в п.1.
3. В поле "Registry" Argo-фазы добавьте переменную, например, ${imageDigest}.

Argo-фаза автоматически вычислит ссылку на образ и передаст значение в переменную.

При использовании DPM-сервиса для образов в Registry#

Для вычисления ссылки на образ в поле "Registry" Argo-фазы добавьте переменную вида ${imagePath}, которая вычислит ссылку на образ.

Подготовка к работе#

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

Обеспечьте вычисление пути к образу в пользовательской переменной для передачи этого значения Argo-фазе (см. подраздел Вычисление ссылки на образ).
Организуйте сборку и выкладку образа этого сервиса в Registry.
Для каждого сервиса DPM создайте приложение (application) Argo CD. При создании application в BitBucket CD будет создан файл values.yaml. Далее пользователь может редактировать этот файл в BitBucket CD для изменения параметров установки, но при каждом запуске Argo-фазы значения из файла values.yaml будут переопределяться значениями из файла kustomization.yaml.
Добавьте и настройте Argo-фазу в этап конвейера (см. подраздел Настройка Argo-фазы).

Настройка Argo-фазы#

Для настройки Argo-фазы выполните следующие действия:

Добавьте в этап конвейера новую фазу и выберите тип фазы Argo-фаза:
Настройте параметры фазы. Для заполнения потребуются следующие данные, специфичные для Argo-фазы:
- Тип публикации/регистрации;
- Argo CD URL;
- Bitbucket repo;
- StandID;
- Branch;
- Registry;
- Учетная запись Argo CD.
- Учетная запись Bitbucket CD.
Поддерживается использование переменных:

Параметр	Назначение	Формат
Тип публикации/регистрации	Способ получения настроек	Выбор из списка доступных
Argo CD URL (*)	URL приложения (application) Argo CD из адресной строки браузера до знака "?"	https://<АДРЕС ARGO CD>/applications/<NAMESPACE>/<ИМЯ ПРИЛОЖЕНИЯ> (<NAMESPACE> может отсутствовать)
Bitbucket repo (*)	Адрес репозитория для хранения файла манифеста `kustomization.yaml` (HTTPS Git clone)	https://<ИМЯ СЕРВЕРА>/projects/<ИМЯ ПРОЕКТА>/repos/<ИМЯ РЕПОЗИТОРИЯ>
StandID	Идентификатор стенда для развертывания (берется из APP DETAILS → PATH)	Название стенда
Branch	Ветка Git, содержащая файлы манифеста, актуальные для использования при запуске фазы (берется из APP DETAILS → TARGET REVISION)	Название ветки репозитория Git
Registry (*)	URL устанавливаемого образа. <АДРЕС REGISTRY>, <ПУТЬ> и <ИМЯ СЕРВИСА> статичны — версия образа передается значением <ХЕШ sha256>.	https://<АДРЕС REGISTRY>/<ПУТЬ>/<ИМЯ СЕРВИСА>@sha256:<ХЕШ sha256>
Учетная запись Argo CD	Логин и пароль для учетной записи, имеющей доступ в Argo application.	Логин/пароль
Учетная запись BitBucket CD	Логин и пароль для учетной записи, имеющей доступ к параметрам установки для Argo CD в BitBucket CD. При настройке фазы можно указать конкретный уровень (проект AS, приложение FSS, сервис RAO), с которого будут взяты учетные данные.	Логин/пароль

Примечание

Для параметров, отмеченных знаком "*", поддерживается использование переменных уровня проекта или конвейера. Учетные данные можно указать непосредственно в фазе, при перезапуске фазы, ручном запуске или в настройках доступа к Внешним приложениям. Если параметры учетной записи не указаны ни на одном уровне (проект, приложение, сервис, фаза), то в автоматическом режиме фаза не запустится.

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

Запуск Argo фазы#

При запуске фазы логин и пароль обращения к Argo будут взяты из настроек фазы. Если в фазе отсутствует логин и пароль, будет произведен поиск на уровнях сервиса, приложения и проекта.

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

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

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

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

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

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

В 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:

Скачается файл в формате JSON, содержащий настройки конвейера.

Для импорта:

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

После импорта конвейер сохранится в статусе Imported в разделе Импортированные.

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

Экспорт и импорт конфигураций конвейера в/из репозитория#

Настройки конвейера можно экспортировать/импортировать в/из репозитория в/из файла в формате YAML.

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

Задайте репозиторий для конвейера и учетную запись в настройках проекта/приложения/сервиса, на вкладке Репозитории для конвейера:

Экспорт в репозиторий#

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

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

По завершении экспорта (в зависимости от сложности конвейера, это может потребовать до нескольких минут) в указанной папке репозитория появится файл в формате YAML, содержащий настройки конвейера.

Импорт из репозитория#

Для импорта:

Перейдите в список конвейеров на уровне проекта/приложения/сервиса, откройте Раздел Конвейеры.
Нажмите кнопку Импортировать и далее в контекстном меню выберите Из репозитория.
В открывшемся окне импорта укажите название файла конвейера и тег нужной версии файла:
Нажмите кнопку Импортировать.

После импорта конвейер сохранится в статусе Imported в разделе Импортированные.

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

Для архивирования конвейеров перейдите на страницу конвейеров (меню Настройки сервиса → Конвейеры Сервиса).
Функция архивирования доступна для конвейеров в статусах 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, фаза останется в статусе По умолчанию.

Переменные (параметры) в 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} и выбран пункт Не разделять значения переменной, то отобразится значение переменной с игнорированием разделителей (запятых):

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

Если в конвейере задана переменная 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}	Адрес дистрибутива с classifier и расширением для Nexus
${pullImagePath}	Адрес дистрибутива с classifier и расширением для Registry
${baseArtifactPath}	Возвращает структуру ${repositoryName}/${groupid}/${artifactid}/${version}/${artifactid}${version}${classifier}.${extension}
${imagePath}	Местоположение дистрибутива Registry
${extension}	Расширение дистрибутива в Nexus (задается в настройках Сервиса)
${classifier}	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, которая сможет обновить значение переменной, описано в подразделе Переменные конвейера. Обновление значений из Jenkins;
Вызывайте такую переменную несколькими способами:

Способ обратиться к значению переменной	Пример
${НАЗВАНИЕ_ПЕРЕМЕННОЙ.НАЗВАНИЕ_ЭТАПА.КЛЮЧ_ФАЗЫ}	${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

Управление движением конвейеров#

См. раздел "Использование приложения оператором" Руководства оператора;

Частные случаи#

Включение в конвейер пользовательской job сборки#

Включение в конвейер пользовательской job сборки выполняется стандартным способом — включением ее в Jenkins-фазу с указанием параметров job.

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

Доработать job;

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

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

В настройках Jenkins-фазы в поле Назначение выберите признак CI.

Важно!
Фаза должна быть первой и единственной в конвейере.

Обратите внимание, если job сборки формирует номер будущего дистрибутива в ходе своего выполнения, и версия отличается от данных в webhook от репозитория исходного кода, то требуется выполнить 2 дополнительных шага:
1. В настройках Jenkins-фазы активируйте чек-бокс Своя версия.
2. Доработайте job сборки так, чтобы в описании сборки (build description) возвращалась фактическая версия артефакта в параметре retArtifactVersion.
Возвращать из job фактическую версию собранного артефакта нужно для сопоставления версии из webhook от репозитория, для которой запущен конвейер, и фактической версии, которую сформировала job сборки, и с которой артефакт сохранен в репозитории артефактов.

Такое сопоставление нужно для:
- исключения дублей РК и предотвращения запуска конвейеров для дублей РК;
- корректного вычисления ссылки на фактический дистрибутив в Nexus;
- корректного вычисления внутренних переменных DPM: ${fullArtifactPath}, ${baseArtifactPath}, ${version}.
Вставлять такой фрагмент следует в середину текста job сразу после формирования номера версии артефакта и до сохранения артефакта в Nexus.

Если пользовательская job изменяет атрибут build description после вставленного фрагмента (ниже по тексту job, в вызываемых job и т.п.), то такое изменение должно быть конкатенацией к существующему во избежание затирания номера версии артефакта.

Формат retArtifactVersion:
```
retArtifactVersion=номер_версии
```
где номер_версии - произвольная строка до знаков ,; или конца строки, т.е. допустимы не только цифры, но и префиксы/суффиксы/нумераторы и т.п…

Регулярное выражение, которому должна удовлетворять строка передачи retArtifactVersion:
```
.*retArtifactVersion=(?<version>[^,;]+)
```
Например, currentBuild.description = "любой текст retArtifactVersion=myversion010203, ; любой текст".
Настройте профиль конвейера (см. подраздел Автозапуск конвейеров: Работа с профилями конвейеров).
В репозитории исходного кода настройте webhooks для автозапуска конвейера с этапом CI (см. подраздел Настройка webhooks от репозитория исходного кода для автозапуска конвейера).

В пользовательском интерфейсе для РК выводятся оба номера версий:

исходный номер версии РК, присвоенный при создании РК по webhook от репозитория исходного кода;
номер версии артефакта, собранного и загруженного в репозиторий артефактов job сборки.

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

Продвинутые возможности#

Использование 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": "configItem",
"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": "nameofservice",
"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 — это ключ сервиса, в который будет добавлен РК указанной версии.

Создание пользователя#

Endpoint (DPM service):

POST http://localhost:8080/dpm/api/public/user/create

Headers:

Body (raw json):

{
 "userLogin" : "USER",
 "isExternalUser" : true
}

Замечание:

isExternalUser (по умолчанию false) — признак Внешний пользователь (используется наряду с ролью для определения того, является ли пользователь внешним сотрудником).

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

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": "<ссылка на релиз в трекере>"
}

Замечание:

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

Создание 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.

Запуск конвейера по webhook от репозитория исходного кода#

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

Создан РК с номером версии, равной имени той ветки репозитория исходного кода, по событию от которой отправлен webhook.
Запущен конвейер, назначенный профилем конвейера (см. подраздел Автозапуск конвейеров: Работа с профилями конвейеров).

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

Обратите внимание
На данном этапе обрабатываются только webhook из веток release.

В репозитории исходного кода CI выполните следующее:

Перейдите в настройки репозитория.
В открывшемся меню выберите Webhooks и нажмите кнопку Create webhook.
Укажите следующие параметры:
- Title — название, например, DPMtest;
- URL — адрес сервиса event provider, например: https://{адрес_сервера}/dpm/orchestrar-event-provider/git/events;
- Merged — флаг, установлен.
Нажмите Test connection. При верно указанных настройках должен появиться код ответа 200.
Сохраните изменения.

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

Свяжите DPM сервис с репозиторием исходного кода:
1. Перейдите в настройки сервиса DPM, в котором должны появиться новые релиз-кандидаты по webhook от репозитория исходного кода.
2. На вкладке Репозиторий и группировка заполните поля:
  - ID проекта — проект в репозитории исходного кода;
  - ID репозитория — репозиторий в репозитории исходного кода.
Проверьте значение регулярного выражения группировки сервиса. В настройках сервиса DPM в поле Regexp группировки добавьте окончание (-\d+)?.
Настройте очереди, для этапов CI укажите следующее:
- Устанавливается одновременно = без ограничений
- По правилу = Первым пришел - первым установился

Шаблонные этапы#

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

Шаблонные этапы перечислены в верхней части списка этапов.
Настроить параметры фаз шаблонного этапа можно в разделе диалога настроек этапа Настроить фазы.

Шаблонный этап CI#

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

сборка дистрибутива и загрузка в Nexus;
сканирование SAST/OSS, если проверки применимы;
запись Release Notes.

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

Особенности настройки фаз шаблонного этапа CI#

Параметры фаз шаблонного этапа CI предзаполнены переменными. Это позволяет настроить шаблоны в глобальных конвейерах проекта/приложения.
Если в проекте работает несколько команд, то конкретные значения они смогут указать на уровне "Приложения" или "Сервиса". Например, для передачи параметру фазы Признак Bitbucket CI (исходное параметризованное значение #{this.stash-sign}) на уровне проекта или приложения следует создать переменную stash-sign со значением, равным имени домена в нижнем регистре.

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

Текущие ограничения#

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

Для сборки Java:

Контейнеризируемое java-приложение
- Монолитное
- Одномодульное
Openshift
Java 8, 11, 17
Maven
- Maven профилей нет
- Простейший Settings.xml (только авторизация в Nexus 3)
  - Settings.xml требует редактирования (настройка Sonarqube через sonar projects.properties)
Файлы в поставку попадают из target/resources, поэтому необходимо использовать maven-resources-plugin для копирования необходимых манифестов в поставку
Сборка образа через Dockerfile
Наличие доступа к инструментам: Jenkins, Nexus 3, Registry, Bitbucket, Sonarqube

Для сборки Python:

Контейнеризируемое приложение
- Монолитное
- Одномодульное
Openshift
В итоговый zip для Nexus3 попадает вся папка manifests, которая должна располагаться в корне проекта
Сборка образа через Dockerfile
Работа только с Nexus 3 и Registry
Наличие доступа ко всем инструментам: Jenkins, Nexus 3, Registry, Bitbucket (Sonarqube для проектов python не поддерживается)

Шаги настройки окружения для работы с шаблонным этапом CI#

Для использования шаблонного этапа CI требуется:

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

Ручной запуск CI этапа#

Находясь в сервисе, нажмите кнопку Запустить этап CI.
В открывшемся окне заполните:
- Git_branch — релизная ветка для сборки;
- Version — версия РК, которая будет присвоена созданному РК.
В зависимости от настроек автоматизации DPM отобразит конвейер с CI этапом (также можно выбрать его самостоятельно).
Нажмите кнопку Подтвердить запуск. Будет добавлен новый РК указанной версии.
Артефакт указанной версии будет собран в первой фазе этапа CI из ветки, указанной в поле Git_branch.

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

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

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

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

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

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

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

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

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

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

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

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

Цепочки фаз#

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

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

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

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

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

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

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

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

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

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

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

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

Вручную
Через API
При создании поставочного конвейера
С помощью сервисной фазы

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

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

Выберите Не готов к поставке → Пометить готовым к поставке:
На Релиз-кандидате появится лейбл Готов к поставке:

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример этапа с тиражируемой фазой:

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

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

Нажмите кнопку Запустить под фазой:
При необходимости укажите параметры запуска;
Фаза будет скопирована для каждого РК, входящего в поставку, и запущена по очереди:
Если требуется подтверждение, подтвердите все фазы нажатием кнопки Валидировать:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Jenkins нажмите ФИО в правом верхнем углу
В левом меню перейдите к пункту Настроить
Нажмите кнопку Add new token
Задайте имя токена и нажмите кнопку Generate
Скопируйте сгенерированный токен кликом по иконке

Сохранение личного токена от Jenkins в DPM для запуска задач#

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

Использование сохраненного в DPM токена из Jenkins при запуске задач или изменение установленного по умолчанию#

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

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

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

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

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

Доверенный пользователь#

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

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

Данная функция предназначена для создания токенов для ТУЗ.

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

создать токен;
передать этот созданный токен ТУЗ.

После передачи переданный токен не будет отображаться среди токенов доверенного пользователя, но будет отображаться среди токенов ТУЗ.

Общие настройки DPM — работа в Панели администратора#

Список фиче-флагов#

Включение фиче-флагов#

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

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

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

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

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

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

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

Поля:

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

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

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

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

Шаблоны конвейеров#

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

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

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

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

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

Поля:

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

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

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

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

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

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

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

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

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

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 перейдите в раздел Шаблоны версионирования.

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

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

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

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

Поля:

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

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

Внешние приложения#

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

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

Доступные типы стендов#

Для добавления доступны следующие типы стендов:

Argo CD;
Bitbucket CD;
Docker Registry;
ELK;
Jenkins;
Jira;
Nexus;
Nexus 3;
Nexus Registry;
Qgm;
Rest.

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

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

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

Поля:

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

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

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

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

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

Release Notes#

Release Notes — настройка учетных записей для работы с RN.

Роли и разрешения#

Вкладка позволяет установить следующие права:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщения пользователям#

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