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

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

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

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

Устройство каталога объектов в системе#

Иерархия основных объекты, с которыми работают пользователи в системе:

Проектная область (АС);

ФП;

ОРД;

Релиз;

Релиз-кандидат 1 (История релиз-кандидата);

Релиз-кандидат 2 (История релиз-кандидата).

Для каждого из объектов Проектная область, Функциональная подсистема, ОРД и релиз могут быть созданы один или несколько дочерних объектов.

Схема работы#

DPM включает этапы:

• формирование каталога дистрибутивов;

• конфигурирование этапов конвейера;

• запуск задач Jenkins;

• валидация результата выполнения задач.

Следующие шаги помогут начать работу с DPM.

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

Начало работы с инструментом управления поставками дистрибутивов#

Подготовка#

Для начала работы с DPM:

1. Подготовьте репозиторий Nexus, который будет использоваться для публикации дистрибутивов.

2. Создайте шаблон конвейера.

3. Подготовьте задания Jenkins (jobs), которые будут добавлены в конвейер.

4. Создайте проектную область.

5. В проектной области определите хранилище дистрибутивов, а затем настройте роли пользователей и конвейеры.

Более подробные инструкции по настройке представлены в разделе Руководство администратора соответствующего компонента.

Работа с проектной областью#

Когда проектная область создана:

1. Создайте функциональную подсистему (ФП).

2. В функциональной подсистеме создайте объект релизной деятельности.

Этой иерархией можно пользоваться для разграничения прав и определения общих переменных (адресов стендов тестирования, параметров запуска). Проектная область (АС) и функциональная подсистема служат для группировок основного объекта работы — объекта релизной деятельности (ОРД). ОРД — набор дистрибутивов, выпускаемых командой разработки, который соответствует Group ID + Artifact ID в Nexus.

Например, DPM состоит из отдельных сервисов, у каждого из которых есть свой репозиторий кода: mail service, audit service, core. Версии каждого сервиса ведутся отдельно, каждый сервис представляет собой объект ОРД.

Когда функциональная подсистема создана, следуйте алгоритму работы с DPM:

1. Создайте ОРД.

2. Создайте конвейеры (данные конвейеры используются для тестирования дистрибутивов).

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

4. Активируйте ОРД.

5. Скачайте дистрибутивы из хранилища Nexus.

6. Запустите конвейеры (при запуске конвейеров используются параметры, указанные в конвейерах и профилях).

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

Работа в UI#

В следующих разделах описана работа с веб-интерфейсом DPM.

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

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

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

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

1. Выберите проектную область, а затем нажмите кнопку Редактировать.

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

3. Добавьте пользователей в список пользователей. Пользователи этого списка будут иметь только возможность просмотра свойств объектов и работы с конфигурациями, заданными администраторами DPM, без возможности вносить изменения.

4. Нажмите кнопку Сохранить (см. Рисунок 1).

Рисунок 1. Панель настройки проектной области

Создание функциональной подсистемы#

В каталоге артефактов функциональная подсистема расположена на уровне внутри проектной области.

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

1. откройте проектную область (см. Рисунок 2).

Рисунок 2. Панель проектной области

2. Нажмите кнопку Создать ФП.

3. Воткрывшемся окне (см. Рисунок 3) введите имя создаваемой функциональной подсистемы; заполните опциональные поля.

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

Поля

• Наименование (обязательное поле) — название функциональной подсистемы, которое будет отображаться в DPM;

• Описание (опциональное поле) — описание функциональной подсистемы;

• Ответственный (обязательное поле) — учетная запись пользователя, отвечающего за функциональную подсистему;

• настройка доступов к Nexus (опциональные поля): Nexus, логин, пароль.

Во вкладке Роли/доступы:

• Администраторы — список учетных записей пользователей, которые будут иметь доступ к администрированию функциональной подсистемы и изменению ее настроек;

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

Рисунок 3. Панель настройки ФП

Изменение функциональной подсистемы#

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

1. Нажмите кнопку редактирования:

• в каталоге;

• на странице проектной области.

2. Внесите изменения.

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

Добавление данных для авторизации в Jenkins#

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

Приоритет использования логина и токена (в порядке уменьшения приоритета):

• пользовательский (задание токена для выполнения авторизированных заданий Jenkins);

• заданный для ОРД (регистрация объектов релизной деятельности);

• заданный для функциональной подсистемы;

• заданный для проектной области.

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

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

1. Откройте страницу проектной области, а затем редактирования.

2. Перейдите на вкладку "Доступы в Jenkins".

Рисунок 4. Панель ввода учетных данных

1. Выберите экземпляр Jenkins.

2. Укажите учетную запись и токен пользователя (см. Рисунок 4), который будет использоваться для входа в Jenkins.

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

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

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

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

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

1. Выберите функциональную подсистему, а затем нажмите кнопку Редактировать.

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

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

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

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

Редактирование проектной области (АС)#

Права на редактирование проектной области (АС) есть у ответственного и администраторов АС. Права редактирования функциональной подсистемы (ФП) у ответственного и администраторов АС или ФП.

Проектную область создают администраторы DPM.

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

1. На главной странице или на странице проектной области нажмите кнопку редактирования (см. Рисунок 5).

Рисунок 5. Панель редактирования

2. Отредактируйте поля (см. Рисунок 6).

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

Описание полей:

• Имя (обязательно) — название проектной области;

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

• Nexus, логин, пароль (опционально) — адрес и учетные данные для доступа к частным репозиториям для всех дочерних объектов; все ОРД будут использовать указанные учетные данные для доступа к хранилищу Nexus;

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

Рисунок 6. Диалоговое окно ввода значений полей

Создание функциональной подсистемы#

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

1. Откройте проектную область, а затем нажмите кнопку Создать ФП.

2. Наполните поля.

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

Описание полей (см. Рисунок 7):

• Имя (обязательно);

• Ключ (обязательно) — ключ; этот, может быть, использован для доступа к переменным ФП в качестве параметров, передаваемых в задании Jenkins (job). ключ задается один раз, изменить ключ в дальнейшем невозможно;

• Nexus, логин, пароль (опционально) — адрес и учетные данные для доступа к частным репозиториям для всех дочерних объектов; все ОРД будут использовать указанные учетные данные для доступа к хранилищу Nexus;

• Конфигурационный элемент (опционально) — КЭ (CI) для автоматизации мониторинга;

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

во вкладке Роли/доступы:

• Администраторы (опционально);

• Пользователи (опционально).

Рисунок 7. Диалоговое окно ввода значений полей

Администратор функциональной подсистемы#

Создание объектов релизной деятельности#

Создание ОРД состоит из этапов:

• выбор репозитория и правил, по которым артефакты в нем будут считаться релиз-кандидатами ОРД;

• настройка конвейера с заданием параметров запуска задач Jenkins.

Для выбора репозитория и правил:

1. Откройте страницу функциональной подсистемы.

2. Нажмите кнопку Создать ОРД.

3. Заполните поля (см. Рисунок 8).

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

Описание полей:

• Name (обязательно) — название ОРД;

• Ключ(обязательно) — используется для обращения к контексту ОРД в параметрах запуска задач;

Для выбора проекта в Nexus:

• URL дистрибутива или;

• Nexus (обязательно) — выбор ХИП из списка зарегистрированных экземпляров;

• Repository (обязательно) — название репозитория ХИП;

• Group ID (обязательно) — Group ID артефактов в ХИП;

• Artifact ID (обязательно) — Artifact ID артефактов в ХИП;

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

• Шаблон артефакта — шаблон наименования артефактов или;

• Регулярное выражение (обязательно) — регулярное выражение, по которому в указанной проекте артефакты будут регистрироваться в АС;

• Шаблон артефакта (обязательно) — выражение для формирования релизов, по которым группируются релиз-кандидаты;

• Группа релизов — подгруппа релизов;

• Шаблон версии — выражение, на основе которого в АС будут отображаться полученные релиз-кандидаты;

• Description (опционально) — описание ОРД.

Рисунок 8. Создание ОРД. Панель ввода значений параметров

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

1. Нажмите кнопку Предпросмотр и на экране отобразится структура регистрируемого ОРД — списка релизов с входящими в него релиз-кандидатами (см. Рисунок 9).

Рисунок 9. Структура регистрируемого ОРД

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

Конфигурирование конвейера ОРД#

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

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

Для конфигурирования конвейера:

1. Откройте страницу ОРД.

2. В меню "Действия" выберите пункт "Конвейеры ОРД"(см. Рисунок 10).

Рисунок 10. Меню "Действия"

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

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

• заименование конвейера;

• описание (опционально).

Для добавления этапа (см. Рисунок 11):

1. В поле "Схема" конвейера нажмите кнопку Редактировать.

2. В редакторе конвейера нажмите кнопку Новый этап.

3. Перетяните этап в добавленную колонку.

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

Рисунок 11. Страница конфигурирования конвейера

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

1. Нажмите кнопку настройки этапа (см. Рисунок 12).

Рисунок 12. Настройка этапа

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

Фазы можно добавить в горизонтальную линию, чтобы фазы выполнялись параллельно (см. Рисунок 13).

Фазы, добавленные в разные линии, выполняются последовательно.

Рисунок 13. Изменение этапа. Порядок фаз

3. Укажите тип фазы:

• Jenkins — в фазе выполняется Jenkins job;

• Ручная фаза — для ручного тестирования (можно оставлять комментарии);

• Сервисная фаза — фаза, настройка которой задается Администратором DPM для выполнения стандартизированных задач;

4. Заполните следующие поля в зависимости от требований к типу, условиям, параметрам запуска:

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

• Job (обязательно) — полный URL задания Jenkins (job). Поле Jenkins будет автоматически выбран из списка зарегистрированных стендов. Если подходящий стенд не будет найден, запустить такую фазу невозможно;

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

• Параметры (опционально) — для параметризованных заданий добавляются параметры запуска. В качестве параметров можно использовать переменные DPM:

• Безопасные параметры (опционально) — для параметризованных заданий добавляются безопасные параметры запуска, которые не хранятся в явном виде в БД, не возвращаются клиенту и имеют более высокий приоритет по сравнению с простыми параметрами;

• Stage jenkins job (опционально) — этапы pipeline job, статусы прохождения которых необходимо фиксировать в DPM, влияют на прохождение фазы;

• Режим валидации (обязательно) — режим проверки статуса задания, полученного от оркестратора. Варианты: автоматический или ручной. В ручном режиме валидация (и переход на следующую фазу или этап) всегда будет происходить после подтверждения ответственного пользователя. В автоматическом режиме переход к следующей фазе или этапу будет автоматическим, при условии положительного статуса задания Jenkins (job); негативный статус или отсутствие статуса по любому из Jenkins stage требует ручной валидации;

• нажмите кнопку Сохранить;

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

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

Для передачи данных между разными заданиями Jenkins (job) можно использовать глобальные переменные.

Пример:

1. Зарегистрируйте переменную NeedLT (требуется нагрузочное тестирование).

2. В одном задании проверьте, какие модули изменены.

3. В DPM установите значение переменной NeedLTв true или false.

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

Управление конфигурациями конвейеров#

Применение конвейеров#

Конвейер может находиться в одном из следующих статусов:

• Available — сконфигурированный конвейер, по которому можно запустить релиз-кандидат или добавить в профиль;

• Imported — черновик конвейера после импорта (необходимо зайти в редактирование этапа и сохранить конвейер);

• Archived — архивные конвейеры, которые больше не используются.

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

Для копирования конвейеров:

1. Откройте страницу конвейеров (Конфигурирование конвейера ОРД).

2. Вполе доступных действий нужного конвейера нажмите кнопку. В списке конвейеров появится копия.

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

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

1. Откройте страницу конвейеров (Конфигурирование конвейера ОРД).

2. В поле доступных действий нужного конвейера нажмите кнопку.

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

Для архивирования конвейеров:

1. Откройте страницу конвейеров (Конфигурирование конвейера ОРД).

2. В поле доступных действий нужного конвейера нажмите кнопку.

Назначение пользователей, отвечающих за этап#

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

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

1. Откройте страницу требуемой функциональной подсистемы.

2. Нажмите кнопку Ответственные за этапы (см. Рисунок 14).

Рисунок 14. Страница выбранной ФП

3. В поле, соответствующем этапу, нажмите кнопку Настроить или Редактировать (см. Рисунок 15).

Рисунок 15. Панель выбранного этапа

4. Добавьте пользователей, ответственных за определенный этап (см. Рисунок 16).

5. Выберите правила подтверждения.

Рисунок 16. Панель "Ответственный за этап"

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

Запуск конвейера и активация ОРД#

После создания ОРД и применения конвейера (Регистрация объектов релизной деятельности, Применение конвейеров) необходимо активировать ОРД. Активация запускает синхронизацию комплекта дистрибутивов с Nexus. Для последнего опубликованного артефакта инициируется конвейер.

Для активации ОРД:

1. Откройте страницу ОРД.

2. В меню "Действия" выберите пункт "Активировать" или на странице ФП нажмите кнопку Активировать.

Запуск конвейера вручную#

Для запуска конвейера вручную:

1. Откройте страницу требуемого дистрибутива (релиз-кандидата). (см. Рисунок 17).

Рисунок 17. Страница требуемого дистрибутива

2. Выберите конвейер в выпадающем списке.

Редактирование объектов релизной деятельности#

Для внесения изменений в настройки ОРД:

1. Откройте страницу ОРД.

2. В меню "Действия" выберите пункт "Редактировать".

3. Отредактируйте поля:

• наименование;

• логин и токен для обращения к Nexus;

• параметры конвенции наименования дистрибутивов;

• описание;

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

Добавление технологических окон к ОРД#

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

Для добавления технологических окон:

1. Откройте страницу ОРД.

2. В меню "Действия" выберите пункт "Технологические окна".

3. На странице технологических окон нажмите кнопку Создать расписание (см. Рисунок 18).

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

Рисунок 18. Страница технологических окон

Для добавления технологического окна в расписание заполните поля (см. рисунок 19):

• Этап — этап, на который назначается технологическое окно;

• Период техокна — календарный период действия технологического окна;

• Время — часы действия технологического окна;

• Дни недели, в которые действует технологическое окно.

Рисунок 19. Добавления технологического окна

Создание объектов релизной деятельности#

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

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

1. Создайте ОРД (связать DPM с Nexus).

2. Сконфигурируйте конвейер.

3. Добавьте конвейер в профиль.

4. Активируйте ОРД.

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

Создание ОРД#

1. Откройте страницу функциональной подсистемы, а затем нажмите кнопку Создать ОРД.

2. На странице создания добавьте ссылку на дистрибутив (остальные поля заполнятся автоматически) (см. Рисунок 20).

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

Рисунок 20. Панель "Создание ОРД"

3. Отредактируйте поля связки с Nexus вручную (см. Рисунок 21):

• Наименование — название ОРД;

• Nexus — выбор ХИП из списка зарегистрированных в DPM (если нет подходящего, нужно обратиться к администраторам);

• Nexus логин и пароль (необязательно);

• Nexus пароль (необязательно), заполните, если доступ к вашему репозиторию ограничен);

• Репозиторий — наименования репозитория ХИП;

• Nexus group ID (обязательно);

• Nexus artifact ID (обязательно) — см. URL или в файле maven-metadata.xml.

Рисунок 21. Nexus artifact ID в файле maven-metadata.xml

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

• Регулярное выражение — шаблон поиска дистрибутивов;

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

• Шаблон релиз-кандидата (дистрибутива) — также можно использовать скобочные группы. Правило, по которому дистрибутив будет отображаться в DPM;

• Exclude regexp — исключающее регулярное выражение; используйте для исключения дистрибутивов; если в репозитории будут дистрибутивы, которые не соответствуют регулярному выражению, такие дистрибутивы на будут исключены. Эти дистрибутивы сохранятся в версии Unknown c префиксом Wrong RegExp for RC .

• Для скрытия таких дистрибутивов используйте переключатель .

• Description (опционально) — описание объекта;

• Ключ — все ключи ОРД, ФП (функциональной подсистемы) или АС (проектной области или автоматизированной системы) уникальны. Это позволяет обращаться к переменным конкретного объекта по ключу этого объекта.

5. Нажмите кнопку Сохранить только ОРД, чтобы сохранить ОРД или кнопку Назад, чтобы перейти к настройке конвейера. Настройка CI будет пропущена.

Активация ОРД#

Для активации ОРД необходим профиль. Это необходимо для обработки полученных дистрибутивов (релиз-кандидатов).

Для активации ОРД:

1. Откройте страницу ОРД;

2. В меню выберите пункт Активировать.

После первой активации только последний опубликованный дистрибутив отправляется в конвейер в соответствии с профилем. Остальные дистрибутивы сохранятся в DPM. Для этих дистрибутивов будет доступен ручной выбор конвейера.

Внимание!

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

Деактивация ОРД#

Для деактивации ОРД:

1. Откройте страницу ОРД.

2. В меню нажмите кнопку Деактивировать.

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

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

• остановить отдельный дистрибутив;

• в очереди на запуск выделить все требуемые дистрибутивы и отложить их выполнение/удалить из очереди;

• на основной странице ОРД выберите дистрибутивы и архивируйте их.

Редактирование объектов релизной деятельности (ОРД)#

Вы можете редактировать поля ОРД, отвечающие за разбор дистрибутивов, отображение, фильтрацию, права доступа в Nexus или Jira. Изменение репозитория, с которым синхронизируется DPM, невозможно.

Для редактирования ОРД:

1. Откройте страницу ОРД.

2. В меню "Действия" выберите "Редактировать ОРД" (см. Рисунок 22).

Рисунок 22. Меню выбора функции редактирования

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

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

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

Рисунок 23. Окно списка изменений

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

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

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

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

1. Откройте страницу ОРД.

2. В меню "Действия" выберите пункт "Конвейеры ОРД" (см. Рисунок 24).

Рисунок 24. Меню выбора функции "Конвейеры ОРД"

3. На странице конвейеров нажмите кнопку Создать конвейер (см. Рисунок 25).

Рисунок 25. Страница создания конвейера

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

• наименование конвейера;

• описание (опционально).

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

Для настройки порядка этапов конвейера (см. Рисунок 26):

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

Рисунок 26. Страница редактирования конвейера

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

Рисунок 27. Добавление этапов в блок конвейера

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

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

1. Нажмите кнопку Настроить, а затем выберите пункт "Настроить фазы" (см. Рисунок 28).

Рисунок 28. Окно редактирования конвейеров

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

Рисунок 29. Настройка порядка фаз

Jenkins — в этой фазе выполняется задание Jenkins (job);

Ручная фаза — фаза для ручного тестирования; в этой фазе можно оставлять комментарии, например, пункт о протоколе тестирования;

Service — в этой фазе доступен подтип:

• для публикации Quality gates в виде Nexus classifier;

• для подготовки к передачи дистрибутива в ФПД (фонд программ и документации). Выберите Тип фазы;

• задайте название (обязательно); это название позволяет отличить создаваемую фазу от других фаз; пример: Deploy IFT;

• выберитеРежим запуска (обязательно); доступны автоматический и ручной режимы. В ручном режиме перед запуском фазы будет создана задача, которая будет назначена на пользователей, отвечающих за этап; запуск произойдет после подтверждения. В автоматическом режиме запуск фазы произойдет сразу после публикации артефактов в Nexus или после перехода на эту фазу. Поддерживается автоматический выбор режима запуска в зависимости от условий (см. Условия запуска фаз);

• выберите задание Job (обязательно для типа Jenkins фазы) — полный URL задания Jenkins (job). URL будет проверен. Если Jenkins нет в списке, обратитесь к администраторам (см. Рисунок 30);

• выберите учетную запись (логин) и токен АС, ФП или ОРД; вводить заново нужно, если для конкретного запуска не подходят настройки верхних уровней. Учетную запись, используемую для запуска на выбранном экземпляре Jenkins, можно выбрать на странице редактирования ОРД, ФП или АС;

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

Рисунок 30. Пример настроек

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

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

• Stage Jenkins job (опционально) — этапы задания конвейера job, статусы прохождения которых необходимо фиксировать в DPM, влияют на прохождение фазы;

• режим валидации (обязательно):

• в ручном режиме переход на следующую фазу или этап происходит после подтверждения ответственного пользователя;

• в автоматическом (ручной для Failed) режиме переход к следующей фазе или этапу будет автоматическим при условии положительного статуса задания Jenkins job). При этом автоматически подтверждается или отклоняется выполнение фазы согласно ответу от Jenkins;

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

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

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

Выберите задание и проверьте в нем, какие модули изменились. Затем установите в DPM значение переменной NeedLT в true или false. Передайте текущее значение переменной в задание, в рамках которого выполняется нагрузочное тестирование.

Добавление QG флагов в Nexus#

Список шлюзов Quality Gate#

DPM поддерживает создание в Nexus следующих QG:

• QG.CI.1 Static Code Analysis;

• QG.CI.2 API First Check;

• QG.CI.3 SAST;

• QG.CDL.1 BVT;

• QG.CDL.2 Dev LT;

• QG.CDL.3 Smoke ST;

• QG.CDL.4 Smart Regress ST;

• QG.CDL.5 NF ST;

• QG.CDL.6 Smoke IFT;

• QG.CDL.7 Smart Regress IFT;

• QG.CDL.8 NF IFT;

• QG.CDL.9 DAST;

• QG.CDL.10 LT;

• QG.CDP.1 Smoke UAT;

• QG.CDP.2 Smart Regress UAT;

• QG.CDP.3 NF UAT.

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

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

Для отказа от встраивания в свой конвейер Jenkins функции добавления флагов в Nexus (см. Рисунок 31):

1. Откройте страницу ОРД, в рамках которого нужно настроить автоматическое проставление QG.

2. Откройте страницу конфигурации конвейеров.

Рисунок 31. Страница конфигурации конвейеров

3. Создайте новый конвейер, либо откройте для редактирования ранее созданный (см. Рисунок 32).

Внимание!

Редактирование активного конвейера запрещено. Для внесения изменений в такой конвейер, скопируйте его, настройте, а затем активируйте.

Рисунок 32. Страница выбора конвейера

4. Нажмите нужный вам этап в конвейере (см. Рисунок 33), в рамках которого вы хотите настроить добавление флагов в Nexus.

Рисунок 33. Выбор этапа конвейера

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

В примере (см. Рисунок 34) добавляются шлюзы QG API First Check и Static Code Analysis. Механизм добавления QG запускается автоматически. При успешном добавлении QG выполнение конвейера продолжится. Описанный конвейер добавляет QG, только при успешном выполнении фаз Deploy и Test.

Рисунок 34. Пример добавления шлюзов QG API First Check и Static Code Analysis.

6. Сохраните конфигурацию этапа и конфигурацию конвейера; предварительно убедитесь, что все этапы в вашем конвейере настроены корректно (см. Рисунок 35).

Рисунок 35. Сохранение конфигурации

7. Активируйте ранее созданный или измененный конвейер.

8. Убедитесь, что конвейер по умолчанию соответствует тому, который вы создавали или редактировали.

Новые релиз-кандидаты, будут автоматически добавлять QG (см. Рисунок 36).

Рисунок 36. Итоговая страница измененной конфигурации конвейера

Внешний вид в конвейере фазы добавления флагов QG#

В примере изображен конвейер ОРД, в котором фаза PUT QG добавляет флаг API First Check. Используется конвейер, в котором исполнение этапа Release Team не будет завершено, пока не появится флаг API First Check.

Рисунок 37. конвейер ОРД, в котором фаза PUT QG добавляет флаг API First Check

Для получения детальной информации о том, какие именно флаги будут проставлены в Nexus, нажмите кнопку многоточия (…) (см. Рисунок 37).

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

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

Работа QG JOB: добавляются все QG, которые были настроены в рамках фазы. Успех добавления в Nexus проверяется. При ошибке проверки QG в Nexus фаза считается неуспешной.

DPM не поддерживает работу с пользовательскими QG, но дает возможность обрабатывать предустановленный список.

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

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

Внимание!

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

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

Для создания профиля конвейера ОРД (см. Рисунок 38):

1. Откройте страницу конвейеров ОРД.

Рисунок 38. Страница конвейеров ОРД

2. Нажмите кнопку Профиль.

3. В открывшемся меню нажмите кнопку Создать (см. Рисунок 39).

Рисунок 39. Создать профиль

3. Заполните поля (сопоставить набор дистрибутивов с конвейером) (см. Рисунок 40):

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

Рисунок 40. Создание профиля

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

Рисунок 41. Определение конвейера профиля

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

Профиль создан.

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

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

Внимание!

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

Рисунок 42. Приоритизация профилей

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

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

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

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

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

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

1. Откройте вкладку "Глобальные конвейеры" в режиме редактирования (см. Рисунок 43).

Рисунок 43. Панель "Глобальные конвейеры"

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

3. Выберите изменяемые переменные. Такие переменные могут меняться от модуля к модулю. Например, адреса стендов, названия модулей разных модулей могут отличаться друг от друга.

4. Добавьте выбранные переменные в список параметров (см. Рисунок 44).

Рисунок 44. Панель добавления переменных

Для каждой переменной (см. Рисунок 45) можно задать значение по умолчанию. Если на нижних уровнях (например, в ФП или ОРД) не будет переопределено другое значение, для запуска используется значение по умолчанию.

Рисунок 45. Панель ввода значений

Используйте переменные в параметрах запуска Jenkins. В поле значения параметра начните вводить ${. DPM предложит варианты значений (см. Рисунок 46).

Рисунок 46. Панель "Настройка фазы". Ввод значения

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

При работе с ОРД существуют глобальные конвейеры, определенные на всю проектную область (АС) или функциональную подсистему.

Для переопределения переменных:

1. Перейдите в режим редактирования ФП или на страницу конвейеров ОРД.

2. Найдите нужный конвейер, а затем откройте переменные и задайте новые значения (см. Рисунок 47).

Рисунок 47. Диалог переопределения переменных

Операции с конвейерами#

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

• Available — полностью настроенный конвейер, который можно добавить в профиль или применить к отдельному релиз-кандидату;

• Draft — черновик конвейера, не хватает настроек;

• Archived — архивные конвейеры, которые больше не используются.

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

1. Откройте страницу ОРД.

2. В меню Действия нажмите Конвейеры ОРД (см. Рисунок 48).

Рисунок 48. Меню выбора действия

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

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

Копирование в рамках одного ОРД#

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

Копирование в другой ОРД#

Для копирования конвейеров между разными ОРД используйте кнопку копирования между ОРД . Выберите одну или несколько ОРД (см. Рисунок 49), куда будет скопирован конвейер, а затем нажмите кнопку Экспортировать.

Рисунок 49. Меню выбора ОРД

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

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

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

Для экспорта конфигурации (см. Рисунок 50):

1. Откройте страницу конвейеров.

2. В строке действий с конвейером нажмите кнопку Экспортировать в JSON.

Рисунок 50. Переход в режим экспорта конфигурации

Скачается файл конфигурации.

Для импорта конфигурации:

1. Откройте страницу списка релиз-кандидатов.

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

3. Переместите курсором мыши файл в формате JSON в форму (или следуйте подсказкам на форме) (см. Рисунок 51).

Рисунок 51. Форма режима импорта

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

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

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

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

1. Откройте страницу конвейеров. Функция редактирования доступна для конвейеров в статусах Available и Draft.

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

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

Для архивирования конвейера:

1. Откройте страницу конвейеров. Функция архивирования доступна для конвейеров в статусах Available и Draft.

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

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

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

Условия проверяются сверху вниз, если ни одно из условий не выполняется, используется режим запуска по умолчанию (см. Рисунок 52).

Рисунок 52. Выбор условия запуска фаз

Условия описываются логическим выражением, для его описания доступны операции, описанные в следующей таблице (Таблица 29).

Таблица 29 — Операции для описания логического выражения

Примеры

${version} == #{КЛЮЧ_ОРД.lastVersion} and (${time_param} in ("MORNING", "DAY") or ${needLT.ST} != false)

Текущая версия совпадает с последней версией ОРД (КЛЮЧ_ОРД можно посмотреть на странице ОРД или скопировать из URL) и выполняется одно из условий: значение переменной time_param равно MORNING или DAY или значение переменной needLT на этапе ST не равно false.

Настройка фазы для регистрации дистрибутива в ФПД#

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

Настройка ФПД фазы#

1. Перейдите к редактированию конвейера (Страница ОРД), выберите пункт "Действия", а затем выберите пункт "Конвейеры ОРД".

2. Добавьте фазу в нужный этап конвейера (например, ПСИ).

3. Выберите тип фазы "Сервисная" (см. Рисунок 53).

4. Выберите пункт ФПД.

Рисунок 53. Настройка ФПД фазы

Для запуска задайте поля:

• ID Релиза — ключ задачи в JIRA;

• Версия дистрибутива — версия дистрибутива по стандарту (например, D- 03.033.00_123 или с помощью встроенных переменных D-${dpmRelease}-${version});

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

Параметры можно вводить при подтверждении запуска ФПД фазы: измените тип параметра со значения "Простой" на значение "Запрашиваемый".

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

Запуск фазы#

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

Рисунок 54. Запуск фазы

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

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

Для просмотра истории:

1. Откройте страницу релиз-кандидата.

2. В меню "Дополнительно" нажмите кнопку История (см. Рисунок 55).

Рисунок 55. Меню "Дополнительно"

История сгруппирована по событиям фазы этапа. Для просмотра истории предыдущих запусков нажмите кнопку Загрузить еще… (см. Рисунок 56).

Рисунок 56. Страница "История релиз-кандидата"

Применение, остановка, возобновление конвейера#

Применение конвейера#

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

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

1. Откройте страницу релиз-кандидата (см. Рисунок 57).

2. В списке конвейеров выберите конвейер, который нужно запустить.

Рисунок 57. Страница релиз-кандидата

3. Подтвердите запуск (см. Рисунок 58).

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

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

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

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

1. Откройте страницу релиз-кандидата.

2. В поле "Конвейер" выберите Не выбран > Остановить конвейер (см. Рисунок 59).

Рисунок 59. Остановить конвейер

Прерывание конвейера#

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

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

1. Откройте страницу релиз-кандидата.

2. Откройте меню "Действия", а затем нажмите кнопку Прервать конвейер (см. Рисунок 60).

Рисунок 60. Прерывание конвейера

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

Возобновление конвейера#

Для возобновления конвейера:

1. Откройте страницу релиз-кандидата.

2. Откройте меню "Действия", а затем нажмите кнопкуВозобновить (см. Рисунок 61).

Рисунок 61. Возобновление конвейера

Доступы для инструмента управления развертыванием ПО (Jenkins)#

Инструмент управления развертыванием ПО#

Для любого экземпляра доступы быть заданы на уровнях проектной области (АС), функциональной подсистемы (ФП) или объекта релизной деятельности (ОРД). Действия для всех уровней одинаковы.

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

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

• проверяется задание собственных учетных данных (учетной записи и токена) в текущей фазе;

• если на уровне фазы нет, выполняется проверка наличия фазы на ОРД, затем проверяется наличие фазы на ФП, а последним шагом проверяется наличие фазы в АС, пока не будут найдены доступы.

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

• задание собственных учетных данных (учетной записи и токена) в текущей фазе;

• наличие личного токена, запускающего фазу пользователя;

• наличие на ОРД, после этого на ФП и АС, пока не будут найдены доступы.

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

Доступы АС/ФП/ОРД#

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

1. Откройте страницу редактирования АС/ФП/ОРД (см. Рисунок 62).

2. Откройте вкладку "Доступы к Jenkins".

Рисунок 62. Страница редактирования АС/ФП/ОРД

3. В поле Поиск введите имя своей учетной записи. можно воспользоваться URL Jenkins или названием экземпляра Jenkins.

4. Укажите имя своей учетной записи и токен.

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

Личный токен#

Личный токен можно использовать при ручном запуске фазы.

Для задания личного токена:

1. В меню пользователя выберите Мои токены (см. Рисунок 63).

Рисунок 63. Меню пользователя

2. Выберите нужный экземпляр Jenkins (см. Рисунок 64), а затем задайте токен своей учетной записи.

Рисунок 64. Страница экземпляра Jenkins

Ответственный за этап#

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

Работа с пользовательскими задачами и отложенный запуск#

Варианты состояния пользователей, назначенных на задачу для текущего этапа:

• если задан ответственный пользователь, то задача назначается на всех ответственных за этап;

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

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

Рисунок 65. Отображение счетчика задач

Типы доступных задач пользователя:

• задача подтверждения запуска;

• задача проверки результатов выполнения задания Jenkins.

Для просмотра задач, нажмите значок актуальных задач (см. Рисунок 66).

Рисунок 66. Панель просмотра активных задач

Для просмотра списка всех задач нажмите кнопку Показать еще … задач(и). Откроется полный список задач (см. Рисунок 67).

Рисунок 67. Полный список задач

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

1. Откройте карточку задачи текущего этапа.

2. Для отложенного запуска активируйте (опционально) флаг Отложенный запуск (см. Рисунок 68).

3. Выберите дату и время запуска задачи.

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

Рисунок 68. Настройка отложенного запуска

Задача проверки создается в следующий случаях:

• значение конечного статуса задания Jenkins (job) или статуса заданных стадий Jenkins (stages) отлично от SUCCESS;

• при конфигурировании фазы назначен ручной режим проверки.

Для выполнения задачи проверки:

1. Откройте карточку задачи текущего этапа, в которой отображается статус задания оркестратора (см. Рисунок 69).

Рисунок 69. Подтверждение/отклонение выполнения фазы

2. Нажмите кнопку Подтвердить, чтобы завершить фазу.

3. Нажмите кнопку Отклонить, чтобы отметить фазу незавершенной.

Перезапуск этапа релиз-кандидата#

При перезапуске этапа статус выполнения задачи по следующим этапам архивируется (за исключением параллельных этапов). Такие этапы следует пройти повторно.

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

1. Откройте страницу релиз-кандидата.

Рисунок 70. Этапы релиз-кандидата

2. Выберите требуемый этап (см. Рисунок 70), а затем нажмите кнопку перезапуска.

3. В открывшемся окне измените параметры запуска (опционально), выбрав флаг "Перезапуск с изменением параметров".

4. Нажмите кнопку Перезапустить.

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

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

Просмотр журналов Jenkins#

Для получения информации о выполненном задании Jenkins вы можете просматривать журналы Jenkins. DPM предоставляет собственное хранилище журналов выполненных заданий Jenkins (job). Это хранилище независимо от Jenkins его настроек.

Для просмотра журнала Jenkins:

1. Откройте страницу релиз-кандидата.

2. Выберите фазу, для которой нужно отобразить журнал выполнения заданий Jenkins (см. Рисунок 71).

3. В строке Job log нажмите кнопку Open log.

Рисунок 71. Страница журнала фазы

Откроется вкладка журнала заданий Jenkins.

Просмотр журнала событий прохождения релиз-кандидата#

Для просмотра событий релиз-кандидата (см. Рисунок 72):

1. Откройте страницу релиз-кандидата.

2. Нажмите кнопку Показать историю РК.

Рисунок 72. Журнал событий релиз-кандидата для выбранной фазы

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

Работа с переменными#

Здесь описана работа с переменными, значение которых может быть изменено из Jenkins при передаче информации между заданиями Jenkins.

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

При конфигурации заданий Jenkins (job) в разделе параметров можно использовать системные и пользовательские переменные окружения. В DPM применяются строковые литералы (функция String Literals) в реализации Apache Commons [StrSubstitutors].

Для передачи значения переменной в Jenkins следует экранировать название переменной метасимволами, например: ${НАЗВАНИЕ_ПЕРЕМЕННОЙ}.

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

Базовая настройка#

Переменные пользователя позволяют управлять своим значением из Jenkins.

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

1. Откройте страницу настройки конвейера (см. Рисунок 73), а затем нажмите кнопку Добавить параметр.

Рисунок 73. Страница настройки конвейера

2. В параметрах задания Jenkins передайте встроенную переменную ${externalKey}; это необходимо для обновления переменной в DPM из задания Jenkins (job);

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

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

• ${НАЗВАНИЕ_ПЕРЕМЕННОЙ.НАЗВАНИЕ_ЭТАПА}; например, в переменную ${result.ST} передастся последнее значение, обновленное фазой этапа ST;

• ${НАЗВАНИЕ_ПЕРЕМЕННОЙ}; например, в переменную ${result} передастся последнее обновленное значение любого этапа или фазы.

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

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

Внимание!

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

Пример

Есть есть две фазы в шаге DEV:

• фаза Deploy1 (ключ фазы Dpl#1);

• фаза Deploy2 (ключ фазы Dpl#2).

В фазе с ключом Dpl#1 вы заполняете переменную result задания Jenkins (job), присваивая ей значение A1. В фазе с ключом Dpl#2 вы заполняете ту же переменную result значением B2. Во все следующие фазы всех этапов можно передавать переменные:

${result.DEV.Dpl#1}=A1
${result.DEV.Dpl#2}=B2
${result.DEV}=B2
${result}=B2

Чтобы заполнить переменную result еще раз на этапе ST фазы Deploy1 с ключом Dpl#3 и передать в нее значение C3:

${result.ST.Dpl#3}=C3
${result.ST}=C3
${result.DEV}=B2
${result

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

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

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

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

Таблица 30 — Описание значений параметра

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

Помимо данных о дистрибутиве можно получить данные о запуске конвейера (Таблица 31). Например, статусы выполнения заданий Jenkins, статусы фаз. Эти данные можно использовать в условиях запуска конвейера для автоматизации процесса развертывания.

Таблица 31 — Параметры развертывания

Пример использования переменных контекста и статуса развертывания приведен на рисунке (см. Рисунок 74).

Рисунок 74. Пример использования переменных контекста

Проверка параметров запуска задания Jenkins#

Можно проверить параметры, с которыми будет запущено задание Jenkins.

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

1. Запустите конвейер с тестовым пустым заданием.

2. На странице релиз-кандидата нажмите значок информации о фазе.

3. В таблице параметров в столбце "Вычислено" отображаются данные, актуальные на момент открытия окна (см. Рисунок 75).

Рисунок 75. Проверка параметров запуска задания

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

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

Переменные из контекста функциональной подсистемы и ОРД#

В DPM можно использовать общие параметры для функциональной подсистемы или ОРД, к которым можно обращаться по ключу ФП или ОРД. Можно определить пользовательские переменные для ФП и ОРД.

Для ОРД доступны системные параметры (Таблица 32):

• groupId;

• artifactId;

• nexusUrl;

• lastVersion;

• lastVersionUrl;

• lastSuccessVersion.

Таблица 32 — Пример использования системных параметров ОРД

При настройке конвейера в параметре запуска задания следует указать #{КЛЮЧ_ОРД.groupID}.

Создание параметра ФП или ОРД#

Для создания параметра ФП или ОРД:

1. Откройте ФП или ОРД в режиме редактирования (см. Рисунок 76).

Рисунок 76. Страница редактирования ФП

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

3. Укажите ключ (ключ будет использован при передаче в Jenkins) и значение ключа.

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

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

1. Откройте страницу настройки конвейера, а затем перейдите к блоку параметров (см. Рисунок 77).

2. В значение параметра введите строку: #{key.var_name}, где key — ключ ФП или ОРД, var_name — название переменной, заданное в ФП или ОРД.

3. Определите ключ ФП/ОРД:

Рисунок 77. Ключи DPM

Quality Gates#

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

Чтобы публиковать флаги в Quality Gates, нужно использовать один из следующих инструментов:

DevOps Pipeline Management (DPM):

• если вы уже используете DPM, никаких дополнительных настроек не требуется. Механизм публикации флагов уже встроен в систему сервиса;

• если вы не используете DPM, но хотите на него перейти, ознакомьтесь с руководством по установке;

• библиотека DPM_pipeline_utils v1.3+. Если вы используете данную библиотеку, убедитесь в актуальности версии:

  • версия 1.3 публикует флаги параллельно в хранилища (Nexus и ФП Quality Gates);

  • версия 1.4 публикует флаги только в ФП Quality Gates;

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

если вы никогда не использовали библиотеку DPM_pipeline_utils, ознакомьтесь с инструкцией по настройке Shared Lib, представленной ниже.

Инструкция по настройке Shared Lib#

1. Перейдите в папку Jenkins (см. Рисунок 78), в которой нужно добавить Shared Lib и нажмите кнопку Configure.

Рисунок 78. Папка Jenkins

2. Перейдите к разделу "Pipeline Libraries" и настройте библиотеку. Для этого заполните следующие поля (см. Рисунок 79):

• Name: dpm-pipe — имя библиотеки для обращения в скриптах;

• Default version: 1.0 — версия библиотеки, которую нужно будет использовать по умолчанию);

• Repository URL — ссылка на репозиторий. Ссылку на git репозиторий можно посмотреть в инструменте управления исходного кода и конфигураций, нажав кнопку Clone;

• Credentials — логин технической учетной записи с доступом в инструмент управления исходного кода и конфигураций.

Рисунок 79. Заполнение полей для настойки библиотеки

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

//Объявляем использование Shared Lib с именем "dpm-pipe" и версией "1.0"
@Library("dpm-pipe@1.0") _
//Выбираем Node на которой будет исполнятся наш pipeline
node("Linux_Default"){
stage('Set variable') {
//Задаем значение переменной "my_var" в DPM, значением "varValue". Если varValue будет не строка, то при отправке будет использовано значение varValue.toString()
//externalKey- параметр, который передается из DPM в Jenkins.
setDpmVar(env.externalKey, "my_var", varValue)
}
}

Основные функции инструмента#

Примеры методов публикации флагов Quality Gates с помощью библиотеки DPM_pipeline_utils v.1.4.#

Code Block 1 Публикация флага для maven-проектов

@Library('DPMPipelineUtils@1.4') _

stage('Upload Flag With Maven Project') {
steps {
script {
qg = qualityGates() //Создаем объект ReleaseNotes
.readPropsFromPomFile("application/pom.xml") //Забираем доступную информацию из pom.xml файла
.setNexusCredsId("DPM_CI_USER_LOGIN_PASSWORD") //Jenkins Credentials ID для публикации ReleaseNotes в Nexus

.uploadFlag("bvt", "ok") //Загружаем флаг
}
}
}

Code Block 2 Универсальный метод публикации

@Library('DPMPipelineUtils@1.4') _

stage('Upload Flag Basic Usage') {
steps {
script {
qg = qualityGates() //Создаем объект библиотеки
.setGroup("Nexus_PROD.ru").setArtifact("dpm").setVersion("1.0.0") //Задаем GAV параметры
.setNexusUrl("Nexus URL")
.setArtifactRepository("Nexus_PROD") //Задаем параметры Nexus
.setNexusCredsId("NEXUS_CREDENTIALS_ID") //Идентификатор Jenkins Credentials для доступа к Nexus

.uploadFlag("bvt", "ok") //Загружаем флаг
}
}
}

Code Block 3 Публикация флага с изменением его содержимого

@Library('DPMPipelineUtils@1.4') _

stage('Upload Flag With Custom Body') {
steps {
script {
qg = qualityGates() //Создаем объект библиотеки
.setGroup("Nexus_PROD.ru").setArtifact("dpm").setVersion("1.0.0") //Задаем GAV параметры
.setNexusUrl("Nexus URL") //Задаем параметры Nexus
.setArtifactRepository("Nexus_PROD")
.setNexusCredsId("NEXUS_CREDENTIALS_ID")

.uploadQGFlag("bvt_ok", "BVT_FLAG uploaded by Nicolay") //Загружаем флаг, тело файла будет содержать строку из второго аргумента
}
}
}

Примеры методов проверки наличия флагов в ФП Quality Gates с помощью библиотеки DPM_pipeline_utils v.1.4.#

Code Block 4 Проверка наличия флага с помощью библиотеки DPM_pipeline_utils

/**
*
* @param flag - name of flag in QG List -> for example: dev, lt, smoke_ift. Should be without status postfix // RU_ru: Название флага, без постфикса со статусом (_ok|_err)
* @return true if flag exists and last flag's status is OK
*/
boolean isLastFlagOk(String flag)
//Usage examples
@Library('DPMPipelineUtils@1.3') _
stage('Check Flag') {
steps {
script {
qg = qualityGates() //Создаем объект библиотеки
.setGroup("Nexus_PROD.ru").setArtifact("dpm").setVersion("1.0.0") //Задаем GAV параметры
.setNexusUrl("Nexus URL") //Задаем параметры Nexus
.setArtifactRepository("Nexus_PROD")
.setNexusCredsId("NEXUS_CREDENTIALS_ID")

qg.isLastFlagOk("bvt") //Вернет true, если флаг bvt есть
}
}
}

Quality Gates Manager (работа в UI)#

Для работы с данными ФП Quality Gates предназначено пользовательское веб-приложение Quality Gates Manager.

Инструкции пользователя Quality Gates Manager (QGM)#

Просмотр информации о статусе прохождения дистрибутивом DevOps Quality Gates#

1. Получите доступ в пространство в QGM.

2. После получения доступа перейдите в QGM.

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

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

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

• если вы являетесь администратором пространства, воспользуйтесь инструкциями раздела "Пользователи и права";

• если вы не являетесь администратором пространства:

1. Запросите доступ, для этого заполните заявку по шаблону.

2. После получения доступа воспользуйтесь инструкциями раздела "Пользователи и права".

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

Создание или изменение кастомных флагов#

• если вы являетесь администратором пространства, воспользуйтесь инструкциями на странице "Создание нового кастомного флага Quality Gates";

• если вы не являетесь администратором пространства:

1. Запросите доступ, для этого заполните заявку по шаблону "Получить доступ к пространствам".

2. После получения доступа воспользуйтесь инструкциями на странице "Создание нового кастомного флага Quality Gates".

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

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

Проект в QGM создается автоматически в момент публикации флагов. Обязательное условие — использование библиотеки DPMPipelineUtils v.1.3+ или DPM.

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

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

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

Получение доступа в пространство в QGM#

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

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

Получение консультации, сообщение о проблеме#

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

Раздел "Пространства"#

Вносить любые изменения в данные пространства могут только пользователи с ролью "Администратор QGM" или "Администратор пространства".

Раздел содержит список существующих в QGM Пространств (в т. ч. перечень входящих и их состав проектов), а также предполагает функционал для создания нового пространства.

Для перехода в карточку пространства нажмите его название (см. Рисунок 80).

Рисунок 80. Переход в карточку пространства

В таблице (Таблица 33) описана Карточка пространства.

Таблица 33 — Карточка пространства

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

Описание этапов создания пространства для роли "Администратор QGM" представлено в таблице (Таблица 34).

Таблица 34 — Создание пространства

Предоставление пользователю доступа в пространство#

Последовательность шагов для доступа в пространство пользователей с разными ролями представлена в таблице
(Таблица 35).

Таблица 35 — Доступ в пространство

Создание нового кастомного флага Quality Gates#

Этапы создания нового кастомного флага Quality Gates представлены в таблице (Таблица 36).

Таблица 36 — Создание нового кастомного флага Quality Gates

Раздел "Пользователи и права"#

Раздел содержит следующие подразделы:

• роли (см. Рисунок 81):

• создание/редактирование/удаление ролей (на уровне QGM, пространств или проектов);

• просмотр всех текущих ролей в QGM;

Рисунок 81. Панель "Роли системы"

• системные роли (см. Рисунок 82):

Рисунок 82. Панель "Системные роли"

• назначенные права (см. Рисунок 83):

• назначение точечных прав для пользователей;

• просмотр всех предоставленных для пользователя прав (какой пользователь, какое право, в рамках какой сущности (проект, пространство и т. д.) имеет);

Рисунок 83. Назначенные права

• пользователи (см. Рисунок 84):

• просмотр перечня всех пользователей QGM (в т. ч. ТУЗ);

• администратор QGM имеет возможность внесения правок в имя и e-mail пользователей;

Рисунок 84. Панель "Пользователи"

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

Этапы создания роли для пользователя представлены в таблице ниже (Таблица 37).

Таблица 37 — Создание роли пользователю

Назначение роли пользователю#

Этапы назначения роли пользователю представлены в таблице ниже (Таблица 38).

Таблица 38 — Назначение роли пользователю

Флаги#

Доступ: всем пользователям в рамках своих проектов/пространств.

Описание: подраздел содержит информацию по всем флагам QG, поступившим в ФП "Quality Gates".

Для просмотра информации перейдите в раздел Данные -> Флаги
(см. Рисунок 85, Рисунок 86).

Рисунок 85. Переход в раздел "Данные"

Рисунок 86. Переход в раздел "Флаги"

Описание полей интерфейса на странице "Флаги" представлено в таблице (Таблица 39).

Таблица 39 — Описание интерфейса

Раздел "Проекты"#

Состав раздела указан в таблице (Таблица 40).

Таблица 40 — Состав раздела

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

Описание этапов создания и редактирования проекта представлено в таблице (Таблица 41).

Таблица 41 — Создание и редактирование проекта

Предоставление ТУЗ доступа к проекту (чтение и запись флагов)#

Возможны два варианта выдачи прав:

• точечное предоставление прав (Таблица 42);

• создание и присвоение роли;

Таблица 42 — Точечное предоставление прав

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

Создание и присвоение роли для ТУЗ описано на странице "Создание и назначение роли пользователю".

Предоставление пользователю (не ТУЗ) доступа к проекту#

Этапы процедуры предоставления пользователю (не ТУЗ) доступа к проекту представлены в таблице (Таблица 43).

Таблица 43 — Предоставление пользователю (не ТУЗ) доступа к проекту