파이프라인 실행 작동 방식

이 섹션에서는 일련의 변경 사항을 CodePipeline 처리하는 방법에 대한 개요를 제공합니다. CodePipeline파이프라인이 수동으로 시작되거나 소스 코드가 변경될 때 시작되는 각 파이프라인 실행을 추적합니다. CodePipeline는 다음 실행 모드를 사용하여 각 실행이 파이프라인을 통해 진행되는 방식을 처리합니다.

• 대체 모드: 최근 실행이 이전 실행을 추월할 수 있습니다. 이 값이 기본값입니다.

• QUEUED 모드: 실행은 대기열에 있는 순서대로 하나씩 처리됩니다. 이를 위해서는 파이프라인 유형 V2가 필요합니다.

• 병렬 모드: PARALLEL 모드에서는 실행이 동시에 독립적으로 실행됩니다. 실행은 시작 또는 종료 전에 다른 실행이 완료될 때까지 기다리지 않습니다. 이를 위해서는 파이프라인 유형 V2가 필요합니다.

파이프라인 실행 시작 방법

소스 코드를 변경하거나 파이프라인을 수동으로 시작할 때 실행을 시작할 수 있습니다. 예약한 Amazon CloudWatch Events 규칙을 통해 실행을 트리거할 수도 있습니다. 예를 들어 소스 코드 변경이 파이프라인의 소스 작업으로 구성된 리포지토리로 푸시되면 파이프라인은 변경 사항을 감지하고 실행을 시작합니다.

참고

파이프라인에 여러 개의 소스 작업이 포함되어 있는 경우, 소스 작업 한 개에만 변경이 감지되더라도 모든 소스 작업이 다시 실행됩니다.

파이프라인 실행을 중지하는 방법

콘솔을 사용하여 파이프라인 실행을 중지하려면 파이프라인 시각화 페이지, 실행 기록 페이지 또는 세부 기록 페이지에서 실행 중지를 선택할 수 있습니다. CLI를 사용하여 파이프라인 실행을 중지하려면 stop-pipeline-execution 명령을 사용합니다. 자세한 설명은 CodePipeline에서 파이프라인 실행 중지 섹션을 참조하세요.

파이프라인 실행을 중지하는 방법은 두 가지입니다.

• 중지 및 대기: 진행 중인 모든 작업 실행을 완료할 수 있으며 후속 작업이 시작되지 않습니다. 파이프라인 실행은 후속 단계로 계속되지 않습니다. 이미 Stopping 상태인 실행에는 이 옵션을 사용할 수 없습니다.

• 중지 및 중단: 진행 중인 모든 작업 실행이 중단되고 완료되지 않으며 후속 작업이 시작되지 않습니다. 파이프라인 실행은 후속 단계로 계속되지 않습니다. 이미 Stopping 상태인 실행에 이 옵션을 사용할 수 있습니다.

  참고

  이 옵션을 선택하면 작업이 실패하거나 작업 순서가 뒤바뀔 수 있습니다.

각 옵션에서 파이프라인 및 작업 실행 단계의 순서가 다음과 같이 달라집니다.

옵션 1: 중지 및 대기

중지하고 대기하도록 선택하면 진행 중인 작업이 완료될 때까지 선택한 실행이 계속됩니다. 예를 들어, 빌드 작업이 진행되는 동안 다음 파이프라인 실행이 중지되었습니다.

1. 파이프라인 보기에 성공 메시지 배너가 표시되고 빌드 작업이 완료될 때까지 계속됩니다. 파이프라인 실행 상태는 중지 중입니다.

   기록 보기에서 빌드 작업과 같은 진행 중인 작업의 상태는 빌드 작업이 완료될 때까지 진행 중입니다. 작업이 진행 중인 동안 파이프라인 실행 상태는 중지 중입니다.

2. 중지 프로세스가 완료되면 실행이 중지됩니다. 빌드 작업이 성공적으로 완료되면 상태는 성공이고 파이프라인 실행은 중지됨 상태로 표시됩니다. 후속 작업이 시작되지 않습니다. 재시도 버튼이 활성화됩니다.

   진행 중인 작업이 완료된 후 기록 보기에서 실행 상태는 중지됨입니다.

   

옵션 2: 중지 및 중단

중지하고 중단하도록 선택하면 선택한 실행은 진행 중인 작업이 완료될 때까지 대기하지 않습니다. 작업은 중단됩니다. 예를 들어, 빌드 작업이 진행 중인 동안 다음 파이프라인 실행이 중지되고 중단되었습니다.

1. 파이프라인 보기에 성공 배너 메시지가 표시되고 빌드 작업은 진행 중 상태로 표시되며 파이프라인 실행은 중지 중 상태로 표시됩니다.

2. 파이프라인 실행이 중지된 후 빌드 작업은 중단됨 상태로 표시되고 파이프라인 실행은 중지됨 상태로 표시됩니다. 후속 작업이 시작되지 않습니다. 재시도 버튼이 활성화됩니다.

3. 기록 보기에서 실행 상태는 중지됨입니다.

   

파이프라인 실행 중지의 사용 사례

중지 및 대기 옵션을 사용하여 파이프라인 실행을 중지하는 것이 좋습니다. 이 옵션은 파이프라인에서 발생할 수 있는 실패나 out-of-sequence 작업을 방지하므로 더 안전합니다. 작업이 중단된 경우 작업 제공자는 해당 작업과 관련된 모든 작업을 계속합니다. CodePipeline AWS CloudFormation 작업의 경우 파이프라인의 배포 작업은 중단되지만 스택 업데이트는 계속되어 업데이트가 실패할 수 있습니다.

작업으로 이어질 수 있는 중단된 작업의 예로, S3 배포 out-of-sequence 작업을 통해 대용량 파일 (1GB) 을 배포하고 배포가 이미 진행 중인 상태에서 작업을 중지했다가 중단하기로 선택한 경우 작업은 Amazon S3에서 중단되지만 Amazon S3에서는 CodePipeline 계속됩니다. Amazon S3에서는 업로드를 취소하라는 지시가 발생하지 않습니다. 그런 다음, 아주 작은 파일로 새 파이프라인 실행을 시작하는 경우 이제 두 개의 배포가 진행 중입니다. 새 실행의 파일 크기가 작기 때문에 이전 배포가 여전히 업로드되는 동안 새 배포가 완료됩니다. 이전 배포가 완료되면 이전 파일이 새 파일을 덮어씁니다.

사용자 지정 작업이 있는 사례에서 중지 및 중단 옵션을 사용하려고 할 수 있습니다. 예를 들어, 버그 수정을 위한 새 실행을 시작하기 전에 완료할 필요 없는 작업이 포함된 사용자 지정 작업을 중단할 수 있습니다.

대체 모드에서 실행이 처리되는 방법

실행 처리를 위한 기본 모드는 대체 모드입니다. 실행은 해당 실행에서 선택되고 처리되는 일련의 변경 사항으로 구성됩니다. 파이프라인은 동시에 여러 실행을 처리할 수 있습니다. 각 실행은 별도로 파이프 라인을 통해 실행됩니다. 파이프라인은 각 실행을 순서대로 처리하며 이전 실행을 이후 실행으로 대체할 수 있습니다. 다음 규칙은 대체 모드의 파이프라인에서 실행을 처리하는 데 사용됩니다.

규칙 1: 실행이 처리 중일 때 단계가 잠깁니다.

각 단계는 한 번에 하나의 실행만 처리할 수 있으므로 진행 중인 동안에는 단계가 잠깁니다. 실행이 단계를 완료하면 파이프라인의 다음 단계로 전환됩니다.

이전: Stage 1 is locked as Execution 1 enters. 이후: Stage 2 is locked as Execution 1 enters.

규칙 2: 후속 실행은 단계가 잠금 해제될 때까지 기다립니다.

단계가 잠겨 있는 동안 대기 중인 실행은 잠긴 단계 앞에 유지됩니다. 단계가 완료된 것으로 간주되기 전에 한 단계에 구성한 모든 작업을 성공적으로 끝내야 합니다. 실패하면 단계에서 잠금이 해제됩니다. 실행이 중지되면 단계에서 실행이 계속되지 않고 단계가 잠금 해제됩니다.

참고

실행을 중지하기 전에 단계 앞의 전환을 비활성화하는 것이 좋습니다. 이렇게 하면 실행 중지로 인해 단계가 잠금 해제될 때 단계에서 후속 파이프라인 실행이 허용되지 않습니다.

이전: Stage 2 is locked as Execution 1 enters. 이후: Execution 2 exits Stage 1 and waits between stages.

규칙 3: 대기 중인 실행이 더 최근의 실행으로 대체됩니다.

실행은 단계 사이에서만 대체됩니다. 잠긴 단계에서는 단계가 완료되기를 기다리는 단계의 앞에 실행이 유지됩니다. 보다 최근의 실행이 대기 중인 실행을 추월하고 단계의 잠금이 해제되는 즉시 다음 단계로 계속됩니다. 대체된 실행은 계속되지 않습니다. 이 예제에서는 실행 2가 잠긴 단계를 기다리는 동안 실행 3으로 대체되었습니다. 실행 3은 다음 단계에 들어갑니다.

이전: 실행 3이 단계 1에 들어가는 동안 실행 2는 단계 사이에서 대기합니다. 이후: 실행 3이 단계 1을 종료합니다. 실행 2는 실행 3으로 대체됩니다.

QUEUED 모드에서 실행이 처리되는 방법

QUEUED 모드의 파이프라인에서는 실행이 처리될 때 스테이지가 잠깁니다. 하지만 대기 중인 실행이 이미 시작된 실행을 초과하지는 않습니다.

대기 중인 실행은 스테이지에 도달하는 순서대로 잠긴 스테이지의 진입점에 모여 대기 중인 실행 대기열을 형성합니다. QUEUED 모드를 사용하면 동일한 파이프라인에 여러 대기열을 둘 수 있습니다. 대기 중인 실행이 스테이지에 들어가면 스테이지가 잠기고 다른 실행은 들어갈 수 없습니다. 이 동작은 SUPERSEDED 모드와 동일하게 유지됩니다. 실행이 스테이지를 완료하면 스테이지의 잠금이 해제되어 다음 실행을 위한 준비가 됩니다.

다음 다이어그램은 QUEUED 모드 파이프라인의 스테이지가 실행을 처리하는 방법을 보여줍니다. 예를 들어, 소스 단계가 실행 5를 처리하는 동안 6과 7의 실행은 대기열 #1 를 형성하고 단계 진입점에서 대기합니다. 대기열의 다음 실행은 스테이지가 잠금 해제된 후에 처리됩니다.

실행 모드가 있는 할당량에 대한 자세한 내용은 을 참조하십시오. AWS CodePipeline의 할당량

병렬 모드에서 실행이 처리되는 방법

PARALLEL 모드의 파이프라인에서는 실행이 서로 독립적이므로 시작하기 전에 다른 실행이 완료될 때까지 기다리지 않아도 됩니다. 대기열이 없습니다. 파이프라인에서 병렬 실행을 보려면 실행 기록 보기를 사용하세요.

각 기능에 고유한 기능 분기가 있고 다른 사용자가 공유하지 않는 대상에 배포하는 개발 환경에서는 PARALLEL 모드를 사용하십시오.

실행 모드를 포함한 할당량에 대한 자세한 내용은 을 참조하십시오. AWS CodePipeline의 할당량

파이프라인 흐름 관리

파이프라인 실행의 흐름은 다음을 통해 제어할 수 있습니다.

• 전환을 통해 단계로의 실행 흐름을 제어합니다. 전환은 활성화 또는 비활성화가 가능합니다. 전환이 비활성화되면 파이프라인 실행이 단계에 들어갈 수 없습니다. 전환이 비활성화된 단계에 들어가기 위해 기다리는 파이프라인 실행을 인바운드 실행이라고 합니다. 전환을 활성화하면 인바운드 실행이 단계 이동하여 잠깁니다.

  잠긴 단계를 기다리는 실행과 마찬가지로 전환이 비활성화된 경우에도 단계에 들어가기를 기다리는 실행은 여전히 새 실행으로 대체될 수 있습니다. 비활성화된 전환이 다시 활성화되면 전환이 비활성화된 상태에서 이전 실행을 대체한 최신 실행이 해당 단계로 들어갑니다.

• 승인 작업은 권한이 허용될 때까지 파이프라인이 다음 작업으로 전환하지 않도록 합니다(예를 들면 권한이 있는 자격 증명에게 수동 승인을 받아서). 예를 들어 파이프라인이 최종 프로덕션 단계로 전환되는 시간을 제어하려는 경우 승인 작업을 사용할 수 있습니다.

  참고

  승인 작업이 있는 단계는 승인 작업이 승인 또는 거부되거나 제한 시간이 초과될 때까지 잠깁니다. 제한 시간이 초과된 승인 작업은 실패한 작업과 동일한 방식으로 처리됩니다.

• 단계의 작업이 성공적으로 완료되지 않을 때 실패가 발생합니다. 개정은 해당 단계의 다음 작업 또는 파이프라인의 다음 단계로 전환하지 않습니다. 다음과 같은 상황이 발생할 수 있습니다.

  • 실패한 작업이 포함된 단계를 수동으로 재시작합니다. 이렇게 하면 실행이 재개됩니다(실패한 작업을 다시 시도하고 성공하면 단계/파이프라인에서 계속).

  • 또 다른 실행은 실패한 단계에 들어가서 실패한 실행을 대체합니다. 이 때 실패한 실행을 다시 시도할 수 없습니다.

권장 파이프라인 구조

코드 변경이 파이프라인을 통과하는 방식을 결정할 때는 단계가 잠길 때 작업이 모두 동일한 실행을 처리하도록 단계 내에서 관련 작업을 그룹화하는 것이 가장 좋습니다. 각 애플리케이션 환경, AWS 리전, 가용 영역 등에 대해 단계를 생성할 수 있습니다. 단계가 너무 많은(즉, 너무 세분화된) 파이프라인은 동시 변경을 너무 많이 허용할 수 있으며, 큰 단계(잘 세분화되지 않은)에서 작업의 수가 많은 파이프라인의 경우 변경 사항을 릴리스하는 데 너무 오랜 시간이 걸릴 수 있습니다.

예를 들어, 동일한 단계의 배포 작업 이후의 테스트 작업은 배포된 것과 동일한 변경 사항을 테스트하도록 보장됩니다. 이 예제에서는 변경 사항을 테스트 환경에 배포하고 테스트한 다음, 테스트 환경의 최신 변경 사항을 프로덕션 환경에 배포합니다. 권장되는 예제에서 테스트 환경과 프로덕션 환경은 별도의 단계입니다.

왼쪽: 관련 테스트, 배포 및 승인 작업이 그룹화되어 있습니다(권장). 오른쪽: 관련 작업들이 별도의 단계에 있습니다(권장하지 않음).

인바운드 실행 작동 방식

인바운드 실행이란 사용할 수 없는 단계, 전환 또는 작업을 사용할 수 있게 될 때까지 기다렸다가 다음 단계로 넘어가는 실행입니다. 다음과 같은 이유로 다음 단계, 전환 또는 작업을 사용하지 못할 수 있습니다.

• 다른 실행이 이미 다음 단계에 들어가서 잠겼습니다.

• 다음 단계로 들어가기 위한 전환이 비활성화되었습니다.

현재 실행이 후속 단계에서 완료될 시간이 있는지 여부를 제어하거나 특정 시점에서 모든 작업을 중지하려는 경우 인바운드 실행을 보류하는 전환을 비활성화할 수 있습니다. 인바운드 실행이 있는지 확인하려면 콘솔에서 파이프라인을 보거나 get-pipeline-state 명령의 출력을 볼 수 있습니다.

인바운드 실행은 다음과 같은 고려 사항에 따라 작동합니다.

• 작업, 전환 또는 잠금 단계를 사용할 수 있게 되면 진행 중인 인바운드 실행이 단계에 진입하여 파이프라인을 통해 계속됩니다.

• 인바운드 실행이 대기 중인 동안에는 수동으로 중지할 수 있습니다. 인바운드 실행은 InProgress, Stopped 또는 Failed 상태일 수 있습니다.

• 인바운드 실행이 중지되거나 실패한 경우 재시도할 실패한 작업이 없으므로 다시 시도할 수 없습니다. 인바운드 실행이 중지되고 전환이 활성화된 경우 중지된 인바운드 실행은 단계로 계속되지 않습니다.

인바운드 실행을 보거나 중지할 수 있습니다.