기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
에서 사용자 지정 작업 만들기 및 추가 CodePipeline
AWS CodePipeline 자동 릴리스 프로세스를 위한 리소스를 구성, 빌드, 테스트 및 배포하는 데 도움이 되는 여러 작업이 포함되어 있습니다. 릴리스 프로세스에 내부적으로 개발된 빌드 프로세스 또는 테스트 제품군 등의 기본 작업에 포함되지 않은 작업이 포함되어 있는 경우 해당 목적에 대한 사용자 지정 작업을 생성하고 이를 파이프라인에 포함할 수 있습니다. 를 사용하여 AWS 계정과 연결된 파이프라인에서 사용자 지정 작업을 만들 수 있습니다. AWS CLI
다음 AWS CodePipeline 작업 카테고리에 대해 사용자 지정 작업을 생성할 수 있습니다.
-
항목을 빌드 또는 변환하는 고객 빌드 작업
-
하나 이상의 서버, 웹 사이트 또는 리포지토리에 항목을 배포하는 고객 배포 작업
-
자동화된 테스트를 구성 및 실행하는 고객 테스트 작업
-
함수를 실행하는 고객 호출 작업
사용자 지정 작업을 만들 때는 이 사용자 지정 작업에 CodePipeline 대한 작업 요청을 폴링하고, 작업을 실행하고, 상태 결과를 에 반환하는 작업 작업자도 만들어야 CodePipeline 합니다. 이 작업 작업자는 퍼블릭 엔드포인트에 액세스할 수 있는 한 모든 컴퓨터 또는 리소스에 위치할 수 CodePipeline 있습니다. 액세스 및 보안을 손쉽게 관리하려면 Amazon EC2 인스턴스에 작업자를 호스팅합니다.
다음 다이어그램에서는 사용자 지정 빌드 작업이 포함된 파이프라인을 세부적으로 보여 줍니다.
파이프라인에 단계의 일부로 사용자 지정 작업이 포함되어 있으면 파이프라인에서 작업 요청이 생성됩니다. 사용자 지정 작업자가 해당 요청을 감지하고 해당 작업을 수행합니다(이 예에서는 타사 빌드 소프트웨어를 사용하는 사용자 지정 프로세스). 작업이 완료되면 작업자가 성공 결과 또는 실패 결과를 반환합니다. 성공 결과가 수신된 경우 파이프라인은 개정 사항과 아티팩트를 다음 작업에 제공합니다. 실패가 반환된 경우 파이프라인은 수정 사항을 파이프라인의 다음 작업에 제공하지 않습니다.
참고
이러한 지침에서는 시작하기 CodePipeline의 단계를 이미 완료한 것으로 가정합니다.
사용자 지정 작업 생성
를 사용하여 사용자 지정 작업을 만들려면 AWS CLI
-
텍스트 편집기를 열고 작업 범주, 작업 공급자 및 사용자 지정 작업에 필요한 모든 설정이 들어 있는 사용자 지정 작업용 JSON 파일을 생성합니다. 예를 들어, 하나의 속성만 필요로 하는 사용자 지정 빌드 작업을 생성하려면 다음과 같은 JSON 파일을 생성합니다.
{ "category": "Build", "provider": "My-Build-Provider-Name", "version": "1", "settings": { "entityUrlTemplate": "https://my-build-instance/job/{Config:ProjectName}/", "executionUrlTemplate": "https://my-build-instance/job/{Config:ProjectName}/lastSuccessfulBuild/{ExternalExecutionId}/" }, "configurationProperties": [{ "name": "ProjectName", "required": true, "key": true, "secret": false, "queryable": false, "description": "The name of the build project must be provided when this action is added to the pipeline.", "type": "String" }], "inputArtifactDetails": { "maximumCount":integer, "minimumCount":integer}, "outputArtifactDetails": { "maximumCount":integer, "minimumCount":integer}, "tags": [{ "key": "Project", "value": "ProjectA" }] }이 예제는 사용자 지정 작업에
Project태그 키와ProjectA값을 포함하여 사용자 지정 작업에 태그 지정을 추가합니다. 에서 CodePipeline 리소스에 태그를 지정하는 방법에 대한 자세한 내용은 을 참조하십시오 리소스에 태그 지정.JSON 파일에는
entityUrlTemplate과executionUrlTemplate의 두 가지 속성이 있습니다. 구성 속성이 필수이며 보안 사항이 아닌 경우,{Config:의 형식을 따라 URL 템플릿 내 사용자 지정 작업의 구성 속성에 있는 이름을 참조할 수 있습니다. 예를 들어 위 샘플에서name}entityUrlTemplate값은 구성 속성을ProjectName나타냅니다.-
entityUrlTemplate: 작업의 서비스 공급자에 대한 정보를 제공하는 정적 링크입니다. 예에서는 빌드 시스템에 각 빌드 프로젝트에 대한 정적 링크가 포함되어 있습니다. 링크 형식은 빌드 제공자에 따라 다를 수 있습니다(또는 테스트나 다른 서비스 공급자와 같이 서로 다른 작업 유형을 생성하는 경우). 사용자 지정 작업이 추가될 때 사용자가 이 링크를 선택하여 빌드 프로젝트(또는 테스트 환경)에 대한 세부 사항을 제공하는 웹 사이트의 페이지로 브라우저를 열 수 있도록 이 링크 형식을 제공해야 합니다. -
executionUrlTemplate: 작업의 현재 실행 또는 가장 최근의 실행에 대한 정보로 업데이트되는 동적 링크입니다. 사용자 지정 작업 작업자가 작업의 상태를 업데이트하면(예: 성공, 실패 또는 진행 중), 링크를 완성하는 데 사용되는externalExecutionId도 제공됩니다. 이 링크를 사용하면 작업 실행에 대한 세부 정보를 제공할 수 있습니다.
예를 들어, 파이프라인의 작업을 확인하면, 다음과 같은 두 개의 링크가 표시됩니다.
이 정적 링크는 사용자 지정 작업을 추가하면 표시되며 entityUrlTemplate의 주소를 가리킵니다. 이 주소는 사용자 지정 작업을 생성할 때 지정합니다.
이 동적 링크는 작업을 실행할 때마다 업데이트되며 executionUrlTemplate의 주소를 가리킵니다. 이 주소는 사용자 지정 작업을 생성할 때 지정합니다.이러한 링크 유형
RevisionURLTemplate및ThirdPartyURL및 에 대한 자세한 내용은 CodePipeline API CreateCustomActionTypeReference의 ActionTypeSettings및 를 참조하십시오. 작업 구조 요구사항 및 작업을 생성하는 방법에 대한 자세한 내용은 CodePipeline 파이프라인 구조 참조 단원을 참조하십시오. -
-
JSON 파일을 저장하고 쉽게 기억할 수 있는 이름을 지정합니다 (예:
MyCustomAction.json). -
AWS CLI를 설치한 컴퓨터에서 터미널 세션(Linux, OS X, Unix)이나 명령 프롬프트(Windows)를 엽니다.
-
AWS CLI 를 사용하여 방금 만든 JSON 파일의 이름을 지정하여 aws codepipeline create-custom-action-type 명령을 실행합니다.
예를 들어, 빌드 사용자 지정 작업을 만들려면 다음과 같이 입력합니다.
중요
파일 이름 앞에
file://를 포함해야 합니다. 이 명령에 필수적입니다.aws codepipeline create-custom-action-type --cli-input-json file://MyCustomAction.json -
이 명령은 생성한 사용자 지정 작업의 전체 구조뿐만 아니라 자동으로 추가된
JobList작업 구성 속성도 반환합니다. 파이프라인에 사용자 지정 작업을 추가하면JobList를 사용하여 작업에 대해 폴링할 수 있는 공급자의 프로젝트를 지정할 수 있습니다. 이를 구성하지 않으면 사용자 지정 작업 작업자가 작업에 대해 폴링할 때 사용 가능한 모든 작업이 반환됩니다.예를 들어 이전 명령은 다음과 유사한 구조를 반환할 수 있습니다.
{ "actionType": { "inputArtifactDetails": { "maximumCount": 1, "minimumCount": 1 }, "actionConfigurationProperties": [ { "secret": false, "required": true, "name": "ProjectName", "key": true, "description": "The name of the build project must be provided when this action is added to the pipeline." } ], "outputArtifactDetails": { "maximumCount": 0, "minimumCount": 0 }, "id": { "category": "Build", "owner": "Custom", "version": "1", "provider": "My-Build-Provider-Name" }, "settings": { "entityUrlTemplate": "https://my-build-instance/job/{Config:ProjectName}/", "executionUrlTemplate": "https://my-build-instance/job/mybuildjob/lastSuccessfulBuild/{ExternalExecutionId}/" } } }참고
이
id섹션에는 create-custom-action-type 명령 출력의 일부로 다음이 포함됩니다"owner": "Custom". CodePipeline 사용자 지정 작업 유형의Custom소유자로 자동 할당됩니다. 이 값은 create-custom-action-type 명령이나 update-pipeline 명령을 사용할 때는 할당하거나 변경할 수 없습니다.
사용자 지정 작업에 대한 작업자 생성
사용자 지정 작업을 수행하려면 사용자 지정 작업에 CodePipeline 대한 작업 요청을 폴링하고, 작업을 실행하고, 상태 결과를 에 반환하는 CodePipeline 작업 작업자가 필요합니다. 공용 엔드포인트에 대한 액세스 권한이 있는 한, 작업 작업자는 모든 컴퓨터 또는 리소스에 위치할 수 CodePipeline 있습니다.
작업자를 설계하는 방법에는 여러 가지가 있습니다. 다음 섹션에서는 맞춤형 작업 작업자를 개발하기 위한 몇 가지 실용적인 지침을 제공합니다 CodePipeline.
작업자에 대한 권한 관리 전략 선택 및 구성
에서 CodePipeline 맞춤형 작업을 위한 맞춤형 작업 작업자를 개발하려면 사용자 및 권한 관리를 통합하기 위한 전략이 필요합니다.
가장 간단한 전략은 통합에 필요한 리소스를 손쉽게 스케일 업할 수 있도록 IAM 인스턴스 역할을 사용하여 Amazon EC2 인스턴스를 생성함으로써 사용자 지정 작업자에 필요한 인프라를 추가하는 것입니다. 와 함께 AWS 기본 제공되는 통합 기능을 사용하여 사용자 지정 작업 작업자와 간의 상호 작용을 단순화할 수 CodePipeline 있습니다.
Amazon EC2 인스턴스를 설정하려면
-
Amazon EC2에 대해 자세히 알아보고 해당 통합 사례에 적합한 선택인지 확인합니다. 자세한 내용은 Amazon EC2 - 가상 서버 호스팅
을 참조하세요. -
Amazon EC2 인스턴스 생성을 시작합니다. 자세한 내용은 Amazon EC2 Linux 인스턴스 시작하기를 참조하세요.
고려해야 할 다른 전략은 IAM에 ID 페더레이션을 사용하여 기존의 자격 증명 공급자 시스템 및 리소스를 통합하는 것입니다. 이 전략은 기업 자격 증명 공급자가 이미 있거나 웹 자격 증명 공급자를 사용하여 사용자를 지원하도록 이미 구성되어 있는 경우에 특히 유용합니다. ID 페더레이션을 사용하면 IAM 사용자를 생성하거나 관리할 필요 없이 AWS 리소스에 대한 보안 액세스를 허용할 수 있습니다. CodePipeline 암호 보안 요구 사항 및 자격 증명 교체에 대한 기능과 정책을 사용할 수 있습니다. 샘플 애플리케이션을 고유한 설계를 위한 템플릿으로 사용할 수 있습니다.
ID 페더레이션을 설정하려면
-
IAM ID 페더레이션에 대해 자세히 알아봅니다. 자세한 내용은 연동 관리
를 참조하십시오. -
임시 액세스 부여를 위한 시나리오의 예를 검토하여 사용자 지정 작업의 요구에 가장 잘 맞는 시나리오를 식별하고 일시적으로 액세스합니다.
-
다음과 같이 자신의 인프라와 관련 있는 자격 증명 연동의 코드 예제를 살펴봅니다.
-
자격 증명 연동 구성을 시작합니다. 자세한 내용은 IAM 사용 설명서의 자격 증명 공급자 및 페더레이션 섹션을 참조하세요.
사용자 지정 작업 및 작업자를 실행할 때 다음 중 하나를 생성하여 AWS 계정 에서 사용합니다.
사용자가 AWS 외부 사용자와 상호 작용하려는 경우 프로그래밍 방식의 액세스가 필요합니다. AWS Management Console프로그래밍 방식의 액세스 권한을 부여하는 방법은 액세스하는 사용자 유형에 따라 다릅니다. AWS
사용자에게 프로그래밍 방식 액세스 권한을 부여하려면 다음 옵션 중 하나를 선택합니다.
| 프로그래밍 방식 액세스가 필요한 사용자는 누구인가요? | To | 액세스 권한을 부여하는 사용자 |
|---|---|---|
|
작업 인력 ID (IAM Identity Center가 관리하는 사용자) |
임시 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 API에 대한 프로그래밍 요청에 서명할 수 있습니다. AWS |
사용하고자 하는 인터페이스에 대한 지침을 따릅니다.
|
| IAM | 임시 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 API에 대한 프로그래밍 방식 요청에 서명할 수 있습니다. AWS | IAM 사용 설명서의 AWS 리소스와 함께 임시 자격 증명 사용의 지침을 따르십시오. |
| IAM | (권장되지 않음) 장기 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 API에 대한 프로그래밍 요청에 서명할 수 있습니다. AWS |
사용하고자 하는 인터페이스에 대한 지침을 따릅니다.
|
다음은 사용자 지정 작업자와 함께 사용하기 위해 생성할 수 있는 예제 정책입니다. 이 정책은 예로만 사용되며 있는 그대로 제공됩니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PollForJobs", "codepipeline:AcknowledgeJob", "codepipeline:GetJobDetails", "codepipeline:PutJobSuccessResult", "codepipeline:PutJobFailureResult" ], "Resource": [ "arn:aws:codepipeline:us-east-2::actionType:custom/Build/MyBuildProject/1/" ] } ] }
참고
AWSCodePipelineCustomActionAccess 관리형 정책을 사용해 보세요.
사용자 지정 작업에 대한 작업자 개발
권한 관리 전략을 선택한 후에는 담당 직원이 어떻게 상호 작용할지 고려해야 합니다. CodePipeline 다음의 상위 수준 다이어그램에서는 빌드 프로세스에 대한 사용자 지정 작업과 작업자의 워크플로우를 보여 줍니다.
-
구직 종사자가 을 (를) 사용하여
PollForJobs채용공고를 CodePipeline 대상으로 설문조사를 실시합니다. -
파이프라인이 소스 단계의 변경 사항으로 인해 트리거되면(예: 개발자가 변경 사항을 커밋하는 경우) 자동화된 릴리스 프로세스가 시작됩니다. 프로세스는 사용자 지정 작업이 구성된 단계에 이를 때까지 계속 진행됩니다. 이 단계에서 조치가 취해지면 작업을 CodePipeline 대기열에 추가합니다. 이 작업은 작업자가
PollForJobs를 다시 호출하여 상태를 가져오는 경우 나타납니다.PollForJobs에서 작업 세부 정보를 가져와서 작업자에 다시 전달합니다. -
작업자가 전화를 걸어 작업 승인을
AcknowledgeJob보냅니다 CodePipeline . CodePipeline 작업자가 작업을 계속해야 함을 나타내는 승인 메시지를 반환합니다 (InProgress). 또는 채용공고를 위해 투표하는 구직 종사자가 한 명 이상인데 다른 작업자가 이미 해당 작업을 신청한 경우에는InvalidNonceException오류 응답이 반환됩니다.InProgress승인 후 결과가 반환될 CodePipeline 때까지 기다립니다. -
작업자가 수정에 대한 사용자 지정 작업을 시작하면 작업이 실행됩니다. 다른 작업과 함께 사용자 지정 작업이 작업자에 결과를 반환합니다. 빌드 사용자 지정 작업의 예에서는 작업이 Amazon S3 버킷에서 아티팩트를 가져와서 빌드하고 성공적으로 빌드된 아티팩트를 Amazon S3 버킷으로 다시 푸시합니다.
-
작업이 실행 중인 동안 작업자는
executionUrlTemplate에 링크를 채우는 데 사용되는ExternalExecutionId정보뿐만 아니라 연속 토큰(작업자에 의해 생성된 작업 상태 직렬화, 예를 들어 JSON 형식의 빌드 식별자 또는 Amazon S3 객체 키)을 사용하여PutJobSuccessResult를 호출할 수 있습니다. 그러면 작동 링크가 있는 파이프라인의 콘솔 보기가 진행 중일 때 특정 작업 세부 정보로 업데이트됩니다. 필수는 아니지만 사용자가 실행 중인 사용자 지정 작업의 상태를 볼 수 있게 해주므로 모범 사례입니다.PutJobSuccessResult가 호출되면 작업이 완료된 것으로 간주됩니다. 연속 토큰이 CodePipeline 포함된 새 작업이 생성됩니다. 이 작업은 작업자가PollForJobs를 다시 호출하는 경우 나타납니다. 이 새 작업은 작업의 상태를 확인하는 데 사용할 수 있으며 연속 토큰을 사용하여 반환하거나 작업이 완료되면 연속 토큰 없이 반환합니다.참고
작업자가 사용자 지정 작업에 필요한 모든 작업을 수행하는 경우 처리 중인 작업자를 최소 두 단계로 나눠야 합니다. 첫 단계에서는 작업에 대한 세부 정보 페이지를 설정합니다. 세부 정보 페이지를 생성했으면 작업자의 상태를 직렬화하고 크기 제한(할당량 입력 AWS CodePipeline 참조)이 적용된 연속 토큰으로 반환할 수 있습니다. 예를 들어 연속 토큰으로 사용하는 문자열에 작업의 상태를 작성할 수 있습니다. 처리 중인 작업자의 두 번째 단계(및 후속 단계)에서는 작업의 실제 작업을 수행합니다. 마지막 단계는 성공 또는 실패를 CodePipeline 반환하며, 마지막 단계에는 연속 토큰이 없습니다.
연속 토큰 사용에 대한 자세한 내용은 CodePipeline API Reference의 사양을 참조하십시오.
PutJobSuccessResult -
사용자 지정 작업이 완료되면 작업 워커는 다음 두 API 중 하나를 CodePipeline 호출하여 사용자 지정 작업의 결과를 에 반환합니다.
-
PutJobSuccessResult(연속 토큰 없음), 사용자 지정 작업이 성공적으로 실행되었음을 나타냄 -
PutJobFailureResult, 사용자 지정 작업이 성공적으로 실행되지 않았음을 나타냄
결과에 따라 파이프라인은 다음 작업으로 계속 진행되거나(성공) 중지됩니다(실패).
-
사용자 지정 작업자 아키텍처 및 예
상위 수준 워크플로우를 매핑한 후 작업자를 생성할 수 있습니다. 결국 사용자 지정 작업의 세부 사항이 작업자에 필요한 사항을 결정하지만 사용자 지정 작업의 대다수 작업자에는 다음 기능이 포함되어 있습니다.
-
를 사용하여 수행한 작업에 대한 폴링. CodePipeline
PollForJobs -
작업 승인 및 결과 반환 CodePipeline
AcknowledgeJobPutJobSuccessResult, 및.PutJobFailureResult -
파이프라인에 대한 아티팩트를 Amazon S3 버킷에서 검색 및/또는 버킷에 배치. Amazon S3 버킷에서 아티팩트를 다운로드하려면 서명 버전 4 서명(Sig V4)을 사용하는 Amazon S3 클라이언트를 생성해야 합니다. 에는 Sig V4가 필요합니다. AWS KMS
Amazon S3 버킷에 아티팩트를 업로드하려면 암호화를 사용하도록 Amazon S3
PutObject요청을 추가로 구성해야 합니다. 현재 암호화에는 AWS 키 관리 서비스 (AWS KMS) 만 지원됩니다. AWS KMS 사용 AWS KMS keys. 아티팩트 업로드에 고객 관리 키를 사용할지 AWS 관리형 키 아니면 고객 관리 키를 사용할지 알기 위해서는 사용자 지정 작업 작업자가 작업 데이터를 보고 암호화 키 속성을 확인해야 합니다. 속성이 설정된 경우 구성할 AWS KMS때 해당 고객 관리 키 ID를 사용해야 합니다. 키 속성이 null인 경우 를 사용합니다. AWS 관리형 키 CodePipeline 달리 AWS 관리형 키 구성하지 않는 한 를 사용합니다.Java 또는 .NET에서 AWS KMS 파라미터를 생성하는 방법을 보여주는 예제는 AWS SDK를 사용하여 Amazon AWS Key Management Service S3에서 파라미터 지정을 참조하십시오. Amazon S3 버킷에 대한 자세한 내용은 CodePipeline 을 참조하십시오CodePipeline 개념 .
사용자 지정 작업 작업자의 더 복잡한 예는 에서 확인할 수 GitHub 있습니다. 이 샘플은 오픈 소스이며 있는 그대로 제공됩니다.
-
Job Worker 샘플 대상 CodePipeline
: GitHub 리포지토리에서 샘플을 다운로드하십시오.
파이프라인에 사용자 지정 작업 추가
작업 작업자가 있으면 새 작업을 만들고 파이프라인 생성 마법사를 사용할 때 선택하거나, 기존 파이프라인을 편집하고 사용자 지정 작업을 추가하거나, SDK 또는 API를 사용하여 파이프라인에 사용자 지정 작업을 추가할 수 있습니다. AWS CLI
참고
빌드 또는 배포 작업인 경우 사용자 지정 작업이 포함된 파이프라인 생성 마법사에서 파이프라인을 생성할 수 있습니다. 사용자 지정 작업이 테스트 범주에 있는 경우 기존 파이프라인을 편집하여 추가해야 합니다.
기존 파이프라인에 사용자 지정 작업 추가(CLI)
를 사용하여 기존 AWS CLI 파이프라인에 사용자 지정 작업을 추가할 수 있습니다.
-
터미널 세션(Linux, macOS 또는 Unix) 또는 명령 프롬프트(Windows)를 열고 get-pipeline 명령을 실행하여 편집하려는 파이프라인 구조를 JSON 파일에 복사합니다. 예를 들어
MyFirstPipeline이라는 파이프라인에 대해 다음 명령을 입력합니다.aws codepipeline get-pipeline --nameMyFirstPipeline>pipeline.json이 명령은 아무 것도 반환하지 않지만 생성한 파일이 명령을 실행한 디렉터리에 표시되어야 합니다.
-
텍스트 편집기에서 JSON 파일을 열고 파일 구조를 수정하여 사용자 지정 작업을 기존 단계에 추가합니다.
참고
해당 단계의 다른 작업과 동시에 작업을 실행하려면 작업에 해당 작업과 동일한
runOrder값을 지정해야 합니다.예를 들어, 파이프라인의 구조를 수정하여 Build라는 이름의 단계를 추가하고 해당 단계에 빌드 사용자 지정 작업을 추가하려는 경우, 다음과 같이 JSON을 수정하여 배포 단계 전에 Build 단계를 추가해야 할 수 있습니다.
, { "name": "MyBuildStage", "actions": [ { "inputArtifacts": [ { "name": "MyApp" } ], "name": "MyBuildCustomAction", "actionTypeId": { "category": "Build", "owner": "Custom", "version": "1", "provider": "My-Build-Provider-Name" }, "outputArtifacts": [ { "name": "MyBuiltApp" } ], "configuration": { "ProjectName": "MyBuildProject" }, "runOrder": 1 } ] }, { "name": "Staging", "actions": [ { "inputArtifacts": [ { "name": "MyBuiltApp" } ], "name": "Deploy-CodeDeploy-Application", "actionTypeId": { "category": "Deploy", "owner": "AWS", "version": "1", "provider": "CodeDeploy" }, "outputArtifacts": [], "configuration": { "ApplicationName": "CodePipelineDemoApplication", "DeploymentGroupName": "CodePipelineDemoFleet" }, "runOrder": 1 } ] } -
변경 사항을 적용하려면 다음과 유사하게 파이프라인 JSON 파일을 지정하여 update-pipeline 명령을 실행합니다.
중요
파일 이름 앞에
file://를 포함해야 합니다. 이 명령에 필수적입니다.aws codepipeline update-pipeline --cli-input-json file://pipeline.json이 명령은 편집한 파이프라인의 전체 구조를 반환합니다.
-
CodePipeline 콘솔을 열고 방금 편집한 파이프라인 이름을 선택합니다.
파이프라인에 변경 사항이 표시됩니다. 다음에 사용자가 소스 위치를 변경할 경우, 파이프라인의 개정된 구조를 통해 해당 개정이 실행됩니다.
