CodePipeline 개념

AWS CodePipeline에서 사용되는 개념과 용어를 이해하면 자동화된 릴리즈 프로세스를 모델링하고 구성하는 것이 쉬워집니다. 다음은 CodePipeline 사용에 관해 알아야 할 개념입니다.

DevOps 파이프라인의 예는 을 참조하십시오DevOps 파이프라인 예제.

에서 사용되는 용어는 다음과 CodePipeline 같습니다.

파이프라인

파이프라인이란 소프트웨어 변경 사항이 릴리스 프로세스에 적용되는 방법을 설명하는 워크플로우 구성입니다. 각 파이프라인은 일련의 단계로 구성됩니다.

Stages

단계는 환경을 격리하고 해당 환경에서 동시 변경 작업의 수를 제한하는 데 사용할 수 있는 논리 단위입니다. 각 단계에는 애플리케이션 아티팩트에 대해 수행되는 작업이 포함됩니다. 소스 코드는 아티팩트의 한 예입니다. 소스 코드가 빌드되고 테스트가 실행되는 빌드 단계가 될 수 있습니다. 또한 코드가 런타임 환경에 배포되는 배포 단계가 될 수도 있습니다. 각 단계는 일련의 직렬 또는 병렬 작업으로 구성됩니다.

작업

작업은 애플리케이션 코드에서 수행되고 지정된 지점에 파이프라인에서 작업이 실행되도록 구성된 일련의 작업입니다. 여기에는 코드 변경의 소스 작업, 애플리케이션을 인스턴스에 배포하는 작업 등이 포함될 수 있습니다. 예를 들어 배포 단계에는 Amazon EC2 또는 AWS Lambda과 같은 컴퓨팅 서비스에 코드를 배포하는 배포 작업이 포함될 수 있습니다.

유효한 CodePipeline 작업 유형은source,build,test, deployapproval, 및 invoke 입니다. 작업 공급자 목록은 CodePipeline에서 유효한 작업 유형 및 공급자 단원을 참조하십시오.

작업은 직렬 또는 병렬로 실행할 수 있습니다. 단계의 직렬 및 병렬 작업에 대한 자세한 내용은 작업 구조 요구 사항의 runOrder 정보를 참조하십시오.

파이프라인 실행

실행은 파이프라인에서 릴리스된 변경 집합입니다. 각 파이프라인 실행은 고유한 자체 ID를 가집니다. 실행은 병합된 커밋 또는 최신 커밋의 수동 릴리스와 같은 변경 집합에 해당합니다. 두 실행은 서로 다른 시간에 동일한 변경 집합을 릴리스할 수 있습니다.

파이프라인은 동시에 여러 실행을 처리할 수 있지만 파이프라인 단계는 한 번에 하나의 실행만 처리합니다. 이를 위해 실행을 처리하는 동안 단계가 잠깁니다. 두 파이프라인 실행이 동시에 같은 단계를 차지할 수는 없습니다. 점유 단계에 진입하기 위해 대기 중인 실행을 인바운드 실행이라고 합니다. 인바운드 실행은 여전히 실패하거나, 대체되거나, 수동으로 중지될 수 있습니다. 인바운드 실행 작동 방식에 대한 자세한 내용은 인바운드 실행 작동 방식 단원을 참조하세요.

파이프라인 실행은 파이프라인 단계를 순서대로 순회합니다. 파이프라인의 유효한 상태는 InProgress, Stopping, Stopped, Succeeded, Superseded 및 Failed입니다.

자세한 내용은 을 참조하십시오 PipelineExecution.

중지된 실행

진행 중인 파이프라인 실행이 파이프라인을 통해 계속되지 않도록 파이프라인 실행을 수동으로 중지할 수 있습니다. 수동으로 중지한 경우 파이프라인 실행은 완전히 중지될 때까지 Stopping 상태로 표시됩니다. 그런 다음 Stopped 상태로 표시됩니다. Stopped 파이프라인 실행을 다시 시도할 수 있습니다.

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

• 중지 및 대기

• 중지 및 중단

실행 중지의 사용 사례에 대한 자세한 내용과 이러한 옵션에 대한 순서 세부 정보는 파이프라인 실행을 중지하는 방법 단원을 참조하십시오.

실패한 실행

실행이 실패하면 작업이 중지되고 파이프라인을 완전히 순회하지 못합니다. 상태는 FAILED 상태가 되고 단계는 잠금이 해제됩니다. 보다 최근의 실행은 잠금 해제된 단계를 파악해 잠글 수 있습니다. 실패한 실행이 대체되었거나 다시 시도할 수 없는 경우가 아니면 실패한 실행을 재시도할 수 있습니다.

실행 모드

파이프라인을 통해 최신 변경 집합을 전달하기 위해 보다 최근의 실행이 파이프라인을 통해 이미 실행 중인 덜 최근의 실행을 전달 및 대체합니다. 이 경우 이전 실행은 새로운 실행으로 대체됩니다. 실행은 단계 사이의 특정 지점에서 보다 최근의 실행으로 대체될 수 있습니다. 기본 실행 모드는 대체입니다.

SUPERSEDED 모드에서는 실행이 잠금 단계에 진입하기 위해 대기 중인 경우 최근 실행이 이를 따라잡아 대체할 수 있습니다. 이제 보다 최신의 실행이 단계가 잠금 해제될 때까지 대기하고, 대체된 실행은 SUPERSEDED 상태로 중지됩니다. 파이프라인 실행이 대체되면 실행이 중지되고 파이프라인을 완전히 순회하지 않게 됩니다. 이 단계에서 대체된 실행은 이후에 더 이상 재시도할 수 없습니다. 사용 가능한 다른 실행 모드로는 병렬 또는 대기열 모드가 있습니다.

실행 모드 및 잠긴 스테이지에 대한 자세한 내용은 을 참조하십시오. 대체 모드에서 실행이 처리되는 방법

단계 실행

단계 실행은 단계 내의 모든 작업을 완료하는 프로세스입니다. 단계 실행 작동 방식에 대한 자세한 내용 및 잠금 상태 단계에 대한 자세한 내용은 대체 모드에서 실행이 처리되는 방법을 참조하십시오.

단계의 유효한 상태는 InProgress, Stopping, Stopped, Succeeded 및 Failed입니다. 실패한 단계를 재시도할 수 없는 경우가 아니면 실패한 단계를 재시도할 수 있습니다. 자세한 내용은 을 참조하십시오 StageExecution.

작업 실행

작업 실행은 지정된 아티팩트에서 작동하는 구성된 작업을 완료하는 프로세스입니다. 입력 아티팩트, 출력 아티팩트 또는 둘 다가 여기에 해당될 수 있습니다. 예를 들어 빌드 작업은 애플리케이션 소스 코드 컴파일과 같은 입력 아티팩트에서 빌드 명령을 실행할 수 있습니다. 작업 실행 세부 정보에는 작업 실행 ID, 관련된 파이프라인 실행 소스 트리거, 작업의 입력 및 출력 아티팩트가 포함됩니다.

작업에 대한 유효한 상태는 InProgress, Abandoned, Succeeded 또는 Failed입니다. 자세한 내용은 을 참조하십시오 ActionExecution.

작업 유형

작업 유형은 에서 CodePipeline 선택할 수 있는 사전 구성된 작업입니다. 작업 유형은 소유자, 공급자, 버전 및 범주에 따라 정의됩니다. 작업 유형은 파이프라인에서 작업 태스크를 완료하는 데 사용되는 사용자 지정 파라미터를 제공합니다.

작업 유형에 따라 파이프라인에 통합할 수 있는 AWS 서비스와 타사 제품 및 서비스에 대한 자세한 내용은 CodePipeline 작업 유형과의 통합 단원을 참조하십시오.

에서 CodePipeline 작업 유형에 지원되는 통합 모델에 대한 자세한 내용은 을 참조하십시오통합 모델 참조.

에서 CodePipeline 타사 공급자가 작업 유형을 설정하고 관리하는 방법에 대한 자세한 내용은 을 참조하십시오작업 유형 처리.

Transitions

전환은 파이프라인 실행이 파이프라인의 다음 단계로 이동하는 지점입니다. 단계의 인바운드 전환을 비활성화하여 실행이 해당 단계로 들어가지 못하도록 한 다음, 전환을 활성화하여 실행을 계속할 수 있습니다. 둘 이상의 실행이 비활성화된 전환에 도달하면 가장 최신의 실행만 다음 단계로 계속되어 전환이 활성화됩니다. 즉, 전환이 비활성화된 동안 보다 최신의 실행이 대기 중인 실행을 계속 대체하고 전환이 활성화된 후에는 계속 진행되는 실행이 대체 실행이 됩니다.

아티팩트

아티팩트는 애플리케이션 소스 코드, 빌드된 애플리케이션, 종속성, 정의 파일, 템플릿 등과 같이 파이프라인 작업을 통해 만들어진 데이터 컬렉션을 의미합니다. 아티팩트는 일부 작업에서 생성되고 다른 작업에서 사용됩니다. 파이프라인에서 아티팩트는 작업에서 만들어진 파일 집합(입력 아티팩트)이거나 완료된 작업의 업데이트 출력(출력 아티팩트)이 될 수 있습니다.

작업은 파이프라인 아티팩트 버킷을 사용한 추가 처리를 위해 출력을 다른 작업에 전달합니다. CodePipeline 아티팩트를 아티팩트 저장소에 복사합니다. 그러면 액션이 아티팩트를 픽업합니다. 아티팩트에 대한 자세한 내용은 입력 및 출력 아티팩트 단원을 참조하십시오.

소스 개정

소스 코드를 변경하면 새 버전이 생성됩니다. 소스 개정은 파이프라인 실행을 트리거하는 소스 변경의 버전입니다. 실행 시 소스 수정이 처리됩니다. GitHub 및 CodeCommit 리포지토리의 경우 이것이 커밋입니다. S3 버킷 또는 작업의 경우 객체 버전이 여기에 해당됩니다.

지정한 커밋과 같은 소스 개정으로 파이프라인 실행을 시작할 수 있습니다. 실행 시 지정된 개정이 처리되고 실행에 사용된 개정이 재정의됩니다. 자세한 설명은 소스 개정 재정의로 파이프라인 시작 섹션을 참조하세요.

트리거

트리거는 파이프라인을 시작하는 이벤트입니다. 파이프라인 수동 시작과 같은 일부 트리거는 파이프라인의 모든 소스 작업 공급자가 사용할 수 있습니다. 특정 트리거는 파이프라인의 소스 공급자에 따라 달라집니다. 예를 들어, CloudWatch 이벤트 규칙의 대상으로 파이프라인 ARN이 추가된 CloudWatch Amazon의 이벤트 리소스로 이벤트를 구성해야 합니다. Amazon CloudWatch Events는 CodeCommit 또는 S3 소스 작업이 있는 파이프라인의 자동 변경 감지를 위한 권장 트리거입니다. Webhook는 타사 리포지토리 이벤트용으로 구성된 트리거 유형입니다. 예를 들어 WebHookv2는 Git 태그를 사용하여 .com, GitHub 엔터프라이즈 서버, GitHub .com, 자체 관리형 또는 Bitbucket Cloud와 같은 타사 소스 공급자와 함께 파이프라인을 시작할 수 있는 트리거 유형입니다. GitLab GitLab 파이프라인 구성에서 푸시 또는 풀 요청과 같은 트리거 필터를 지정할 수 있습니다. Git 태그, 브랜치 또는 파일 경로에서 코드 푸시 이벤트를 필터링할 수 있습니다. 이벤트 (열림, 업데이트, 닫힘), 브랜치 또는 파일 경로에서 풀 리퀘스트 이벤트를 필터링할 수 있습니다.

트리거에 대한 자세한 내용은 에서 파이프라인 시작 CodePipeline 주제를 참조하십시오. Git 태그를 파이프라인의 트리거로 사용하는 방법을 안내하는 자습서는 자습서: Git 태그를 사용하여 파이프라인 시작하기을 참조하십시오.

Variables

변수는 파이프라인에서 작업을 동적으로 구성하는 데 사용할 수 있는 값입니다. 변수는 파이프라인 수준에서 선언하거나 파이프라인의 작업에 의해 내보낼 수 있습니다. 변수 값은 파이프라인 실행 시 확인되며 실행 기록에서 확인할 수 있습니다. 파이프라인 수준에서 선언된 변수의 경우 파이프라인 구성에서 기본값을 정의하거나 지정된 실행에 대해 기본값을 재정의할 수 있습니다. 작업에서 내보낸 변수의 경우 작업이 성공적으로 완료된 후에 값을 사용할 수 있습니다. 자세한 내용은 Variables을(를) 참조하세요.