Интеграция с управлением изменениями ServiceNow

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Azure Pipelines поддерживает интеграцию с ServiceNow для улучшения совместной работы между разработками и ИТ-командами. Включив управление изменениями в конвейеры выпуска, команды могут снизить риски, связанные с изменениями, и следовать методологиям управления службами, таким как ITIL, используя все преимущества Azure Pipelines.

В этой статье вы узнаете, как выполнять следующие задачи.

Необходимые компоненты

• В этом руководстве рассматривается использование утверждений и шлюзов и определение утверждений и проверка.

• Организация Azure DevOps. Создайте организацию, если у вас еще нет.

• Экземпляр ServiceNow, отличный от разработчика.

Настройка экземпляра ServiceNow

1. Установите расширение Azure Pipelines в экземпляре ServiceNow. Для завершения установки потребуются учетные данные Hi . Дополнительные сведения об установке приложений из магазина ServiceNow см. в разделе " Обзор покупки ".

2. Создайте пользователя в ServiceNow и предоставьте ей следующую роль: x_mioms_azpipeline.pipelinesExecution

   

Настройка организации Azure DevOps

1. Установите расширение ServiceNow Change Management в организации Azure DevOps.

   

2. Создайте подключение службы ServiceNow в проекте Azure DevOps следующим образом. Кроме того, можно использовать проверку подлинности OAuth2.

   

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

1. Перейдите к конвейеру выпуска и щелкните значок условий предварительного развертывания. Выберите Гейтс и шлюз управления изменениями ServiceNow перед развертыванием.

   

2. Выберите подключение службы, созданное ранее, и заполните необходимые поля следующим образом:

   

   • Подключение ServiceNow: Подключение ion к экземпляру ServiceNow, используемому для управления изменениями.
   • Краткое описание: сводка по изменению.
   • Описание: подробное описание изменения.
   • Категория: категория изменения. Пример: оборудование, сеть, программное обеспечение.
   • Приоритет: приоритет изменения.
   • Риск: уровень риска для изменения.
   • Влияние: влияние изменения на бизнес.
   • Элемент конфигурации: элемент конфигурации (CI), к которому применяется изменение.
   • Группа назначений: группа, к которому назначено изменение.
   • Расписание запроса на изменение: расписание изменения в соответствии с рабочим процессом ServiceNow. Дата и время должны быть в формате UTC и форматом y-MM-ddTHH:mm:ssZ. Пример: 2018-01-31T07:56:59Z.
   • Дополнительные параметры запроса на изменение: имя должно быть именем поля (не меткой), префиксом "u_". Пример: u_backout_plan. Значение должно быть допустимым значением в ServiceNow. Недопустимые записи игнорируются.
   • Требуемое состояние запроса на изменение: шлюз завершится успешно, и конвейер продолжается, когда состояние запроса на изменение совпадает с указанным значением.
   • Дополнительно. Указывает выражение, которое управляет выполнением этого шлюза. Запрос на изменение определяется как root['result'] в ответе serviceNow. Пример : "and(eq(root['result'].state, 'New'),eq(root['result'].risk, 'Low'))". Дополнительные сведения см . в выражениях .
   • Выходные переменные: необходимо указать имя ссылки, чтобы использовать выходные переменные в рабочем процессе развертывания. Переменные шлюза можно получить с помощью preDEPLOYGATE в качестве префикса в задании без агента. Например, если для имени ссылки задано значение "gate1", номер изменения можно получить следующим образом: $(PREDEPLOYGATE.gate1.CHANGE_REQUEST_NU МБ ER).
   • CHANGE_REQUEST_NU МБ ER: число запроса на изменение.
   • CHANGE_SYSTEM_ID: системный идентификатор запроса на изменение.

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

   

• Подключение ServiceNow: Подключение ion к экземпляру ServiceNow, используемому для управления изменениями.
• Номер запроса на изменение: номер запроса на изменение для обновления.
• Обновлено состояние запроса на изменение: состояние, заданное для запроса на изменение. Этот вход доступен, если выбрано состояние обновления.
• Закройте код и закройте заметки: состояние возврата.

Создание конвейера выпуска

1. Выберите "Создать выпуск", чтобы запустить новый конвейер выпуска.

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

   

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

   

4. Запрос на изменение будет помещен в очередь в ServiceNow и может просматриваться владельцем изменений.

   

5. Конвейер выпуска, активировав новый запрос на изменение, можно найти в разделе метаданных Azure DevOps Pipeline.

   

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

   

7. Запрос на изменение будет автоматически закрыт после развертывания.

Конвейеры Yaml

В этом руководстве предполагается, что у вас есть конвейер yaml с одним этапом развертывания в "последней" среде.

Добавление проверка

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

2. Выберите знак "плюс", чтобы добавить новую проверка, а затем добавьте в среду проверка serviceNow Change Management. Используйте ту же конфигурацию, которую вы использовали для шлюза предварительного развертывания.

   

Добавление задачи yaml

1. Добавьте задание сервера на этап, чтобы обновить запрос на изменение.

   

2. Сохраните и запустите конвейер. Новый запрос на изменение будет создан автоматически, и конвейер приостановится и дождется завершения проверка.

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

Вопросы и ответы

Вопрос. Какие версии ServiceNow поддерживаются?

Вопрос. Какие типы запросов на изменение поддерживаются?

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

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

Ответ. Можно указать дополнительные свойства изменений из поля "Дополнительные параметры запроса на изменение". Используйте формат JSON пар "ключ-значение" с именем поля (а не меткой) с u_префиксом .

Вопрос. Можно ли обновить настраиваемые поля в запросе на изменение с дополнительными параметрами запроса на изменение?

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

Вопрос. Я не вижу раскрывающихся значений, заполненных для полей "Категория", "Состояние" и "Другие". Что делать?

Ответ. Подключаемые модули модели управления состоянием и управление изменениями должны быть активными в экземпляре ServiceNow для работы раскрывающихся списков. Дополнительные сведения см. в разделе "Управление изменениями " и " Обновление запросов на изменение".

Ресурсы

• Настройка конвейеров выпуска для безопасных развертываний
• Тональность Twitter в качестве ворот выпуска
• Проблемы с GitHub в качестве шлюза выпуска
• Создание пользовательских шлюзов.
• Пример библиотеки ServerTaskHelper

Связанные статьи

• Выпуск шлюзов и утверждений
• Определение утверждений и проверок
• Настройка вмешательства вручную
• Использование шлюзов и утверждений для управления развертыванием
• Добавление этапов, зависимостей и условий
• Триггеры выпуска