ServiceNow 변경 관리와 통합
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure Pipelines는 ServiceNow와의 통합을 지원하여 개발 팀과 IT 팀 간의 협업을 개선합니다. 릴리스 파이프라인에 변경 관리를 포함하면 팀은 Azure Pipelines를 최대한 활용하면서 변경과 관련된 위험을 줄이고 ITIL과 같은 서비스 관리 방법을 따를 수 있습니다.
이 문서에서는 다음을 수행하는 방법을 알아봅니다.
- ServiceNow 인스턴스를 구성합니다.
- ServiceNow 변경 관리 프로세스를 릴리스 게이트로 포함합니다.
- 릴리스 파이프라인에서 변경 관리 프로세스를 모니터링합니다.
- ServiceNow 변경 요청을 배포 결과로 업데이트된 상태로 유지합니다.
필수 조건
이 자습서에서는 승인 및 게이트 사용 및 승인 정의 및 검사 확장합니다.
Azure DevOps 조직 아직 조직이 없는 경우 조직을 만듭니다.
ServiceNow의 비 개발자 인스턴스입니다.
ServiceNow 인스턴스 구성
ServiceNow 인스턴스에 Azure Pipelines 확장을 설치합니다. 설치를 완료하려면 Hi 자격 증명이 필요합니다. ServiceNow 스토어에서 앱을 설치하는 자세한 내용은 구매 개요를 참조하세요.
ServiceNow에서 새 사용자를 만들고 다음 역할을
x_mioms_azpipeline.pipelinesExecution
부여합니다.
Azure DevOps 조직 설정
Azure DevOps 조직에 ServiceNow 변경 관리 확장을 설치합니다.
다음과 같이 Azure DevOps 프로젝트에서 새 ServiceNow 서비스 연결을 만듭니다. 또는 OAuth2 인증을 사용할 수도 있습니다.
릴리스 파이프라인을 구성합니다.
릴리스 파이프라인으로 이동한 다음 배포 전 조건 아이콘을 선택합니다. 게이트 및 ServiceNow 변경 관리 배포 전 게이트를 선택합니다.
이전에 만든 서비스 연결을 선택하고 다음과 같이 필요한 필드를 입력합니다.
- ServiceNow 연결: 변경 관리에 사용되는 ServiceNow 인스턴스에 대한 커넥트ion입니다.
- 간단한 설명: 변경 내용 요약입니다.
- 설명: 변경 내용에 대한 자세한 설명입니다.
- 범주: 변경의 범주입니다. 예: 하드웨어, 네트워크, 소프트웨어.
- 우선 순위: 변경의 우선 순위입니다.
- 위험: 변경에 대한 위험 수준입니다.
- 영향: 변경 내용이 비즈니스에 미치는 영향입니다.
- 구성 항목: 변경 내용이 적용되는 CI(구성 항목)입니다.
- 할당 그룹: 변경 내용이 할당된 그룹입니다.
- 변경 요청 일정: ServiceNow 워크플로에서 적용한 변경 일정입니다. 날짜 및 시간은 UTC여야 하며 형식은 yyyy-MM-ddTHH:mm:ssZ여야 합니다. 예: 2018-01-31T07:56:59Z.
- 추가 변경 요청 매개 변수: 이름은 'u_' 접두사로 된 필드 이름(레이블 아님)이어야 합니다. 예: u_backout_plan. 값은 ServiceNow에서 유효한 값이어야 합니다. 잘못된 항목이 무시됩니다.
- 원하는 변경 요청 상태: 변경 요청 상태 제공된 값과 같으면 게이트가 성공하고 파이프라인이 계속됩니다.
- 고급: 이 게이트가 성공해야 하는 시기를 제어하는 식을 지정합니다. 변경 요청은 ServiceNow의 응답에서 루트['result']로 정의됩니다. 예 - "and(eq(root['result'].state, 'New'),eq(root['result'].risk, 'Low'))" 자세한 내용은 식을 참조하세요.
- 출력 변수 : 배포 워크플로에서 출력 변수를 사용할 수 있도록 참조 이름을 지정해야 합니다. 에이전트 없는 작업에서 "PREDEPLOYGATE"를 "접두사"로 사용하여 게이트 변수에 액세스할 수 있습니다. 예를 들어 참조 이름이 'gate1'로 설정된 경우 변경 번호를 다음과 같이 가져올 수 있습니다. $(PREDEPLOYGATE.gate1.CHANGE_REQUEST_NUMBER).
- CHANGE_REQUEST_NUMBER: 변경 요청의 수입니다.
- CHANGE_SYSTEM_ID: 변경 요청의 시스템 ID입니다.
릴리스 파이프라인의 끝에서 ServiceNow 변경 요청 업데이트 작업으로 에이전트 없는 작업을 추가합니다.
- ServiceNow 연결: 변경 관리에 사용되는 ServiceNow 인스턴스에 대한 커넥트ion입니다.
- 변경 요청 번호: 업데이트할 변경 요청의 수입니다.
- 변경 요청 상태 업데이트됨: 변경 요청에 대해 설정할 상태입니다. 이 입력은 업데이트 상태 선택한 경우 사용할 수 있습니다.
- 코드 닫기 및 메모 닫기: 상태 반환합니다.
참고 항목
실행 중에 변경 요청 필드가 업데이트되지 않으면 ServiceNow 변경 요청 업데이트 작업이 실패합니다. ServiceNow는 잘못된 필드와 작업에 전달된 값을 무시합니다.
릴리스 파이프라인 만들기
릴리스 만들기를 선택하여 새 릴리스 파이프라인을 시작합니다.
파이프라인은 이전에 만든 배포 전 조건의 일부로 ServiceNow에서 새 변경 요청을 만들어야 합니다.
파이프라인은 모든 게이트가 동일한 샘플 간격 내에 성공할 때까지 기다립니다. 변경 번호를 검사 상태 아이콘을 선택하여 파이프라인 로그를 봅니다.
변경 요청은 ServiceNow에서 큐에 대기되며 변경 소유자가 볼 수 있습니다.
새 변경 요청을 트리거한 릴리스 파이프라인은 Azure DevOps 파이프라인 메타데이터 섹션에서 찾을 수 있습니다.
변경 내용이 구현할 준비가 되면(구현 상태로 이동) 파이프라인이 실행을 다시 시작하고 게이트 상태 성공적으로 반환되어야 합니다.
변경 요청은 배포 후 자동으로 닫힙니다.
Yaml 파이프라인
이 자습서에서는 "최신" 환경에 배포되는 단일 단계가 있는 yaml 파이프라인이 있다고 가정합니다.
검사 추가
환경 "최신"으로 이동하고 줄임표 단추를 선택한 다음 승인 및 검사 선택합니다.
더하기 기호를 선택하여 새 검사 추가한 다음 ServiceNow 변경 관리 검사 환경에 추가합니다. 배포 전 게이트에 사용한 것과 동일한 구성을 사용합니다.
yaml 작업 추가
단계에 서버 작업을 추가하여 변경 요청을 업데이트합니다.
파이프라인을 저장하고 실행합니다. 새 변경 요청이 자동으로 생성되고 파이프라인이 일시 중지되고 검사 완료될 때까지 기다립니다.
검사 완료되면 파이프라인이 실행을 다시 시작해야 합니다. 변경 요청은 배포 후 자동으로 닫힙니다.
FAQ
Q: 지원되는 ServiceNow 버전은 무엇인가요?
A: 킹스턴, 런던, 뉴욕, 파리, 퀘벡, 로마, 샌디에이고, 도쿄 버전이 지원됩니다.
A: 킹스턴, 런던, 뉴욕, 파리, 퀘벡 버전이 지원됩니다.
A: 다음 버전을 지원합니다. 샌디에이고, 도쿄 및 유타 릴리스.
Q: 지원되는 변경 요청 유형은 무엇인가요?
A: 이 통합을 통해 일반, 표준 및 긴급 변경 요청이 지원됩니다.
Q: 추가 변경 속성을 설정할 어떻게 할까요? 있나요?
A: 추가 변경 요청 매개 변수 필드에서 추가 변경 속성을 지정할 수 있습니다. 이름이 접두 u_
사로 지정된 필드 이름(레이블 아님)인 키-값 쌍 JSON 형식을 사용합니다.
Q: 변경 요청의 사용자 지정 필드를 추가 변경 요청 매개 변수로 업데이트할 수 있나요?
A: 사용자 지정 필드가 변경 요청에 정의된 경우 가져오기 집합 변환 맵에서 사용자 지정 필드에 대한 매핑을 추가해야 합니다.
Q: 범주, 상태 및 기타 필드에 대한 드롭다운 값이 채워지지 않습니다. 어떻게 해야 합니까?
A: 변경 관리 코어 및 변경 관리 - 드롭다운이 작동하려면 ServiceNow 인스턴스에서 상태 모델 플러그 인이 활성화되어 있어야 합니다. 자세한 내용은 업그레이드 변경 관리 및 업데이트 변경 요청 상태를 참조하세요.
리소스
- 안전한 배포를 위한 릴리스 파이프라인 구성
- 릴리스 게이트로서의 트위터 감정
- 릴리스 게이트로 발생하는 GitHub 문제
- 사용자 지정 게이트를 작성합니다.
- ServerTaskHelper 라이브러리 예제