파이프라인 상태 유형

특정 지점에서 참조 파이프라인의 오류 또는 실패 조건을 이해하는 것이 중요합니다. 개념적으로는 다음과 같이 규제 준수 파이프라인에서 실행되는 태스크의 두 가지 서로 다른 유형의 상태 결과가 있습니다.

• 규제 준수 상태: some 검사 또는 검사 세트의 패스 또는 실패 상태입니다.
• 파이프라인 상태: 태스크 실행 자체의 성공 또는 실패 상태입니다.

테스트, 스캔 또는 검사에 실패해도 파이프라인 자체가 실패하거나 중지되지 않습니다. 테스트를 실행 중인 태스크는 초록색으로 표시됩니다.

규제 준수라는 관점에서는 단위 테스트의 결과가 배치에 영향을 주지 않습니다. 검사에 실패한 아티팩트를 배치할 수 있지만 프로세스는 이 활동에 관한 증거를 보존합니다. 규제 준수 플로우는 가동 중단이 발생해도 수정사항 릴리스를 막지 않습니다. 예를 들어, 실패한 테스트를 발견한 단위 테스트 태스크의 초록색 실행은 The task ran successfully and found the following issues을 의미합니다.

태스크가 실패하며 빨간색 상태가 되는 이유는 파이프라인이 계속될 수 없거나 계속되지 않아야 하기 때문입니다. 실패에 관한 예제 조건은 다음과 같습니다.

• 태스크 또는 파이프라인의 오류입니다.
• 파이프라인을 계속 실행하는 것이 의미가 없는 상황이 발생했습니다.

예를 들어, 아티팩트 빌드가 지속적 통합에서 실패하는 경우 지속적 통합 프로세스 자체의 목적에 맞지 않습니다.

최종 파이프라인 상태를 규제 준수 결과와 동기화 상태로 유지하려면 파이프라인 끝에 있는 태스크에서 규제 준수 결과를 확인하고 파이프라인 실행 상태를 red 또는 green으로 설정합니다.

가져오기 요청 파이프라인

가져오기 요청 파이프라인은 지정된 애플리케이션(앱) 저장소의 가져오기 요청에서 사전 설정된 규제 준수 상태 검사를 실행합니다. 이러한 상태 확인에 실패하면 풀 리퀘스트를 기본 활성 브랜치(보통 master)로 병합하지 못할 수 있습니다. 기본 활성 브랜치에 대한 풀 리퀘스트를 열거나 업데이트하여 풀 리퀘스트 파이프라인 실행을 트리거합니다. 사용자는 사용자 정의 스테이지에서 파이프라인 및 테스트를 위한 고유 설정을 실행할 수 있습니다. 가져오기 요청 파이프라인에 관한 자세한 정보는 가져오기 요청 파이프라인을 참조하십시오.

지속적 통합 파이프라인

지속적 통합 파이프라인은 애플리케이션(앱) 저장소에서 배치 가능한 아티팩트를 빌드합니다. 아티팩트를 빌드하기 전에 파이프라인은 가져오기 요청을 처리하는 방법과 동일한 방법으로 코드가 스캔되고 테스트되는지 확인합니다. 또한 빌드된 아티팩트는 인벤토리에서 릴리스 및 배치 준비로 표시하기 전에 취약성이 있는지 스캔하고 파이프라인에서 서명합니다. 가져오기 요청 파이프라인과 달리, 지속적 통합 파이프라인은 빌드의 각 스테이지(예: 테스트, 스캔, 서명)에서 증거 및 결과 아티팩트를 수집합니다. 이 데이터는 빌드된 아티팩트와 관련되며 배치 프로세스 및 변경 관리를 통해 추적 가능합니다. 지속적 통합 파이프라인에 관한 자세한 정보는 지속적 통합 파이프라인을 참조하십시오.

지속적인 배치 파이프라인

지속적 배포 파이프라인은 모든 증거와 변경 요청 요약 콘텐츠를 생성합니다. 파이프라인은 스테이징 또는 프로덕션과 같은 특정 환경에 빌드 아티팩트를 배치한 후 증거 라커에 기존 로그 파일, 증거, 아티팩트를 모두 수집하고 작성하고 업로드합니다. 연속 배치 파이프라인에 대한 자세한 정보는 연속 배치 파이프라인 을 참조하십시오.

지속적인 컴플라이언스 파이프라인

지속적 준수 파이프라인은 아티팩트가 프로덕션에 배치된 이후 배치된 아티팩트 및 해당 소스 저장소에서 최신 취약성을 주기적으로 스캔합니다. 또한 파이프라인은 마감일과의 편차를 자동으로 추적하고 애플리케이션 인식 기능을 제공합니다. 자세한 내용은 지속적인 규정 준수 파이프라인을 참조하세요.

인벤토리 워크플로우

증거를 참조하십시오.

인벤토리를 참조하십시오.

인벤토리 환경

현재 배치된 상태에는 환경에 배치할 컨텐츠가 포함되어 있습니다. 대상 분기의 모든 승격된 커미트에는 관련 파이프라인 실행 ID 및 변경 요청 ID가 태그로 포함되어 있습니다. 일부 커미트에는 실패한 배치가 다시 실행될 때와 같이 여러 개의 태그가 있을 수 있습니다. 인벤토리는 배치를 재생할 모든 정보를 저장합니다.

태그 사용

• latest: 분기에서 인벤토리의 현재 배치되고 종료된 상태에 태그를 지정합니다.
• pipeline run id: 분기의 최근 인벤토리 상태에 실제 배치의 빌드 번호나 파이프라인 실행 ID로 태그를 지정합니다. 이 정보를 사용하여 병렬 배치가 트리거되는 경우 인벤토리 컨텐츠가 겹치지 않도록 분기 히스토리에서 실제 인벤토리 지점 해시를 참조할 수 있습니다.
• change request id: 선택사항입니다. 현재 상태에 태그를 설정합니다. 변경 요청 ID는 히스토리에 따라 표시되고 인벤토리에서 추적됩니다.

단일 대상 - 다중 지역 설정

단일 대상 - 다중 지역 설정은 단일 대상 환경을 위한 여러 latest 태그가 도입되는 이 모델의 반복입니다. 이 모델을 사용하면 여러 유형의 유스 케이스에 대해 동일한 대상에서 여러 개의 지속적 파이프라인이 작동될 수 있습니다.

예를 들어, 프로덕션 대상 환경 및 인벤토리 분기에서 여러 지역(예: us-south 및 eu-de)에 대해 동일한 대상 환경을 사용할 수 있습니다.

연속 배치 파이프라인으로 배치 지역을 지정하려면 region 매개변수를 사용하십시오. 이 매개변수에 대한 자세한 정보는 연속 배치 파이프라인 매개변수 를 참조하십시오.

팀에서는 us-south-prod 및 eu-de-prod 과 같이 각 지역마다 다른 지점을 설정하여 프로모션을 중복으로 실행할 필요가 없습니다. 대신 동일한 인벤토리 분기에 이러한 추가 대상을 지정한 후 Git 태그로 사용하십시오.

이 설정에서 prod 브랜치는 us-south_prod_latest 및 eu-de_prod_latest 와 같이 동일한 브랜치에 여러 개의 latest 태그를 가지며, 각 리전을 담당하는 각 연속 배포 파이프라인은 이러한 태그를 사용하여 배포할 수 있습니다.

시나리오 예

모든 위치에 배치될 수 있는 변경사항 세트가 하나의 지역에 먼저 릴리스될 수 있습니다. 그런 다음 해당 지역을 대상으로 하는 지속적인 배포 파이프라인을 사용하여 이 변경 집합을 다른 지역에 점진적으로 배포할 수 있습니다.