클래식 Delivery Pipeline 개요

IBM Cloud® Continuous Delivery에는 사용자 개입을 최소화하여 반복적 방식으로 빌드, 테스트 및 배치를 수행할 수 있도록 클래식 Delivery Pipeline이 포함됩니다. 파이프라인에서는 일련의 단계에서 입력을 검색하고 작업(예: 빌드, 테스트 및 배치)을 실행합니다.

브라우저를 사용하거나 IBM Cloud CLI Developer Tools(ibmcloud dev)명령 을 사용하여 Classic및 Tekton Delivery Pipeline 모두에 대해 작업할 수 있습니다. Tekton 파이프라인 HTTP API및 SDK를 사용하거나 IBM Cloud Terraform 제공자 를 사용하여 Tekton 전달 파이프라인에 대해 작업할 수도 있습니다. 텍톤 배달 파이프라인에 대한 자세한 내용은 텍톤 파이프라인으로 작업하기를 참조하세요.

파이프라인을 보거나 수정하거나 실행할 권한은 파이프라인을 소유한 도구 체인의 액세스 제어를 기반으로 합니다. 도구 체인의 액세스 제어에 대한 자세한 정보는 리소스 그룹의 도구 체인에 대한 액세스 관리 를 참조하십시오.

파이프라인에서 제공하는 다수의 작업 유형에서 실행될 스크립트를 지정하여 작업에 의해 실행되는 작업을 직접 제어할 수 있습니다. 이러한 스크립트는 IBM Cloud 런타임과 상호작용하는데 필요한 도구를 포함한 많은 표준 개발 도구를 포함하고 있는 Docker 이미지에서 실행됩니다. 표준 Docker 이미지에 포함된 항목에 대한 자세한 정보는 사전 설치된 리소스를 참조하십시오. 작업에 표준 이미지에서 사용할 수 없는 개발 도구가 필요하거나 해당 도구의 다른 버전이 필요한 경우 사용자 정의 이미지를 사용할 수 있습니다. 사용자 정의 이미지에 대한 자세한 정보는 사용자 정의 Docker 이미지에 대한 작업을 참조하십시오.

파이프라인에서 스크립트를 실행하면 작업이 실행되고 있는 컨텍스트를 설명하는 특성은 환경 변수를 사용하여 스크립트에 전달됩니다. 예를 들면, 단계에 대한 입력인 저장소의 URL, 실행되고 있는 단계와 작업의 이름, 작업 유형에 의해 지정된 매개변수 등입니다. 사용 가능한 환경 변수 목록을 보려면 사전 설치된 리소스를 참조하십시오.

파이프라인 레벨과 단계 레벨 모두에 특성을 정의할 수 있습니다. 파이프라인 특성은 파이프라인의 모든 단계와 작업에서 공유됩니다. 단계 특성은 특정 단계에 고유하며 해당 단계의 모든 작업에서 공유됩니다. 특성에 대한 자세한 정보는 환경 특성(환경 변수)을 참조하십시오.

스테이지

단계는 코드가 빌드, 배치 및 테스트됨에 따라 입력 및 작업을 구성합니다. 단계에서는 소스 제어 저장소(SCM 저장소) 또는 다른 단계에 있는 빌드 작업의 입력을 승인합니다. SCM 저장소의 경우 입력은 저장소의 특정 분기 컨텐츠입니다. 빌드 작업의 경우 입력은 작업에 의해 생성되는 아티팩트입니다. 첫 번째 단계를 작성할 때 입력 탭에 기본 설정이 포함되어 있습니다.

단계가 실행되면 해당 단계의 입력사항이 해당 단계의 각 작업에 전달됩니다. 각 작업에는 실행할 클린 컨테이너가 제공됩니다. 결과적으로 단계 내에 있는 작업에서는 아티팩트를 서로 전달할 수 없습니다. 작업 내에서 아티팩트를 전달하려면 작업을 두 단계로 분리하고 첫 번째 단계에서의 작업 출력을 두 번째 단계에 대한 입력으로 사용하십시오. 모든 빌드 작업은 다른 단계에서 기타 모든 작업에 입력으로 전달될 수 있습니다. 기본적으로 출력은 ./ 폴더에 작성됩니다. 빌드 작업의 출력을 원하지 않으면 폴더를 출력으로 구성하고 해당 폴더로 출력을 보내지 마십시오.

파이프라인 특성을 정의할 수 있는 방법과 유사하게 특정 단계의 모든 작업에 사용할 단계 특성을 정의할 수도 있습니다. 예를 들어, TEST_URL 특성을 정의하여 단계에서 URL을 배치 및 테스트 작업에 전달할 수 있습니다. 배치 작업에서는 해당 URL에 배치하고 테스트 작업에서는 해당 URL에서 실행 앱을 테스트합니다. 단계 특성도 환경 변수를 사용하여 작업 스크립트에 전달됩니다. 파이프라인 레벨과 단계 레벨 모두에 동일한 특성이 정의되면 단계 특성의 값이 사용됩니다.

기본적으로 한 단계에서, 변경사항이 프로젝트의 SCM 저장소로 전달될 때마다 빌드 및 배치가 자동으로 실행됩니다. 단계 및 작업은 직렬로 실행되므로 작업 플로우를 제어할 수 있습니다. 예를 들어, 배치 단계 앞에 테스트 단계를 놓을 수 있습니다. 테스트 단계의 테스트가 실패하면 배치 단계가 실행되지 않습니다.

Delivery Pipeline에서는 공용 및 개인용 작업자를 사용하여 단계에서 작업을 실행합니다. 기본적으로 파이프라인 작업은 IBM 관리 공용 공유 인프라에서 공용 작업자를 사용하여 실행됩니다.

특정 시나리오에서는 Delivery Pipeline에 내부 또는 온프레미스 리소스에 대한 액세스 권한이 필요할 수도 있습니다. 이러한 상황에서 Delivery Pipeline Private Worker를 연결하고 통합하여 고유 Kubernetes 인프라에서 실행할 수 있습니다.

특정 단계를 면밀히 제어할 수 있습니다. 해당 입력에서 변경이 발생할 때마다 단계가 실행되도록 하지 않으려면 해당 기능을 사용 불가능하게 설정하십시오. 입력 탭의 단계 트리거 섹션에서 이 단계를 수동으로 실행할 때만 작업 실행을 클릭하십시오.

추가 단계 트리거 옵션은 Git 저장소 입력 유형을 사용하는 단계를 위해 사용할 수 있습니다. 예를 들어, 선택한 분기에서 Git 이벤트에 대해 작업을 자동으로 실행하도록 선택할 수 있습니다. 이 트리거 유형을 선택할 때 다음 이벤트 유형 중 하나 이상을 선택해야 합니다.

선택한 저장소 분기에 대한 푸시가 이루어지는 경우 커미트가 푸시될 때가 트리거됨
가져오기 요청 또는 병합 요청을 열거나 편집하는 경우 가져오기/병합 요청을 열거나 업데이트할 때가 트리거됩니다.
연관된 커미트가 없어도 가져오기 요청 또는 병합 요청이 처리완료되는 경우 가져오기/병합 요청이 처리완료될 때가 트리거됩니다.

가져오기/병합 요청이 열리거나 업데이트된 경우 선택란을 선택하면 파이프라인의 상태가 Git 저장소로 리턴됩니다. 가져오기 요청 또는 병합 요청이 파이프라인을 트리거하면 페이지에 인라인 상태 확인이 표시됩니다. 상태 확인은 파이프라인에서 실행되는 각 스테이지에 대해 표시되고 각 스테이지의 로그 및 히스토리에 대한 링크가 제공됩니다. 상태 확인이 실행되면 보류 중에서 성공 또는 실패로 업데이트됩니다. 파이프라인에 여러 단계가 포함되어 있는 경우 각 단계는 선택 목록에서 해당 상태를 보고합니다.

이 상태 피드백은 병합 요청을 위해 IBM 호스팅 GitLab Community Edition 도구에서도 지원됩니다.

또한 Git 분기 보호 규칙을 사용하여 상태 검사 결과에 따라 병합을 제한할 수 있습니다. 분기 보호 규칙이 작성된 후 모든 필수 상태 검사가 성공할 때까지 모든 병합이 차단됩니다.

Bitbucket Cloud 가져오기 요청

Bitbucket Cloud는 현재 Continuous Delivery 서비스에서 필요로 하는 가져오기 요청에 대한 저장소 참조를 지원하지 않습니다. 이 기능을 통해 refs/pull/123/… 형식의 참조를 사용하여 액세스하려는 저장소로 가져오기 요청을 전송할 수 있습니다.

소스 리포지토리 URL을 사용하여 풀 리퀘스트를 로컬로 가져와 체크아웃할 수 있습니다. 그러나 소스 저장소가 개인용 분기 실행 저장소인 경우 Continuous Delivery 서비스는 가져오기 요청을 관리하는 데 필요한 액세스 권한이 없습니다. 이 제한사항을 해결하려면 파이프라인 스크립트에서 분기 실행 저장소에 대한 필수 액세스 권한을 명시적으로 제공해야 합니다.

다음 샘플 bash 파이프라인 스크립트에서는 두 명의 사용자가 Bitbucket Cloud를 사용 중이고 기본 저장소의 각 개인용 분기 실행이 있습니다(bitbucket.org/userA/repo-forked-A and bitbucket.org/userB/repo-forked-B). 스크립트는 빌드 작업이 두 개의 분기 실행 저장소 중 하나에서 가져오기 요청 열기 이벤트 또는 업데이트 이벤트로 트리거될 때 가져오기 요청을 확인하도록 설정되어 있습니다.

case "$BITBUCKET_PR_SOURCE_HOST" in       #BITBUCKET_PR_SOURCE_HOST is an environment exported by pipeline if job is triggered by a bitbucket pull request
  *userA*)                                #userA should be replaced to anything to identify a forked repo's url
    url="https://$username:$password@$BITBUCKET_PR_SOURCE_HOST"    #you need to provide username and password for repo-forked-A
    ;;
  *userB/repo-forked-B*)                  #userB/repo-forked-B should be replaced to anything to identify a forked repo's url
    url="https://$username1:password1@$BITBUCKET_PR_SOURCE_HOST"   #you need to provide username1 and password1 for repo-forked-B
    ;;
esac
git fetch $url $BITBUCKET_PR_SOURCE_BRANCH   #BITBUCKET_PR_SOURCE_BRANCH is an environment exported by pipeline if job is triggered by a bitbucket pull request
git checkout FETCH_HEAD

빌드 스테이지

빌드 단계는 아티팩트 빌드 방법을 표시하기 위해 빌더 유형을 지정합니다.

빌드 작업에서 사용 가능한 필드 중 다수는 다중 빌더 유형 전체에서 공통입니다.

다음 빌더 유형을 사용할 수 있습니다.

빌더 유형
빌더 유형	설명	지원되는 작업 유형
단순	향후 단계에서 사용할 수 있도록 수정 없이 현재 단계의 입력을 아카이브합니다. 일반적으로, 이 빌더 유형은 SCM 저장소에서의 단계의 입력인 경우에만 유용합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오.
Ant	Apache Ant 파일을 사용하여 빌드 작업을 관리합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉터리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉터리를 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
Container registry	Docker 이미지를 빌드하고 이를 IBM Cloud Container Registry에 업로드합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. API 키: 계정 리소스에 대한 권한을 제공하는 데 사용할 IBM Cloud API Container Registry 네임스페이스: 빌드한 이미지를 저장할 Docker 이미지 이름: 이 작업이 빌드하여 IBM Cloud Container Registry 업로드하는 이미지의 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉터리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉터리를 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
사용자 정의 Docker 이미지	노드, Java™ 또는 기타 도구의 버전을 세밀하게 제어할 수 있는 사용자 지정 도커 이미지를 사용하여 빌드합니다.	Docker 이미지 이름: 이 작업이 빌드하여 IBM Cloud Container Registry 업로드하는 이미지의 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 빌드 아카이브 디렉터리: 후속 단계에서 사용하기 위해 아카이브할 작업의 출력이 포함된 디렉터리를 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
Gradle	Gradle을 사용하여 빌드합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉토리- 후속 단계에서 사용할 수 있도록 작업의 출력이 포함된 디렉터리를 아카이브하도록 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
Grunt	Grunt를 사용하여 빌드합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉터리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉터리를 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
Maven	Apache Maven을 사용하여 빌드합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉터리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉터리를 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
npm	노드 패키지 관리자를 사용하여 종속 항목을 설치합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉터리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉터리를 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
쉘 스크립트	UNIX 쉘 스크립트(예: Bash)를 실행합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 빌드 스크립트: 작업 실행 시마다 새 Ubuntu 쉘에서 실행됩니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉터리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉터리를 테스트 보고서 사용: 빌드 작업이 JUnit XML 형식으로 결과 파일을 생성하는 테스트를 실행하도록 지정하려면 이 선택란을 선택하십시오. 결과 파일을 기반으로 한 보고서가 작업 결과 페이지의 테스트 탭에 표시됩니다. 테스트에 실패하는 경우 작업은 '실패'로 표시됩니다. 코드 적용 범위 보고서 사용: 코드 적용 범위 보고서에 사용할 수 있는 추가 필드를 표시하려면 이 선택란을 선택하십시오. 작업 디렉터리를 기준으로 커버리지 런너(예: JaCoCo,, Cobertura), 커버리지 결과 파일의 위치, 커버리지 결과 디렉터리를 지정할 수 있습니다.
Gradle(Artifactory, Nexus 또는 SonarQube)	Nexus 또는 Artifactory 저장소에서 Gradle을 사용하여 빌드 및 배치합니다. Gradle은 SonarQube와도 통합됩니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 리포지토리 도구 통합 인스턴스: 이 빌드 작업에 사용할 리포지토리 도구 통합 인스턴스의 리포지토리 도구 통합 유형: Gradle 정보를 가져올 도구 통합 SonarQube 통합 인스턴스입니다: 이 빌드 작업에 사용할 SonarQube 통합 인스턴스의 빌드 명령: 작업 실행 시마다 실행할 빌드 명령입니다. 스크립트 필드에 프로젝트의 소스 컨트롤에 저장된 스크립트 또는 참조 스크립트를 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉토리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉토리를 지정합니다.
Maven(Artifactory, Nexus 또는 SonarQube)	Nexus 또는 Artifactory 저장소에서 Maven을 사용하여 빌드 및 배치합니다. Maven은 SonarQube와도 통합됩니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 리포지토리 도구 통합 인스턴스: 이 빌드 작업에 사용할 리포지토리 도구 통합 인스턴스의 리포지토리 도구 통합 유형: Gradle 정보를 가져올 도구 통합 SonarQube 통합 인스턴스입니다: 이 빌드 작업에 사용할 SonarQube 통합 인스턴스의 빌드 명령: 작업 실행 시마다 실행할 빌드 명령입니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉토리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉토리를 지정합니다.
npm(Artifactory 또는 Nexus)	Nexus 또는 Artifactory 저장소에서 npm을 사용하여 빌드합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 리포지토리 도구 통합 인스턴스: 이 빌드 작업에 사용할 리포지토리 도구 통합 인스턴스의 리포지토리 도구 통합 유형: Gradle 정보를 가져올 도구 통합 SonarQube 통합 인스턴스입니다: 이 빌드 작업에 사용할 SonarQube 통합 인스턴스의 빌드 명령: 작업 실행 시마다 실행할 빌드 명령입니다. 스크립트 필드에 프로젝트의 소스 컨트롤에 저장된 스크립트 또는 참조 스크립트를 스냅샷 모듈 버전 증가: 게시 단계에서 `package.json` 파일의 내용과 npm 레지스트리에 보고된 현재 스냅샷을 기반으로 로컬에서 모듈 버전을 증분하여 연속 배포를 지원합니다 작업 디렉터리: 스크립트가 실행되는 디렉터리를 지정합니다 빌드 아카이브 디렉토리: 후속 단계에서 사용할 수 있도록 아카이브할 작업의 출력이 포함된 디렉토리를 지정합니다.

배치 단계

배치 단계는 빌드 단계의 입력을 지정합니다. 배치 단계의 작업은 배치자 유형을 지정합니다. 다음 배치자 유형을 사용할 수 있습니다.

배포자 유형
배치자 유형	설명	지원되는 작업 유형
사용자 정의 Docker 이미지	노드, Java™ 또는 기타 도구의 버전을 세밀하게 제어할 수 있는 사용자 지정 Docker 이미지를 사용하여 배포합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. API 키: 계정 리소스에 대한 권한을 제공하는 데 사용할 IBM Cloud API Docker 이미지 이름: 이 작업이 빌드하여 IBM Cloud Container Registry 업로드하는 이미지의 배치 스크립트: 작업 실행 시마다 실행할 배치 명령입니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오.
Kubernetes	Kubernetes 클러스터(예: IBM Cloud Container Service 내에 있는 클러스터)에 애플리케이션을 배치합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. API 키: 계정 리소스에 대한 권한을 제공하는 데 사용할 IBM Cloud API 클러스터 이름: Name of the Kubernetes cluster; the platform that you deploy your Kubernetes components on. 배치 스크립트: 작업 실행 시마다 실행할 배치 명령입니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오.

테스트 단계

테스트 단계는 테스트 구성을 지정합니다. 테스트 단계의 작업은 테스터 유형을 지정합니다. 다음 테스터 유형을 사용할 수 있습니다.

테스터 유형
테스터 유형	설명	지원되는 작업 유형
단순	선택적 테스트 보고서를 사용하여 자동화된 테스트를 실행하는 쉘 명령을 시작합니다.	파이프라인 이미지 버전: 사용되지 않습니다. 테스트 스크립트: 작업 실행 시마다 실행할 테스트 명령입니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 테스트 스크립트가 실행되는 테스트 보고서 사용: 사용되지 않습니다. 코드 적용 범위 보고서 사용: 사용되지 않습니다.
사용자 정의 Docker 이미지	노드, Java™ 또는 기타 도구의 버전을 세밀하게 제어할 수 있는 사용자 지정 Docker 이미지를 사용하여 테스트합니다.	Docker 이미지 이름: 작업을 실행할 Docker 이미지의 이름입니다. 작업이 정리된 컨텍스트에서 실행되도록 보장하려면 Docker 컨테이너에서 이를 실행하십시오. 테스트 스크립트: 작업 실행 시마다 실행할 테스트 명령입니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 테스트 스크립트가 실행되는 테스트 보고서 사용: 사용되지 않습니다. 코드 적용 범위 보고서 사용: 사용되지 않습니다.
Vulnerability Advisor	지정된 이미지에 대해 규제 준수 및 취약성 검사를 실행하고 결과를 표시합니다. 문제가 발견되면 이 단계는 실패합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. API 키: 계정 리소스에 대한 권한을 제공하는 데 사용할 IBM Cloud API Container Registry 네임스페이스: 빌드된 이미지가 저장되는 Docker 이미지 이름: 작업을 실행할 Docker 이미지의 이름입니다. 작업이 정리된 컨텍스트에서 실행되도록 보장하려면 Docker 컨테이너에서 이를 실행하십시오. Docker 이미지 태그: IBM Cloud Container Registry 표시되는 Docker 이미지의 태그입니다 테스트 스크립트: 작업 실행 시마다 실행할 테스트 명령입니다. 스크립트 필드에서 프로젝트의 소스 제어에 저장된 스크립트 또는 참조 스크립트를 입력하십시오. 작업 디렉터리: 테스트 스크립트가 실행되는 테스트 보고서 사용: 사용되지 않습니다. 코드 적용 범위 보고서 사용: 사용되지 않습니다.
Sauce Labs	Sauce Labs를 사용하여 JavaScript, Node 또는 Java™ 테스트를 실행합니다.	파이프라인 이미지 버전: 다양한 내장형 명령을 제공하는 내장형 Docker 이미지를 사용하여 컨테이너에서 실행됩니다. 해당 명령의 새 버전을 채택하려면 새 이미지 버전을 사용하십시오. 서비스 인스턴스: 구성 인스턴스를 선택하거나 이를 새로 작성하십시오.

더 이상 사용되지 않는 작업 유형

IBM Globalization Pipeline 빌드 작업, 스페이스 셸 테스트 작업 및 DevOps Insights 게이트 테스트 작업과 같은 여러 작업 유형이 더 이상 사용되지 않습니다. 이러한 작업 유형은 더 이상 사용되지 않지만 작업 유형이 더 이상 사용되지 않음을 나타내는 표시기를 사용하여 여전히 UI에 로드할 수 있습니다. 또는 작업이 경고 알림을 사용하여 여전히 지원되는 다른 작업 유형으로 되돌아갈 수 있습니다.

더 이상 사용되지 않는 작업 유형의 구성을 사용해야 하는 경우 다음 방법 중 하나를 사용하여 파이프라인 구성에 액세스하십시오.

IBM Cloud Devtool을 사용하십시오.

ic dev pipeline-get 7325f511-492a-4c35-a388-5e499e65d6bb -output JSON

Delivery Pipeline API를 사용하십시오.

curl --location --request GET 'https://devops-api.us-south.devops.cloud.ibm.com/v1/pipeline/pipelines/7325f511-492a-4c35-a388-5e499e65d6bb/stages' \
--header 'Authorization: Bearer <IAM Bearer token>

Delivery Pipeline UI의 네트워크 탭에서 파이프라인 ID로 필터하여 더 이상 사용되지 않는 작업 유형 데이터를 포함하는 파이프라인을 찾으십시오.

API 키

Some of the standard pipeline jobs use IBM Cloud API keys to access services, such as deploying to Kubernetes. IBM Cloud IAM(Identity and Access Management) 서비스는 두 가지 유형의 API 키를 제공합니다.

사용자 API 키: 이러한 API 키는 사용자가 액세스하는 서비스 및 리소스 모두에 대한 전체 액세스 권한을 제공합니다.
서비스 API 키: 다양한 서비스 및 리소스에 대해 특정 액세스 권한을 제공하도록 서비스 API 키를 구성할 수 있습니다.

일부 서비스는 서비스 ID API키를 사용할 수 없습니다. 이러한 경우 파이프라인 사용자 인터페이스에서 사용자가 사용자 API 키를 지정하도록 합니다.

파이프라인 작업에서는 임의의 방식으로 서비스 API 키를 사용할 수 있는 사용자 작성 스크립트를 실행하므로, 파이프라인은 특정 키에 적용할 제한사항 세트를 판별할 수 없습니다. 이러한 경우 파이프라인이 API 키를 작성하도록 요청하면 사용자 API 키가 작성됩니다. 강력한 보안을 유지보수하기 위해 스크립트에 필요한 서비스 및 리소스로만 제한되는 액세스로 서비스 API 키를 대신 사용하십시오. 이 경우 API 키를 직접 작성해야 합니다. API 키 작성에 대한 자세한 정보는 IBM Cloud API 키를 참조하십시오.

작업

작업은 단계 내의 실행 단위입니다. 단계에는 여러 작업이 포함될 수 있으며, 단계 내의 작업은 순차적으로 실행됩니다. 기본적으로 하나의 작업이 실패하면 단계 내의 후속 작업이 실행되지 않습니다.

작업은 각 파이프라인 실행을 위해 작성된 Docker 컨테이너 내의 개별 작업 디렉토리에서 실행됩니다. 작업이 실행되기 전에 해당 작업 디렉토리는 단계 레벨에서 정의된 입력으로 채워집니다. 예를 들어, 하나의 테스트 작업과 하나의 배치 작업을 포함하는 단계가 있을 수 있습니다. 하나의 작업에 종속 항목을 설치하는 경우 다른 작업에서는 이를 사용할 수 없습니다. 그러나 단계의 입력에서 종속 항목을 사용 가능하게 설정하면 두 작업 모두 해당 종속 항목을 사용할 수 있습니다.

단순 유형 빌드 작업을 제외하곤, 작업을 구성할 때 빌드, 테스트 또는 배치 명령이 포함된 UNIX 쉘 스크립트를 포함시킬 수 있습니다. 작업은 임시 컨테이너에서 실행되므로 작업이 같은 단계에 속하는 경우에도 한 작업의 조치는 다른 작업의 실행 환경에 영향을 미칠 수 없습니다.

샘플 빌드 및 배포 스크립트는 https://github.com/open-toolchain/commons 에서 확인할 수 있습니다.

또한 파이프라인 작업은 sudo로서 다음 명령만 실행할 수 있습니다.

/usr/sbin/service
/usr/bin/apt-get
/usr/bin/apt-key
/usr/bin/dpkg
/usr/bin/add-apt-repository
/opt/IBM/node-v0.10.40-linux-x64/npm
/opt/IBM/node-v0.12.7-linux-x64/npm
/opt/IBM/node-v4.2.2-linux-x64/npm
/usr/bin/Xvfb
/usr/bin/pip

작업이 실행된 후에는 그 작업을 위해 작성된 컨테이너가 버려집니다. 작업 실행의 결과는 유지될 수 있지만 작업이 실행된 환경은 유지되지 않습니다.

작업은 최대 60분 동안 실행될 수 있습니다. 작업이 이 한계를 초과하면 작업이 실패합니다. 하나의 작업이 이 한계를 초과하는 경우에는 작업을 여러 개의 작업으로 나누십시오. 예를 들어, 작업이 세 개의 태스크를 수행하는 경우 이 작업을 세 개의 작업(태스크당 하나의 작업)으로 나눌 수 있습니다.

단계에 작업을 추가하는 방법을 알아보려면 단계에 작업 추가를 참조하십시오.

빌드 작업

빌드 작업은 배치를 준비하기 위해 프로젝트를 컴파일합니다. 빌드 작업은 빌드 아카이브 디렉토리로 전송할 수 있는 아티팩트(기본적으로 프로젝트의 루트 디렉토리에 배치됨)를 생성합니다.

빌드 작업에서 입력되는 작업은 빌드 아티팩트를 작성 시와 동일한 구조로 참조해야 합니다. 예를 들어, 빌드 작업이 빌드 아티팩트를 output 디렉토리에 아카이브하는 경우 배치 스크립트는 프로젝트 루트 디렉토리가 아니라 output 디렉토리를 참조하여 컴파일된 프로젝트를 배치합니다. 아카이브 디렉토리 빌드 필드에 디렉토리 이름을 입력하여 아카이브할 디렉토리를 지정할 수 있습니다. 필드를 공백으로 두면 루트 디렉토리를 아카이브합니다.

단순 빌더 유형을 사용하는 경우 코드가 컴파일되거나 빌드되지 않습니다. 다음 단계를 위해 패키지되고 사용 가능하도록 설정됩니다.

배치 작업

배치 작업은 프로젝트를 IBM Cloud에 앱으로 업로드하며, URL에서 액세스할 수 있습니다. 프로젝트가 배치되고 나면 배치된 앱을 IBM Cloud 대시보드에서 찾을 수 있습니다.

배치 작업은 새 앱을 배치하거나 기존 앱을 업데이트할 수 있습니다. 다른 방법을 사용하여 앱을 처음 배치한 경우에도 배치 작업을 사용하여 앱을 업데이트할 수 있습니다. 앱을 업데이트하려면 배치 작업에서 해당 앱의 이름을 사용하십시오.

하나 또는 다수의 지역과 서비스에 배치할 수 있습니다. 예를 들면, Delivery Pipeline이 하나 이상의 서비스를 사용하고 한 지역에서 테스트되며 여러 지역의 프로덕션에 배치되도록 설정할 수 있습니다.

테스트 작업

조건이 충족되도록 하려면 빌드 및 배치 작업의 앞이나 뒤에 테스트 작업을 포함시키십시오. 필요에 따라 단순하거나 복잡하도록 테스트 작업을 사용자 정의할 수 있습니다. 예를 들어, cURL 명령을 실행하고 특정 응답을 예상할 수 있습니다. 또한 단위 테스트 스위트를 실행하거나 서드파티 서비스(예: Sauce Labs)로 기능 테스트를 실행할 수도 있습니다.

테스트로 인해 JUnit XML 형식의 결과 파일이 생성되는 경우, 결과 파일에 기반한 보고서가 각 테스트 결과 페이지의 테스트 탭에 표시됩니다. 테스트가 실패하면 작업도 실패합니다.

환경 특성(환경 변수)

사전정의된 환경 특성 세트를 통해 작업 실행 환경에 대한 정보에 액세스할 수 있습니다. 사전정의된 환경 특성의 전체 목록은 환경 특성 및 리소스를 참조하십시오.

사용자 고유의 환경 특성을 정의할 수도 있습니다. 예를 들면, 파이프라인의 모든 스크립트에서 IBM Cloud 리소스에 액세스하는 데 사용하는 API 키를 전달하는 API_KEY 특성을 정의합니다.

다음 유형의 특성을 추가할 수 있습니다.

텍스트: 단일 행 값을 갖는 특성 키입니다.
텍스트 영역: 다중 행 값을 갖는 특성 키입니다. 각 텍스트 영역 특성 값의 Base-64 버전도 사용 가능합니다. 접미부가 _base641인 특성 키 이름을 사용하여 이 버전에 액세스할 수 있습니다. echo "$(echo $multi_base64 | base64 -d)"를 입력하여 텍스트 영역 특성의 Base-64 버전을 디코딩하고 에코잉할 수 있습니다. 여기서 multi는 정의한 특성 키 이름이고 multi_base64는 제공된 추가 특성입니다. 파이프라인 기본 이미지에는 다중 행 인코딩을 투명하게 관리하도록 지원하는 기본 제공 기능이 있습니다. 하지만 사용자 정의 이미지를 사용하는 경우, 행의 끝으로 값이 잘리는 문제를 방지하려면 _base64 접미부 특성을 추가해야 합니다.
보안: AES-128 암호화를 통해 보호되는 단일 행 값이 있는 특성 키입니다. 이 값은 별표로 표시됩니다.
특성: 프로젝트의 저장소에 있는 파일입니다. 이 파일에는 여러 특성이 포함될 수 있습니다. 각 특성은 자체 고유의 행에 위치해야 합니다. 키-값 쌍을 분리하려면 등호(=)를 사용하십시오. 모든 문자열 값을 따옴표로 묶으십시오. 예를 들어, MY_STRING="SOME STRING VALUE"입니다.

작업 스크립트에서 env 명령을 실행하여 파이프라인 작업에 대한 환경 특성을 조사할 수 있습니다.

파이프라인 특성

파이프라인 특성 페이지의 오버플로우 메뉴에서 파이프라인 특성을 정의하려면 파이프라인 구성을 선택하십시오.

파이프라인 구성 페이지의 환경 특성 탭에서 파이프라인 레벨 환경 특성을 설정하십시오.

스테이지 특성

단계 특성을 정의하려면 단계 구성 페이지를 열고 환경 특성 탭을 클릭하십시오.

초기 값(또는 공백 값)을 사용한 후 환경 변수를 활용하여 작업에서 해당 값을 대체함으로써 단계 특성을 정의할 수 있습니다. 초기 값을 대체하면 단계의 후속 작업에 새 값이 표시될 수 있습니다. 예를 들어, 다음 명령을 포함시켜 $API_KEY 속성을 설정하고 스테이지 내의 다른 작업에서 사용할 수 있도록 할 수 있습니다: export API_KEY=<insert API key here>

계산된 특성

단계가 실행되는 동안 build.properties 파일을 작성하여 여러 단계에 걸쳐 공유되는 환경 특성 값을 계산한 후 다음 단계에서 해당 파일을 실행할 수 있습니다. 예를 들어, 빌드 작업에서는 다음 명령을 빌드 스크립트에 포함할 수 있습니다.

echo "IMAGE_NAME=${FULL_REPOSITORY_NAME}" >> $ARCHIVE_DIR/build.properties

파일이 존재하는 경우 build.properties 파일을 실행하면 모든 작업이 시작됩니다.

아티팩트 작성 및 사용

빌드 작업은 사용자 스크립트가 실행되는 현재 폴더에 컨텐츠를 자동으로 페치합니다. 나중에 배치하기 위해 전체 Git 저장소 컨텐츠가 필요하지 않은 경우 명시적 출력 디렉토리를 구성한 다음 관련 아티팩트를 해당 디렉토리에 복사 또는 작성하는 것이 좋습니다. 작업 스크립트가 빌드 결과에서 실행됩니다(출력 디렉토리).

IBM Cloud Kubernetes Service에 배치하는 배치 작업은 권한 작업이 실행되는 사용자의 플랫폼 API 키, Dockerfile 및 선택적으로 Helm 차트를 지정해야 합니다.

지정된 플랫폼 API 키를 사용하여 작업이 대상 환경에 로그인한 후에 작업 스크립트가 실행됩니다(스크립트에서 cf push 또는 kubectl 명령을 실행할 수 있도록 함).

파이프라인 예

단순 파이프라인에는 세 개의 단계가 포함될 수 있습니다.

앱에서 빌드 프로세스를 컴파일하고 실행하는 빌드 단계
앱의 인스턴스를 배치한 후 거기서 테스트를 실행하는 테스트 단계
테스트한 앱의 프로덕션 인스턴스를 배치하는 프로덕션 단계

다음 개념 다이어그램에 이 파이프라인이 표시되어 있습니다.

단계는 저장소와 빌드 작업에서 입력을 받으며 단계 내의 작업은 순차적으로, 그리고 서로 독립적으로 실행됩니다. 파이프라인 예에서, 테스트 및 프로덕션 단계가 모두 빌드 단계의 출력을 입력으로 받지만 단계는 순차적으로 실행됩니다.