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