실패한 빌드 또는 릴리스 파이프라인 작업 및 스테이지 다시 시작
해당 스테이지 또는 파이프라인에서 실패하거나 취소된 빌드, 릴리스 변경 또는 파이프라인을 다시 실행하거나 재배포 Azure DevOps 합니다. 재시도는 파이프라인 UI에 DevOps 새 실행을 생성하는 대신 연속 실행으로 표시됩니다.
파이프라인 또는 스테이지 재실행 Azure DevOps
실패하거나 취소된 빌드 또는 릴리스 파이프라인을 다시 실행하거나 에서 작업을 변경할 수 있습니다.Azure DevOps 재실행은 에서 첫 번째 실행 ServiceNow DevOps과 동일한 파이프라인 실행의 일부로 처리됩니다. 전체 파이프라인 또는 실패하거나 취소된 특정 작업 및 스테이지를 다시 실행할 수 있습니다. 이제 스테이지 또는 파이프라인을 다시 시작할 때마다 새 변경 요청을 생성하는 대신 변경 요청을 재사용할 수 있습니다.
attemptNumber 재실행을 추적하는 데 도움이 되는 매개변수가 페이로드에 추가됩니다. 모든 재실행 시도에 해당하는 관련 테스트 요약, 소프트웨어 품질 검사 결과, 커밋, 작업 항목도 에서 업데이트 ServiceNow DevOps됩니다.
사용하는 Azure 호출 REST API를 사용하여 변경 제어 구성 경우 빌드 및 릴리스 파이프라인에 대해 지정된 구문 형식으로 페이로드 본문에 시도 번호 매개변수를 추가해야 합니다. 시도 횟수 매개변수를 지정하지 않으면 기본 시도 횟수는 1로 설정됩니다.
"attemptNumber": "$(system.jobAttempt)""attemptNumber": "$(Release.AttemptNumber)"변경 요청 재사용
변경 활성화 작업이 다시 실행되고 이전 실행/시도에 대한 변경 요청이 있는 경우 기본 시스템 "DevOps 변경 요청 재사용 가능성 결정 하위 플로우"를 사용하여 이전 변경 요청을 재사용하거나 새 변경 요청을 생성하도록 선택할 수 있습니다. 이 하위 플로우의 기본 구현을 사용하면 변경 요청이 구현 또는 구현 후 상태인 경우 이전 시도의 변경 요청을 재사용할 수 있습니다. 변경 요청이 다른 상태 인 경우 기본적으로 작업을 다시 실행하면 새 변경 요청이 만들어집니다. 기존 동작에 따라 테스트 요약 및 검사와 같은 모든 관련 세부 정보가 새로 생성되는 반면 커밋과 작업 항목은 새 변경 요청에 대해 변경되지 않은 상태로 유지됩니다.
예를 들어 변경 요청이 승인된 후 특정 스테이지에서 파이프라인이 실패하고 해당 스테이지를 다시 실행하는 경우입니다. 변경 요청이 재사용되고, 아티팩트에 연결된 테스트 요약 및 소프트웨어 품질 검사, 커밋 및 작업 항목이 사용자가 승인한 동일한 변경 요청과 연결됩니다.
재사용성을 위한 사용자 지정 논리를 적용하려면 기존 하위 플로우를 복사하고, 변경하고, 게시하고, 아래에서 새 하위 플로우 이름을 업데이트하면 됩니다. .
일반 기본 시스템 플로우에서 변경이 생성되면 변경 요청에 대한 결정을 내린 후 단계 실행 기록의 필드를 업데이트할 State 때 '플로우 사용자 지정 DevOps'를 사용합니다. 그러나 변경을 재사용할 경우 생성 중인 변경 요청의 첫 번째 트리거 조건이 충족되지 않습니다. 작업이 재실행될 때 변경 요청이 재사용될 때마다 기본 시스템 하위 플로우 "DevOps 변경 요청 재사용 가능성 모델 하위 플로우"가 대신 트리거됩니다. 이 하위 플로우의 기본 구현은 모델 변경 요청 플로우와 DevOps 비슷합니다. 다음에서 사용자 지정 하위 플로우를 생성하고 하위 플로우 이름을 업데이트할 수 있습니다 . .
파이프라인 UI 변경
- 카드를 클릭하면 해당 스테이지의 최신 시도를 볼 수 있습니다.
- 모든 시도 보기 링크를 클릭하면 두 번 이상 실행되는 단계 또는 스테이지와 관련된 모든 단계 실행 및 관련 정보를 볼 수 있습니다.
- 변경 보기 링크에는 최근 시도와 연결된 변경 요청이 표시됩니다.